Reqmagazyn wydanie 3

Nr 3/2015

kwa rta l n i k

N A S T Y K U B I Z N E S U I I T: minimum viable product szkodliwe legendy w it Św i at d e f i n i c j i , m o d e l ś w i ata

Od potrzeby do procesujak zsyntezować wiedzę o użytkownikach?

Jeden konflikt wiele ścieżek ku jego rozwiązaniu

inżynieria wymagań | inżynieria oprogramowania |user experience|zarządzanie projektami |dział prawny

Inżynieria Wymagań IREB

Szanowni Państwo

– potrójny pakiet korzyści weryfikacja

Rok temu zrodził się pomysł stworzenia magazynu skierowanego do tych, którzy poszukują wiedzy z zakresu inżynierii wymagań oraz dziedzin ją wspierających. W poprzednim numerze pojawił się nowy dział - UX, który został przez Państwa pozytywnie odebrany. Niezmiernie nas to cieszy, ponieważ staramy się prezentować artykuły, które są nie tylko źródłem wiedzy teoretycznej, lecz prezentują również najlepsze praktyki wykorzystywane przez profesjonalistów w swojej dziedzinie.

wymagan

wsparcie w

Projekcie

Bieżący numer magazynu został rozszerzony o Dział Prawny, który coraz częściej pojawia się w roli uczestnika w procesie wytwarzania oprogramowania. W ramach nowego działu przeczytacie o mediacjach, jako sposobie rozwiązywania konfliktów między Klientem a Dostawcą.

innowacyjnosc

Synergia

Zrozumienie potrzeb Klienta to największe wyzwanie, z którym musi się zmierzyć każdy inżynier wymagań. W tym numerze prezentujemy techniki, które pozwolą Wam nie tylko umiejętnie porozumiewać się z Klientem, ale przede wszystkim pozwoli Wam łatwiej zrozumieć jego potrzeby, co ostatecznie przekłada się na jakość produktu.

zakres projektu

Czy jesteśmy w stanie dostarczyć Klientowi produkt wysokiej jakości przy niskim nakładzie sił? Na to pytanie odpowiadamy w pierwszym artykule bieżącego numeru magazynu.

rekomendacje

Zapraszam do lektury!

W PAKIECIE TANIEJ ulepszanie Szkolenie + członkostwo w stowarzyszeniu + egzamin procesów W SPECJALNEJ CENIE REQ

Monika Perendyk Prezes Stowarzyszenia Inżynierii Wymagań Redaktor Naczelna REDAKCJA Opracowanie i redakcja: Redaktor naczelna: Monika Perendyk Zespół redakcyjny: Włodzimierz Dąbrowski Artur Kiełbowicz Rafał Stańczak Korekta: Ewa Brzeska Projekt graficzny i skład: Dagmara Zawada-Żark

2

Prawa autorskie Wszystkie opublikowane artykuły są objęte prawem autorskim autora lub przedsiębiorstwa. Wykorzystywanie w innych publikacjach, kopiowanie lub modyfikowanie zawartości artykułu bez pisemnego upoważnienia autora jest zabronione.

Więcej szczegółów: http://cts.com.pl/info/inzynieria-wymagan-ireb

magazyn

Facebook http://www.facebook.com/ reqmagazyn Reklama czasopismo@wymagania.org.pl Współpraca Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: czasopismo@wymagania.org.pl

wymagania.org.pl 3

Spis

Treści Działy stałe

2

Słowo wstępu

Inżynieria Oprogramowania

Ewa Brzeska

Na styku biznesu i IT: Minimum Viable Product

6

Inżynieria Wymagań

Hanna Wesołowska

Świat definicji, model świata

12

Zarządzanie projektami

22

Bogdan Bereza Szkodliwe legendy IT

Dział prawny Karolina Alama Jeden konflikt- wiele ścieżek ku jego rozwiązaniu, czyli rozwiązywanie sporów dotyczących nowych technologii

32

User Experience

Aleksandra Masłowska Od potrzeby do procesu - jak zsyntezować wiedzę o użytkownikach ?

16

4

5

Ewa Brzeska

Inżynieria Oprogramowania

Na styku biznesu i IT: Minimum Viable Product

W

Wstęp

drugim numerze REQ Magazyn ukazał się mój artykuł na temat zakresu projektu i produktu informatycznego1. W dzisiejszym artykule chciałabym nawiązać do tej tematyki i omówić tzw. produkt minimalnie satysfakcjonujący, czyli produkt typu MVP (Minimum Viable Product).

Strategia tworzenia produktów w oparciu o produkt MVP jest doskonałą strategią pozwalającą maksymalizować efekt rynkowy przy jednoczesnej minimalizacji kosztów i strat wytwarzania. Zastosowanie tej strategii umożliwia przeprowadzenie badań rynkowych przed wprowadzaniem na rynek nowych produktów, w tym oprogramowania lub usług informatycznych. Badania takie dają szybką i ilościową odpowiedź na pytanie, czy dany produkt powinien zostać wytworzony: czy istnieje potrzeba, na którą produkt ma być odpowiedzią lub problem, który dany produkt pomoże rozwiązać. Pozwala również sprawdzić, czy istnieją klienci, którzy są gotowi kupić ten produkt. Jest to bezcenna wiedza, szczególnie w warunkach niepewności rynkowej.

Rys 2 Minimum Viable Product

woleniem klienta. Koncepcja ta została ogłoszona przez Blank’a w czternastopunktowym manifeście Customer Development Manifesto i stanowiła podwaliny dla Lean Startup – podejścia spopularyzowanego przez Erica Riesa.

Startup wg definicji Steva Blank’a to „tymczasowa organizacja poszukująca powtarzalnego, skalowalnego i zyskownego medelu biznesowego”. Przedsiębiorców zarządzających startupami cechuje chęć stworzenia nowego produktu i wprowadzenia go z sukcesem na rynek w warunkach skrajnej niepewności.

6

Idea MVP bardzo dobrze wpisuje się w metodyki oparte na iteracyjnym podejściu do projektu oraz przyrostowym tworzeniu produktu, jak Lean czy Agile, które sprawdzają się doskonale zwłaszcza w warunkach niepewności rynkowej. Aby zminimalizować ryzyko, ograniczyć koszty wprowadzenia produktu na rynek, a jednocześnie czy trategia tworzenia zbadać, produkt ten nap r o d u k t ó w znajdzie bywców, twow oparciu o MVP jest rzy się na poKoncepcja Lean szczupłego wytwarzadoskonałą strategią czątku produkt nia i szczupłego zarząMVP - produkt p o z w a l a j ą c ą pozwalający dzania - rozwinęła się w oparciu o zasady maksymalizować efekt rynkowy na zebranie od Systemu Produkcyjneklientów maksigo Toyoty, zastosowane przy jednoczesnej minimalizacji mum informacji po raz pierwszy zaraz kosztów i strat wytwarzania. przy najmniejpo II wojnie światowej. szych poniesioDla potrzeb startupów, nych kosztach: w tym takich, które bazują na wytwarzaniu „A version of a new product which allows oprogramowania, koncepcję Lean opisał a team to collect the maximum amount of w swojej książce „The Lean Startup”2 Eric Ries. validated learning about customers with the Jest on często mylnie uważany za autora po- least effort””. Należy przy tym dążyć do tego, jęcia MVP. Strategią Lean Startup jest ciągłe aby zminimalizować całkowity czas przejścia testowanie założeń i korekty modelu w pętli przez pełną pętlę sprzężenia zwrotnego, to informacji zwrotnych Tworzenie – Pomiary – znaczy, aby czas od powstania wizji produkUczenie się (Rys. 1) oraz zwroty (Pivot) kon- tu do momentu otrzymania z rynku informacji o zapotrzebowaniu na ten produkt był jak naj2 Tytuł oryginalny: The lean startup: How Today’s Entrepreneurs Use Conkrótszy. tinuous Innovation to Create Radically Successful Businesses, przekład:

S

Rys 1 Pętla informacji zwrotnej w Lean Startup

W niniejszym artykule omówię ogólne, uniwersalne aspekty modelu MVP i będę posługiwała się bardzo ogólnym terminem „produkt”.

W szczególności produkt może być programem komputerowym lub usługą informatyczW IT przyjęło się, że model MVP może być wy- ną. korzystywany przede wszystkim do realizacji oprogramowania mobilnego i webowego.

MPV – zacznijmy od początku Tymczasem, moim zdaniem, model ten jest na tyle uniwersalny, że można z niego korzy- Pojęcie MVP wywodzi się bezpośrednio z Custać w szerokim zakresie realizowanych pro- stomer Development, czyli z metodyki zajmujektów informatycznych, a nawet w realizacji jącej się rozwojem produktu sterowanego projektów spoza branży nowych technologii. potrzebami klienta. Jej autorem jest Steve Blank, który już w połowie 1990 roku stworzył koncepcję zrównoważonego związku pomię1 „Na styku biznesu i IT: zakres projektu informatycznego i zakres oprogramodzy rozwojem produktu a potrzebami i zadowania” – artykuł opublikowany w REQ Magazyn nr 2.

cepcji rozwiązania powstałe w wyniku procesu uczenia się.

Bartosz Sałbut.

7

Wspomniana wyżej minimalna funkcjonalność MVP powinna być jednocześnie kluczowa i reprezentatywna dla tworzonego produktu.

Dzięki temu można na jej podstawie pokazać zainteresowanym odbiorcom wartość, unikalność i innowacyjność produktu (Rys. 2).

Przemyślenie zakresu funkcjonalnego MPV pozwala jednocześnie uniknąć strat produkcyjnych, co jest zgodne z koncepcją Lean.

MPV to strategia zmniejszania ilości godzin inżynierskich zmarnowanych na tworzenie niepotrzebnych czy nieprzemyślanych funkcji produktu. W swojej praktyce zawodowej spotkałam się wielokrotnie z sytuacją, kiedy produkt informatyczny (zwykle oprogramowanie) był realizowany od razu w bardzo szerokim zakresie, z mnóstwem funkcji, których zaprojektowanie oraz implementacja wymagały wielu godzin pracy architektów, projektantów i programistów. Tymczasem po wdrożeniu okazywało się, że wiele z tych „fantastycznych” i okupionych tak dużą pracochłonnością wykonania funkcji jest wykorzystywanych przez użytkowników tak rzadko, że produkt spokojnie mógłby się bez nich obyć.

Tradycyjny model wprowadzania produktów na rynek vs Customer Development Tradycyjny schemat wprowadzania nowych

Na początku jest idea, wizja inwestora projektu, która z czasem może zostać rozbudowana o wymagania techniczne i rynkowe względem produktu. Następnie długi czas trwają prace rozwojowe, w ramach których realizowana jest funkcjonalność produktu zgodna z wizją i spełniająca wymagania.

Po pomyślnym przejściu obu faz testów, pierwsza partia produktów jest gotowa do wprowadzenia na rynek.

W tradycyjnym podejściu do wytwarzania nowych produktów prace rozwojowe odbywają się często w metodyce klasycznej – wg kaskadowego modelu rozwoju produktu, składającego się z poszczególnych etapów prac, następujących sekwencyjnie jeden po drugim (Rys. 4).

Przywołane wyżej klasyczne podejście do rozwoju produktu charakteryzuje się m.in. tym, że pierwsza informacja zwrotna z rynku spływa do wytwórcy po bardzo długim, jak na dzisiejsze standardy, czasie – dopiero po zakończeniu realizacji ostatniego etapu procesu wytwórczego. Rozwiązanie powstaje właściwie w oparciu o założenie, iż producent dokładnie wie, czego oczekuje klient oraz jakie cechy produktu będą dla klienta i użytkownika najlepsze i w rezultacie spowodują przyjęcie się rozwiązania na rynku. Co więcej,

trwają relatywnie dłużej, proporcjonalnie do tu oraz gotowe są dać informację zwrotną, niezbędną dla jego dalszego rozwoju. Steve nasycenia właściwościami i funkcjami.

Black wyróżnia zespół następujących cech, Konieczny jest też odpowiednio wysoki budżet pożądanych u wczesnych użytkowników: na sfinansowanie prac rozwojowych.

• użytkownik ma problem lub potrzebę, Przy takim podejściu często zdarza się, że w momencie, kiedy produkt jest gotowy do • ma świadomość problemu lub potrzeby, wdrożenia, nie jest już innowacyjny ani interesujący dla potencjalnych użytkowników, gdyż • aktywnie poszukuje rozwiązania problemu upływający czas oraz konkurencja rynkowa i musi je znaleźć w określonym terminie, pozbawiły go tych atutów. W kontrapunkcie do tradycyjnego modelu rozwoju produktu • problem jest na tyle poważny i dotkliwy, że są wszelkie podejścia przyrostowe i zwinne, obecnie stosowane jest rozwiązanie tymczaktóre bazują na założeniu, że kolejne iteracje sowe, produktu pojawiają się na rynku w odpowiedzi na konkretne zapotrzebowanie klientów • użytkownik dysponuje budżetem na zakup i użytkowników (Customer Development i User skutecznego rozwiązania.

Driven Development).

Wyłonienie grupy wczesnych użytkowników Wprowadzenie na rynek prototypu - pierwszej, o wyżej wymienionych cechach może prze-

Rys. 5 Źródło: http://www.dilbert.com

Rys. 3 Tradycyjny schemat wprowadzania produktu na rynek

stosunkowo niewielkiej wersji produktu i oddanie jej do eksploatacji użytkownikom stanowi swoiste „wyjście w teren” zgodnie z Manifestem Customer Development. Pozwala na zebranie danych, które pokażą w jakim kierunku powinien rozwijać się produkt. Może się okazać, że z niektórych dotychczas zaimplementowanych funkcji należy zrezygnować, gdyż nie spotkały się one z odpowiednim zainteresowaniem pierwszych użytkowników.

sądzić o przyszłym sukcesie produktu na rynku. Jeśli uda się znaleźć tego typu odbiorców pierwszej wersji produktu, będą oni szczęśliwi mogąc kupić rozwiązanie skutecznie eliminujące ich problem, chętnie przekażą informację zwrotną oraz będą szeroko dzielić się wiedzą o produkcie, jednocześnie polecając go innym.

Określanie funkcjonalności MVP

Inne funkcje powinny zostać przeprojektowane w stosunku do pierwotnych założeń, a ko- Modele zwinne i przyrostowe nie mówią lejne cechy i funkcje powinny zostać doda- wprost, jaki ma być zestaw cech i funkcji pierwszej, prototypowej, wersji produktu. ne, aby produkt stał się atrakcyjny rynkowo.

Rys 4 Kaskadowy model rozwoju produktu

produktów na rynek, stosowany dotychczas z powodzeniem w wielu firmach, które mają ugruntowaną pozycję na rynku oraz rzeszę wiernych klientów (w dziedzinie oprogramowanie jest to np. Microsoft), wygląda następująco (Rys.3): 8

podczas rozwoju produktu przy zastosowaniu tradycyjnego modelu istnieje silna pokusa, aby powstające rozwiązanie było od razu doskonałe i posiadało jak najbardziej rozległą funkcjonalność (Rys. 5). Tym samym prace nad rozwojem tak rozbudowanego produktu

Zmiany i rozszerzenia funkcjonalne produktu mają miejsce w kolejnych jego iteracjach i powtarzają się aż do osiągnięcia stanu produktu, który w pełni odpowiada potrzebom rynku i jednocześnie przynosi oczekiwany dochód producentowi. Pierwsi użytkownicy rozwiązania powinni być dobrani w przemyślany sposób – najlepiej spośród takich osób, które są zainteresowane wczesną wizją produk-

Które funkcje mają być zaimplementowane w pierwszej fazie i dlaczego oraz jaki jest klucz nadawania priorytetów realizacyjnych. Jak zatem określić funkcjonalność MVP? Można to zrobić na co najmniej dwa sposoby, a kluczem powinna być spodziewana korzyść biznesowa. Gdy znana jest już grupa pierwszych użytkowników produktu, którzy mają konkretne potrzeby i oczekują produktu o funkcjo9

nalności rozwiązującej ich problemy – MVP powinno być rozwiązaniem wystarczająco dobrym, aby stanowiło skuteczne antidotum na te problemy. Pierwsza wersja produktu powinna zatem posiadać zestaw funkcji dokładnie dopasowany do oczekiwań pierwszych jego odbiorców.

prezentowana za pomocą makiet, szkiców i rysunków - sam produkt może nie być nigdy pokazany.

Celem jest zainteresowanie przyszłych użytkowników wizją produktu, ewentualnie zdobycie środków na jego sfinansowanie.

Dokładnie taki i tylko taki – bez żadnych nad- 3.„Smoke test” – w kontekście Lean Startup jest to metoda określania, czy istnieje zapomiarowych cech i funkcji. trzebowanie na dane rozwiązanie, aby uzaPrzyjdzie na nie pora dopiero w kolejnych ite- sadnić potrzebę budowania rzeczywistego racjach produktu, kiedy pierwsi użytkownicy produktu. Smoke test najczęściej składa się wskażą spodziewany przez nich kierunek roz- z jednostronicowej witryny produktu (tzw. lanwoju rozwiązania. Jeśli wizja produktu nie jest ding page), kampanii AdWords, wezwania do jeszcze powiązana z jakimikolwiek potrzeba- działania oraz ewentualnie kampanii e-mail. mi przyszłych użytkowników, metodyka rozwoju produktu w oparciu o MVP pozwala na Wezwanie do działania służy zebraniu infordokonanie pewnego rodzaju eksperymentu macji, jak dużo osób jest rzeczywiście zainte- badania, czy istnieje potrzeba rynku, którą resowanych produktem opisywanym na stronie. Może to być równie dobrze np. prosta produkt ten może rozwiązać. prośba o rejestrację Klienta lub możliwość Aby było to możliwe należy tak dobrać funk- składania zamówień na produkt, może być cjonalność MVP, aby rozległą wizję przyszłe- także wezwanie do współfinansowania realigo produktu zamknąć w kilku lub kilkunastu zacji produktu w ramach kampanii crowdfunkluczowych funkcjach. Jak to zrobić? Przy dingowej. takim podejściu trafność wyboru funkcji zależy przede wszystkim od doświadczenia osób Pewną odmianą landing page może być tzw. podejmujących decyzje (Product Owner, In- „Fake door” - witryna internetowa oferująca westor projektu, założyciel startupu, …) - od coś, co na etapie tworzenia oferty absolutnie znajomości przez nich dziedziny, dla której nie istnienie, aby w ten sposób zbadać, czy powstaje produkt i procesu, który produkt ten oferta spotka się z oddźwiękiem uzasadniającym tworzenie produktu. ma obsługiwać.

Czy MVP zawsze oznacza funkcjonalny prototyp produktu?

To dość przewrotne pytanie, lecz jak się okazuje nie jest ono pozbawione sensu. Jak już wcześniej wspomniałam, głównym celem MVP jest zebranie maksimum informacji od klientów czy użytkowników produktu przy najmniejszych zaangażowanych kosztach.

A gdyby tak zebrać te informacje zanim produkt powstanie? Czy jest to możliwe? Okazuje się, że w zgodzie z modelem MPV możemy również czasami poprzestać jedynie na odpowiednio zrealizowanym badaniu rynku, które dostarczy miarodajnych informacji odnośnie celowości budowy produktu. Oto kilka metod, które pozwalają przekonać się, czy rynek oczekuje naszego rozwiązania:

Wszystkie w/w środki pochłaniają niewiele zasobów, a mogą dostarczyć wielu informacji odnośnie zainteresowania produktem potencjalnego klienta i użytkownika 4.„Concierge MVP” – czyli taka wersja MVP, w której część lub wszystkie funkcje produktu (procesu, który produkt ma obsługiwać) realizowane są manualnie, zamiast automatycznie. Przykładem może być np. porównywarka cen: zgodnie z założeniami i wizją produktu, rozwiązanie to ma w docelowym modelu działać automatycznie w oparciu o specjalizowaną platformę programistyczną. MVP przewiduje jednak przetestowanie założeń i koncepcji za pomocą ręcznego wyszukiwania cen produktów, porównywania ich w tabeli arkusza kalkulacyjnego i wysyłanie wyników porównań drogą mailową zarejestrowanym użytkownikom.

1.Prezentacja w Power Poincie – najprostszy i ciągle często stosowany sposób przedsta- 5.Demonstracyjna wersja produktu – np. wienia wizji produktu potencjalnym klientom w przypadku aplikacji mobilnych może to być czy inwestorom. tzw. „klikalna makieta”, która pozwala wąskiej grupie pierwszych użytkowników zapoznać się 2.Video przedstawiające ogólną koncepcję z produktem i jego przyszłą funkcjonalnością rozwiązania. Idea produktu może zostać zabez konieczności zaangażowania zdecydo10

Bibliografia:

wanie większych środków na wykonanie podobnego funkcjonalnie prototypu aplikacji.

Podsumowanie W dzisiejszych czasach dużym wyzwaniem dla wielu wytwórców produktów w branży nowych technologii (i nie tylko) jest dynamika i niepewność rynku. Produkt, który dziś wydaje się być atrakcyjny, unikalny i innowacyjny, już za kilka miesięcy może zupełnie nie odpowiadać oczekiwaniom potencjalnych użytkowników. Dzieje się tak nie tylko w przypadku rozwiązań całkowicie nowych – podobnym problemem może być rozszerzanie zakresu funkcjonalnego produktów już funkcjonujących na rynku.

Strategia przyrostowego tworzenia rozwiązania w oparciu o MPV oraz uwzględnianie informacji zwrotnych od użytkowników podczas realizacji kolejnych iteracji produktu, pozwala minimalizować koszty wytwarzania i wprowadzania produktu na rynek oraz minimalizuje ryzyko jego odrzucenia. Nie jest to strategia uniwersalna – nadal istnieje wiele firm, najczęściej dużych graczy na rynku IT, które nie pytają potencjalnych klientów i przyszłych użytkowników, jakie są ich oczekiwania w stosunku do wytwarzanych i sprzedawanych rozwiązań. Jednak olbrzymia część podmiotów rynkowych nie może pozwolić sobie na takie sztywne wyznaczanie standardów – ci wytwórcy muszą podążać ze swoimi produktami za potrzebami swoich klientów, aby zdobyć rynek lub utrzymać się na nim. I właśnie w takich przypadkach strategia wytwarzania oparta o MPV może być elementem decydującym o sukcesie.

Książka: 1. Ries Eric, „The Lean Startup”, Helion 2012, ISBN 978-83-246-5100-9, 9788324651009 2. Steve Blank, Bob Dorf, “Podręcznik startupu.

Budowa wielkiej firmy krok po kroku”, Helion 2013, ISBN 978-83-246-6616-4, 9788324666164 Strony internetowe: 1.http://www.syncdev.com/minimum-viable-product [dostęp: 18.09.2015] 2. https://en.wikipedia.org/wiki/Minimum_viable_product [dostęp 18.09.2015] 3.http://www.startuplessonslearned.com [dostęp 19.09.2015] 4.http://steveblank.com [dostęp 21.09.2015] 5.https://en.wikipedia.org/wiki/Steve_Blank [dostęp 23.09.2015] Słowa kluczowe artykułu: Minimum Viable Product, MVP, Lean Startup, User Driven Development, Customer Driven Development

Ewa Brzeska, Doświadczony Manager i Konsultant IT. Od 25 lat związana czynnie z branżą informatyczną. W tym czasie uczestniczyła w realizacji wielu projektów, pełniąc rolę analityka, projektanta, architekta i programisty oraz kierownika projektu. Wśród zrealizowanych przez nią projektów są rozwiązania wspomagające zarządzanie różnymi sferami biznesu i produkcji. Ma ponad 15 lat doświadczenia w tworzeniu systemów klasy MES (ang. Manufacturing Execution System) dla energetyki i przemysłu.

Zarządza projektami i produktami informatycznymi oraz wytwarzaniem oprogramowania. Zajmuje się konsultingiem i doradztwem IT, wykorzystując przy tym bogate doświadczenie praktyczne oraz wiedzę teoretyczną, zdobytą m.in. w Szkole Głównej Handlowej w Warszawie.

W 2009 roku wraz ze wspólnikiem założyła firmę Ebitech, która zajmuje się głównie tworzeniem oprogramowania biznesowego na platformy systemowe Apple: iOS i Mac OS X. Współzałożycielka oraz Członek Zarządu Stowarzyszenia Inżynierii Wymagań.

11

Hanna Wesołowska

Inżynieria Wymagań

właśnie odbiór pewnej, bardzo ważnej, części systemu. Nagle, pomimo wcześniejszej weryfikacji, po tym, jak wszyscy zgodzili się ze sobą, okazało się, że model rozliczeń użytkowników, nie uwzględnia wszystkich ich rodzajów. Oznacza to zmianę działania skomplikowanego modułu, dla którego ta struktura była fundamentem. Nowe typy użytkowników i zupełnie odmienne sposoby ich rozliczania. Miało być tak pięknie, a wyszło jak zawsze – wywraca się nasz zaimplementowany świat.

Firmowa wiedza plemienna

Świat definicji, model świata

P

odczas analizy powinno się tworzyć słownik pojęć i model pojęciowy. Tak. O tym, jak bardzo wartościowe jest wykonywanie pewnych czynności z kategorii dobrych analitycznych praktyk często możesz przeczytać w książkach. Każdą z takich objawionych prawd rozważasz w kontekście przydatności w Twoich projektach.

Nic jednak tak nie przekonuje jak sparzenie się na tym, że postąpiłeś niezgodnie z zaleceniami i ściągnęło to na Ciebie spore kłopoty.

Może w swoich wspomnieniach znajdziesz jakiś wspólny mianownik z poniższymi historiami?

danej zmiany. Ech.

Historia 2: Pewnego zwyczajnego dnia w pracy, w projekcie jakich wiele, rzucone zostało pytanie: „Pakiet to zbiór usług?”. Nie pozostało bez odpowiedzi: „Nie, to pojedyncza usługa. Zbiór to paczka.” Pytającym był programista, który zabierał się za przygotowywanie struktury dla nowo powstającego systemu.

Wprowadźmy element grozy: co by się stało, jeśli nie zadałby tego pytania? Jak zrozumiałby kolejne wymagania? Jak przygotowałby rozwiązanie, którego podwalinami była ta właśnie struktura? Był to wyjątkowo rozmowny programista, zjawisko, stereotypowo rzecz Historie optymistyczne biorąc, nieczęsto spotykane. Idąc dalej – co Historie optymistyczne, bo często wierzymy, by się stało, gdyby analityk nie siedział z nim że będzie dobrze bez tego przerostu formy biurko w biurko? To również niekoniecznie najnad treścią i pisaniny. Wiadomo przecież o co częstsza opcja. chodzi i to nie takie skomplikowane. A jak to bywa w praktyce? W praktyce kwestie zwią- Wydawać by się mogło, że tak niefortunne zane z definicjami potrafią sporo namieszać. mylenie pojęć nie stanowi poważnego ryzyka w pokaźnym procencie przypadków. Jednak czy na pewno? Czy przyjęcie takiego założeCi tak, a ci tak nia zbytnio nie usypia naszej czujności?

Historia 1: Pewnego dnia podczas prezentoUżytkowników mamy takich wania dzieła ostatnich dwóch tygodni, zespół z dumą pokazywał zmiany wprowadzone na i takich życzenie klienta. Wszystko działało dokładnie tak, jak w wymaganiach. Z sali jednak padło Historia 3: Analityk był zadowolony z przebiepytanie skonsternowanej osoby - analityka. gu pierwszego większego projektu. WydawaDziałało tak, jak miało działać, tylko nie tam, ło się, że wszystko idzie we właściwym kierungdzie trzeba. Okazało się, że w nomenkla- ku, wymagania są zaakceptowane, klienci turze klienta i zespołu funkcjonowało słowo zadowoleni, zespół gotowy do działania. Wy„priorytet”, ale znaczyło dwie różne rzeczy! dawało się. Analityk nie wiedział jeszcze, żeby Oznaczało to trzy razy więcej pracy – przygo- nie chwalić projektu przed zachodem, tzn. towanie niepożądanej zmiany, odkręcenie odbiorem, wdrożeniem i popracowaniem na niepożądanej zmiany, wprowadzenie pożą- gotowym rozwiązaniu. W każdym razie, trwał 12

Historia 4: „Świeżak” na jednym z pierwszych spotkań w firmie siedział z notesem i dopisywał do długiej listy zasłyszane nieznane pojęcia – do dopytania o co chodzi. Jedno brzmiało szczególnie zagadkowo i skomplikowanie. Jednak obserwując innych kompanów codziennej pracy, dało się odczuć spokój i pewność. Każdy, zapytany, potrafił powiedzieć, jak działa ten tajemniczo brzmiący mechanizm. Był on nawet opisany w instrukcji.

Co prawda niezbyt rozwlekle, ale był. Kiedy na spotkaniu klient zażyczył sobie modyfikacji jego działania, nie było problemu – każdy wie o co chodzi, więc sobie z tym poradzimy. Jednak nie było tak prosto. Konsternacja rosła za każdym razem, kiedy zespół wprowadzał do mechanizmu coraz to nowe zmiany a później klient szczegółowo dopytywał o jego działanie, bo po wdrożeniu nie do końca zgadzało się z jego oczekiwaniami.

czynają się wtedy, kiedy opisywane jest złożone zjawisko czy mechanizm albo nietypowe słownictwo. Bywa, że takie pojęcia z czasem nabierają więcej cech wspólnych z legendą niż z definicją. Mianowicie: 1) pytając kilka osób otrzymujesz nieco inną wersję 2) nikt nie pamięta skąd to się wzięło 3) nikt nie da sobie głowy uciąć, że tak to właśnie jest, bardziej mu się wydaje. Pojęcie nie zostało ściśle zdefiniowane, bo po co, skoro każdy wie, o co chodzi. Kryzys nadchodzi, kiedy trzeba wytłumaczyć klientowi, czemu to działa inaczej, niż się spodziewał (kto ma słuszność?) albo wprowadzamy zmiany w obszar, w którym funkcjonuje niejasny termin. Pozostając na poziomie „wydaje mi się” lub „prawdopodobnie tak to działa” ryzykujemy naszą reputację u klienta i adekwatnie dużą wartość w odpowiedniej walucie z powodu odkręcania i poprawiania pracy w niewłaściwym kierunku.

Te historie łączy wspólny wątek – przekonanie, że przecież pewne rzeczy są wiadome i nie ma się co nad nimi doktoryzować czy marnować drzew (jak się mówi w opcji bez wydruku?).

Świat definicji Niełatwo jest definicjom w naszej obecnej rzeczywistości, gdy panuje powszechne przekonanie o tym, że należy „stawiać działające oprogramowanie ponad obszerną dokumentację”. Jednak idąc z duchem usprawniania procesów, czy nie powinniśmy uczyć się na powtarzających się błędach?

Niektóre pojęcia funkcjonują w firmie od zarania dziejów. Wyjaśnienie wielu z nich zajmuje Jedna kwestia to - czy warto? Druga – czy kie5 sekund (zrozumienie tyleż samo). Schody za- dy już się za to zabierzemy jako analitycy, to

13

czy zrobimy to dobrze? Często zatrzymujemy się na poziomie – „wypiszę wszystkie trudne pojęcia w porządku alfabetycznym i je z grubsza wyjaśnię”. W czym problem? Otóż jest ich kilka, jeśli pozostajemy z takim rozwiązaniem:

b. pojęcia, które mają wiele znaczeń, w zależności od kontekstu, c. pojęcia, które z innego powodu grożą pojawieniem się nieporozumienia.

1. Nie wiemy jak się te pojęcia mają do siebie, 2. Definicja powinna być krótka i jasna. co znacznie ogranicza ich pełne zrozumienie.

3. Do definicji dołączajmy synonimy. Tłumacz2. Bywa, że znajdują się tam pojęcia bardziej my jedno pojęcie, a w każdym z synonimów takie, jakie chciałbyś wypisać (skróty, niespo- wstawiajmy odwołanie do tego pojęcia. Ułatykane słowa), a nie takie, jakie ktoś chciałby twi to utrzymanie słownika. wyczytać, tzn. szukają4. Definicja musi opisycy, mimo wielu pozycji iestety nawet wać dokładnie jedno w słowniku, nie odnajduje tego, co najbarw y k o n a n i e pojęcie – jeśli po przedziej go nurtuje. doskonałej pracy czytaniu wyjaśnienia, możemy w miejsce w kontekście wyjaśnianego pojęcia 3. Luźno przygotowaprecyzyjnych definicji, wstawić więcej niż jena definicja często samodelu pojęć den taki element i bętysfakcjonuje bardziej dokładnego Ciebie (uzupełniłem i rzetelnego przetestowania, na dzie to nadal podstaopis pojęcia wypełnia- nic się nie zda, jeśli nie będzie wienie prawdziwe, to znaczy, że nie jesteśmy jąc pustą przestrzeń – o tym wiedział nikt poza nami. wystarczająco precyodhaczone) niż odbiorzyjni. ców mających z tym pojęciem konkretny problem lub takich, którzy są posiadaczami ponadprzeciętnie do- Na wysokim poziomie abstrakcji (pojęcia biznesowe) stosujemy glosariusz, który abstrahuciekliwych umysłów. je od projektów i implementacji – tu przydaJakie byłyby kryteria dobrej definicji zaspoka- dzą się słowniki i modele danych. jającej potrzeby wnikliwych ludzi, którzy już na etapie koncepcji są prawdziwie zaintereso- Niektóre narzędzia CASE (np. Visual Parawani tworzonym efektem? Jest to w naszym digm) posiadają wbudowane wsparcie dla wspólnym, i podkreślę, także w naszym wła- tworzenia definicji. Z dowolnego miejsca mosnym analitycznym interesie, żeby rozwiązy- delu można dodać do słownika pojęcie. Każde jego wystąpienie będzie automatycznie wać niejasności jak najwcześniej. stawało się odnośnikiem do słownika. Nieste1. Definicje warte zapisania to nie tylko skróty ty, w języku polskim dla pełnego skorzystania z tego cudu techniki, trzeba odmieniać słowa czy niespotykane słowa, ale także: przez przypadki i liczby. Można przypomnieć a. pojęcia, które używane na co dzień mają sobie szkolne czasy. Mianownik – kto? co? tainne znaczenie niż w kontekście analizowane- ryfa, dopełniacz – kogo? czego? taryfy, celownik – komu? czemu? taryfie. go zagadnienia,

N

Gdzie szukać pojęć? W procesach, regułach biznesowych, wymaganiach.

Wytężajmy uważnie słuch tam, gdzie rozmawia biznes i szukajmy słów-kluczy.

Model świata Co nam po słowniku, który zawiera losowo wybrane, wyrwane z kontekstu słowa? Całość nabiera kształtu i głębszego sensu wtedy, kiedy obec14

ność definicji w słowniku wynika z wystąpienia elementu w modelach. A czym są te modele? Uchwyceniem najistotniejszych w danym aspekcie elementów i zależności między nimi.

Uproszczeniem świata. Mówiąc o świecie mam na myśli interesujący nas wycinek, np. daną dziedzinę, obszar, w jakim działa organizacja czy toczy się projekt.

zainteresowanych i bezpośrednio przedstawić im opracowane materiały.

5. Nie wystarczy wydrukować najważniejsze rzeczy i powiesić na ścianie osób, które powinny z tego wynieść korzyść.

6. Nie wystarczy przy każdym pytaniu zachęcać do samodzielnego wyszukiwania odpoW świecie występują obiekty i ich zachowa- wiedzi, przypominając, gdzie są one dostępnia. Np. jest faktura i z taką fakturą można ne. coś zrobić – wystawić, aneksować. W modelach pojęciowych ważne są zarówno rze- Zdaje się, że ludzie muszą sami natrafić na czowniki i czasowniki. W zasobniku analityka ważny, dręczący ich problem czy wyzwaznajdziemy narzędzie, które przyda się na tę nie, gdzie takie pojęcie będzie odgrywało okoliczność: diagram klas UML. O tym, ile wo- dużą rolę. Jak pokazują przytoczone historie, kół niego zamieszania i czym powinien różnić o takie przypadki nietrudno. Chodzi jednak się model pojęciowy od modelu dziedziny, o zrozumienie, że ten problem wynika z nieciekawie napisał Jarosław Żeliński: http://it-con- doskonałości czy niedoskonałej znajomości sulting.pl/autoinstalator/wordpress/2011/01/18/cho- definicji i można temu zaradzić usprawniając lerny-diagram-klas/. Powiązanych jest też kilka obie te rzeczy. Korzystanie z tych cennych dla innych artykułów wokół tej tematyki. Pozna- organizacji czy projektu zasobów oczywiście da już korzyści, kiedy wykorzysta je choćby wanie świata jedna osoba czuwająca nad merytoryczną Niestety nawet wykonanie doskonałej pracy poprawnością i spójnością. Pełną moc zdow kontekście precyzyjnych definicji, dokład- będzie jednak, kiedy zaczną korzystać z nich nego modelu pojęć i rzetelnego przetestowa- wszyscy. Do tego potrzeba jednak zaangania, na nic się nie zda, jeśli nie będzie o tym żowania, konsekwencji i przykładu z góry. Jewiedział nikt poza nami. Nie udało mi się do- śli biznes zacznie rozmawiać tymi pojęciami tąd zrobić doskonałego wdrożenia. Wiem na- z klientami, architekt komunikować je dalej, tomiast, co nie jest wystarczające (co nie zna- tester odsyłać do pojęć programistów, kieczy, że nie jest warte wykonania i nie stanowi rownicy wykorzystają je, by określać zakres prac, dopiero kiedy wypracujemy kulturę koważnego kroku pośredniego). rzystania z precyzyjnych definicji, rzeczywiście 1. Nie wystarczy przygotować świetne defini- wejdą w życie. W czasem staną się nieodłączną częścią żargonu rozumianą przez wszystcje i modele. kich w ten sam, precyzyjny sposób. Choć 2. Nie wystarczy umieścić je w łatwo dostęp- będą one również zawsze dostępne w miejnym miejscu. scu, do którego każdy będzie miał w nawyku szybko zajrzeć.

3. Nie wystarczy oznajmić do publicznej wiadomości, że coś takiego zostało przygotowa- Co jest najlepsze w definicjach i modelach? ne i gdzie można to znaleźć.

To, że zostają na długo po tym, kiedy pojęcia ulatują nam z głowy, bo minęło tyle czasu lub 4. Nie wystarczy zebrać grupy potencjalnie odeszło tylu ludzi.

Hanna Wesołowska- analityk biznesowy. Doświadczenie w projektach z branży telekomunikacyjnej, bankowej, ubezpieczeniowej i wielu innych. Poprzednie doświadczenia z projektów dla instytucji rządowych. Absolwentka informatyki na Politechnice Gdańskiej (specjalność Inżynieria Systemów i Bazy Danych) i Psychologii w biznesie. Certyfikaty Agile Project Management Foundation, PSM I (Professional Scrum Master), ITIL Foundation, PRINCE2 Practitioner. Prowadząca zajęcia projektowe z Inżynierii Oprogramowania na Politechnice Gdańskiej. Członek International Institute of Business Analysis, członek Stowarzyszenia Inżynierii Wymagań. Autorka artykułów dla Gazety Ubezpieczeniowej, Gazety Bankowej. Prelegentka na konferencjach NetVision, 3camp, UX Camp, Geek Girls Carrots. Członek Sopockiego klubu Toastmasters - organizacji zajmującej się rozwojem umiejętności mówczych i liderskich. Autorka bloga o analizie biznesowej – www.analizait.pl. W wolnych chwilach biega i podziwia widok na morze.

15

Aleksandra Masłowska

UX user

experience

Od potrzeby do procesu - jak zsyntezować wiedzę o użytkownikach ?

P

rojektowanie pozytywnych doświadczeń związanych z korzystaniem z produktu lub usługi zaczyna się w momencie, gdy zrozumiemy naszych użytkowników. Nie wystarczy skupić się wyłącznie na suchych danych demograficznych – wiedza o tym, że 70% użytkowników naszego produktu stanowią osoby w wieku 26-40 lat, nie wpłynie na jakość tworzonych przez nas rozwiązań. Aby stworzyć wartościowy produkt, musimy poznać – i umiejętnie wykorzystać – ich motywacje, obawy, zachowanie i osobowość. Ceną, jaką zapłacimy za kompleksowe podejście, będą jednak nierzadko setki stron raportów i analiz. W codziennej pracy, a zwłaszcza w sytuacji, gdy nie możemy pozwolić sobie na czasochłonne wertowanie dokumentacji, potrzebujemy narzędzi, które pozwolą łatwo odnieść się do posiadanych informacji i podejmować skuteczne działania.

Dzięki badaniom ilościowym uzyskamy mierzalne dane, które następnie będą mogły zostać pogłębione podczas badań jakościowych – wsparte wywiadami obserwacje użytkowników dostarczą informacji na temat ich zwyczajów, potrzeb, obaw i oczekiwań. Na podstawie danych statystycznych będziemy w stanie podzielić odbiorców na grupy, natomiast wywiady umożliwią nam zdefiniowanie typowych wzorców zachowań w odniesieniu do naszego produktu. Treści bogate w szczegóły umykają podczas badania ilościowego, a to właśnie one decydują o przyszłym kształcie projektowanego rozwiązania.

Informacje pozyskane w toku badań z użytkownikami pomogą nam w zdefiniowaniu kim jest użytkownik i do czego dąży. Jak wykorzystać tę wiedzę i jednocześnie dostarczyć organizacji, z którą współpracujemy cenne narzędzia, które przydadzą się nie tylko do zaprojektowania produktu, ale będą stanowić Zacznij od badań punkt odniesienia dla strategów komunikacji, Tak, jak stworzenie rozwiązania dla problemu marketerów, sprzedawców i innych specjalibiznesowego będzie trudne bez dogłębnego stów kreujących portfolio firmy? zrozumienia jego istoty, tak i wypracowywanie elementów dedykowanych konkretnej grupie Opowiedz mi o tym docelowej może przebiegać mniej sprawnie, jeśli nie poświęcimy wystarczająco dużo cza- Informacje o user experience możemy przesu i uwagi, by ją jak najlepiej poznać. Zamiast kazywać opowiadając historię – przyglądadokonywać oceny i podejmować decyzje jąc się użytkownikowi z różnych perspektyw na podstawie pochopnych wniosków, powin- i sytuując go w różnych kontekstach. W tym niśmy najpierw zaangażować się w odkrycie celu możemy zastosować m. in. scenariusze i zrozumienie potrzeb potencjalnych użytkow- (ang. user scenarios), historie użytkowników ników naszego produktu lub usługi. Mocne (ang. user stories), persony, komiksy (ang. podstawy dla dalszych działań otrzymamy storyboards) i mapy podróży użytkownika właśnie dzięki danym pochodzącym z ba- (ang. customer journey maps), które dzięki dań. Dla uzyskania pełnego obrazu sytuacji, zachowaniu ciągu przyczynowo-skutkowego przedstawiają szczegóły interakcji pomiędzy najlepiej jest połączyć kilka ich rodzajów. użytkownikiem a produktem. Wykorzystując 16

techniki wizualne i zaczerpnięty ze studia filmowego storytelling możemy stworzyć niepowtarzalne doświadczenia, które nie ograniczą się wyłącznie do jednorazowego kontaktu z produktem lub usługą, ale doprowadzą do zbudowania długotrwałej, wartościowej relacji. Dobre UX tworzą ludzie, którzy w codziennej pracy w różnych sytuacjach wykorzystują siłę sugestywnej narracji – wplatają użytkownika w historię, ciąg zdarzeń, kontekst. Umiejętność pracy z historią to nieodłączny element projektowania zorientowanego na użytkownika, który możemy wykorzystać na wiele sposobów: • dla zwizualizowania i uzasadnienia zaproponowanego przez nasz zespół rozwiązania problemu, np. w toku komunikacji z klientem, • dla „ożywienia” technologii – nadania określonym funkcjom realnego charakteru i uniknięcia sytuacji, w której rozwiązanie funkcjonalne w teorii nie sprawdzi się w kontakcie z żywym użytkownikiem, • w charakterze narzędzia, które pozwoli nam zrozumieć użytkowników i podejmować trafne decyzje strategiczne.

Postaci z historii Przeprowadzenie właściwej segmentacji na podstawie danych statystycznych, a następnie pogłębienie wiedzy o użytkownikach danego segmentu podczas badań jakościowych, pozwoli na stworzenie sugestywnej wizji jego przykładowych reprezentantów w postaci person. Kierując się celami projektu i organizacji, spośród wyłonionych grup konieczne będzie wybranie tych najważniejszych pod względem biznesowym. Odczucie użytkownika końcowego, zamiast być jedynie punktem na mapie do zrealizowania celu kwartalnego, będzie pełnoprawnym uczestnikiem procesu projektowego, który szuka dialogu z marką i staje się głównym bohaterem naszych historii.

W toku pracy nad narzędziem poszukujemy przede wszystkim wzorców zachowań. Persona nie będzie dosłownym ucieleśnieniem określonej grupy wiekowej czy zawodowej – będzie za to reprezentować użytkowników o podobnym lub identycznym charakterze, kontekście i celu interakcji. Grupę odbiorców, którą ożywimy w personie, będzie charakteryzować wspólny:

produktu, czego się obawia?)

• szanse (co może zwiększyć jej zainteresowanie?)

• wpływ (jak na nią wpłynąć, jak przekonać ją do skorzystania z produktu?)1 Konkretne postaci stworzymy nadając personie indywidualną osobowość – imię, wiek, zainteresowania, motto, podejście do technologii, rodziny, otoczenia. Na samym końcu pozostaje wybór odpowiedniego zdjęcia – tak, by nie ukierunkowywało opisu, zamiast go dopełniać. Wszystko po to, by przybliżyć zespołowi docelowego odbiorcę.

Persony w formie dedykowanych szablonów, a następnie opracowane graficznie i wydrukowane, powinny trafić do wszystkich osób zaangażowanych w projekt.

Dlaczego warto rozpocząć projektowanie od zbudowania persony? Przede wszystkim uczłowieczamy w ten sposób odbiorcę końcowego, dając mu głos w decyzjach strategicznych. Rozwiązania nie dedykujemy już abstrakcyjnej grupie, o której przeczytaliśmy w raporcie segmentacyjnym, ale realnej społeczności.

Wyobraźmy sobie, że...

Dopełnieniem person, które pozwoli nam umieścić wykonywane przez odbiorcę zadania w charakterystycznym dla niego kontekście, są scenariusze użytkownika. Uzupełniając personę o historię, uzupełniamy naszą wiedzę o grupie docelowej, jednocześnie dostarczając informacji, które szybko się nie zdezaktualizują.

Rozpoczynając pracę nad scenariuszem dobrze jest przyjrzeć się kilku najpopularniejszym powodom, dla których użytkownicy sięgają po nasz produkt lub zadaniom, które będą chcieli zrealizować w jego obrębie. Scenariusze mogą przyjąć mniej lub bardziej rozbudowaną formę – warto jednak pamiętać, by w procesie ich tworzenia nie skupiać się na funkcjach czy wybranych elementach struktury projektowanego rozwiązania, ale na celach użytkowników i wykonywanych przez nich czynnościach. Nie musimy tworzyć scenariuszy dla wszystkich możliwych przypadków użycia produktu, ale jedynie dla tych, które będą mieć realny wpływ na tworzone rozwiązanie lub są szczególnie istotne z punktu widzenia użytkownika.

• cel końcowy (co chce osiągnąć za pomo- Warto też pamiętać o tym, że cechą niezbędcą produktu?) ną scenariusza, tak jak każdej dobrej historii, • motywacja (dlaczego się nim interesuje?)

1 Banach Monika, „Persony, czyli jak wejść w buty klienta”, w: Marketer+, 2015 (http://marke• bariery i obawy (co może ją zniechęcić do terplus.pl/teksty/artykuly/persony-czyli-wejsc-buty-klienta/).

17

jest zachowanie ciągu przyczynowo-skutkowego – dzięki temu nie tylko zdobędziemy ogląd na temat tego, jak postępuje użytkowWidzi, myśli, czuje nik, ale również uzyskamy odpowiedź na pytanie „dlaczego?”, wnikając głębiej w sferę Ustaliliśmy już, że niezależnie od tego, czy potrzeb i motywacji. projektujemy złożony serwis transakcyjny lub opracowujemy strategię treści dla sklepu inTa wiedza, w połączeniu z odzwierciedlony- ternetowego, musimy zdawać sobie sprawę mi w scenariuszu cechami charakterologicz- dla kogo to robimy.

• co myśli i czuje? (co ma dla niego faktyczne znaczenie, jakie są jego prawdziwe przemyślenia i opinie, które zachowuje tylko dla siebie?)

cować wiarygodne i logiczne procesy, skupiając się na tych elementach, które mogą w szczególny sposób wpłynąć na zbudowanie emocjonalnej relacji z użytkownikiem.

• co słyszy? (jakie sygnały dźwiękowe dochodzą do niego z otoczenia – jakie wypowiedzi, reakcje znajomych, komunikaty z mediów mają na niego wpływ, jakie opinie słyszy?)

Całościowe spojrzenie na doświadczenie uzyskamy dzięki sięgnięciu do metodyki service design. Mapa podróży (ang. customer journey map) to świetny sposób na zwizualizowanie drogi, jaką pokonuje użytkownik w trakcie korzystania z produktu lub usługi – zarówno online, jak i offline. Przykładowo, chcąc kupić ubezpieczenie domu, będzie się on przemieszczał pomiędzy określonymi punktami styku z marką – w tym przypadku może to być nie tylko serwis ubezpieczyciela, ale również placówka, infolinia, telewizja czy materiały prasowe.

• co widzi? (jakie komunikaty wizualne do niego docierają – jak wygląda jego otoczenie, mieszkanie, praca? Jaki jest jego gust, co lubi, co mu się podoba?)

• co mówi i robi? (jak zachowuje się w codziennych sytuacjach? Jakie są jego codzienne rytuały, czynności, zwyczaje, zainteresowania? To, co naprawdę robi, nie musi być spójne z tym, co myśli i czuje, ale może być Stosunek użytkownika do marki będzie kształwynikiem dopasowywania się do określonych tował się w każdym z tych punktów – skupiastandardów społecznych). jąc się na interakcjach i eliminując możliwe

Rys. 1 Szablon mapy empatii, źródło: mat. własne oraz https://norulesjustwords.wordpress.com/2013/02/24/a-voice-of-the-customer-without-meeting-the-customer

nymi, pozwoli nam zaprojektować interakcje, Po stworzeniu person warto skupić się na dofunkcje i treść przyszłego serwisu. znaniach, myślach i uczuciach naszych użytkowników. Możemy wykorzystać do tego Jak ubrać czynność w historię? Wyobraźmy mapę empatii – narzędzie, które zgodnie sobie, że persona X rozważa zakup ubezpie- z metodyką design thinking można nazwać czenia samochodowego. metaforyczną parą butów2 , dzięki której możliwe będzie odzwierciedlenie prawdziNigdy nie interesowała się tym te- wych odczuć związanych z doświadczeniem. matem, ale słyszała od koleżanki, że Wchodząc w buty użytkownika uwrażliwiamy może otrzymać zniżkę za bezszkodo- się na problemy, na które może natrafić. wą jazdę. Chciałaby się dowiedzieć, czy i jaka zniżka przysługuje jej w towarzystwie Y. Celem mapy empatii jest dogłębne zrozumieZe względu na nawał obowiązków wolałaby nie odbiorców i usytuowanie ich w złożonym zrobić to online, gdyż nie ma czasu na wizytę kontekście – spojrzenie poza projektowane w placówce. rozwiązanie i odkrycie czynników, które determinują sposób, w jaki postrzegają swoje Tak skonstruowany scenariusz daje nam wy- środowisko. Ważne, by na pojedynczym szaraźne informacje o potrzebach persony X. blonie przedstawiać preferencje wyłącznie W tym przypadku będzie to uzyskanie infor- jednej grupy odbiorców. Stawiając personę macji na temat przysługujących jej zniżek. Re- w centrum, odpowiadamy na pytania – zaalizację potrzeby umożliwi jej np. prosty kalku- równo w kategorii teraźniejszości, jak i oczelator zniżek. kiwań:

2 Ingle Beverly, „Design Thinking”, One Press 2013, s. 65.

18

Rys. 2 Przykładowa mapa podróży użytkownika, źródło: Symetria

Szablon uzupełniamy również o kategorie zagrożenia (ang. pain points) mające miejz szablonu person, tj. obawy i szanse. sce w różnych kanałach, jesteśmy w stanie zaprojektować pozytywne odczucia podczas Uzupełnienie mapy empatii (dobrze jest wyko- korzystania z produktu lub usługi. Dzięki spojrzystać w tym celu samoprzylepne karteczki) rzeniu na problem z lotu ptaka dostrzeżemy i wnioskowanie na jej podstawie w toku pracy zależności pomiędzy niekompletnymi infornad projektem pozwoli na zaprojektowanie macjami na temat ubezpieczenia w serwisie, produktu, który stanowi odpowiedź na indy- a niechęcią do zakupu pakietu w placówce. widualne problemy, tym samym pomagając Aby mapy były użytecznym narzędziem, muosiągnąć bieżącą satysfakcję. szą być wynikiem podsumowania obecnej wiedzy o użytkowniku, a nie luźnych spekulacji Z mapą do celu i przeczuć.

Aby stworzyć zapamiętywalne i satysfakcjonujące doświadczenie, musimy najpierw opra19

Oprócz uzyskanych podczas badań informacji ilościowych i jakościowych, warto włączyć w tworzenie mapy przedstawicieli marki, którzy bezpośrednio stykają się z użytkownikiem – często to właśnie oni posiadają najbardziej wartościowe informacje z pierwszej ręki na temat potrzeb użytkowników i obecnego stanu produktu.

Jak skorzystać na stworzeniu mapy?

1. Kieruj się informacjami zebranymi podczas badań – nie bazuj na przeczuciach. Jeśli nie jesteś pewien niektórych kwestii, postaw pytania i zweryfikuj je podczas dodatkowych badań z użytkownikami.

z udziałem użytkowników są cennym punktem odwołania w procesie realizacji projektu – najlepiej wydrukować je i powiesić nad biurkiem lub na ścianach pomieszczenia, w którym pracujemy nad rozwiązaniem. To nie tylko źródło informacji, ale również przypomnienie, że niezależnie od tego, jakie rozwiązanie projektujemy – robimy to dla innych, nie dla siebie.

Bibliografia:

Książka: 1. Brooks Kevin, Quesenbery Whitney, Storytelling for User Experience. Crafting Stories for Better Design, 2010.

2. Ingle Beverly, Design Thinking, Gliwice, One 2. Wykorzystaj persony – stwórz główne i uzu- Press, 2015. pełniające hipotezy, mając na uwadze przyzwyczajenia i obawy użytkowników.

3. Patton Jeff, User Story Mapping. Discover the Whole Story, Build the Right Product, New3. Narysuj mapę ilustrującą procesy, potrzeby ston, O’Reilly Media, 2014. oraz doświadczenia użytkowników podczas ich kontaktu z produktem lub usługą w róż- Artykuły w internecie: nych punktach styku, wizualizując wiedzę uzy- 1. Banach Monika, Persony, czyli jak wejść skaną podczas badań. w buty klienta [online], maj 2015 [dostęp: 13 sierpnia 2015], dostępny w Internecie: http:// 4. Wyciągnij wnioski do dalszej pracy, iden- marketerplus.pl/teksty/artykuly/persony-czylityfikując obszary w znacznym stopniu ograni- -wejsc-buty-klienta/ czające poziom satysfakcji użytkowników.

2. Samsel Jacek, Marketingowa mapa skarbów [online], styczeń 2013 [dostep: 13 sierpCzerp inspiracje i... nie projektuj nia 2015], dostępny w Internecie: http://antyweb.pl/marketingowa-mapa-skarbow/ dla siebie Podsumowując, źródłem innowacyjnych poStrony internetowe: mysłów może być myślenie wizualne, czyli 1. http://designthinking.pl, [dostęp: 13 sierpsposób komunikowania myśli i pomysłów za nia 2015]. pomocą złożonych z obrazów i symboli szablonów. Nie chodzi tu o rozwiązania o wysokim stopniu szczegółowości, ale proste wizualizowanie kluczowych spostrzeżeń.

Wykorzystując narzędzia i techniki wizualne uzyskujemy komplet informacji o użytkownikach, które następnie można wykorzystać w codziennej pracy projektowej. Graficzne persony, mapy podróży użytkownika i komiksy Aleksandra Masłowska – UX/Content Specialist w Agencji UX Symetria. Na co dzień zajmuje się optymalizacją i tworzeniem strategii i treści serwisów internetowych, przeprowadza analizy eksperckie i badania użyteczności, realizując projekty dla największych marek z branży finansowej.

Agencja UX Symetria specjalizuje się w projektowaniu złożonych interfejsów i przeprowadzaniu badań użyteczności. Od 1998 roku eksperci agencji doradzają i wykonują projekty dla dużych polskich i zagranicznych firm. Obecnymi klientami Symetrii są m.in. Alior Bank, BZ WBK, Credit Agricole, Deutsche Bank, Hestia, ING, LIDL, LOT, Orange, Philip Morris International, PKO, PZU. Agencja UX Symetria jest jedynym w Polsce członkiem międzynarodowego stowarzyszenia UXalliance oraz wyłącznym przedstawicielem Certyfikatu UX-PM – pierwszego na świecie Certyfikatu UX dla Project Managerów.

20

21

Bogdan Bereza

Zarządzanie Projektami

Szkodliwe legendy w IT 1. Mity i legendy zarządzania projektami – jak nie dać się im omamić

Z

więc legendy doskonale istnieją obok wiedzy, a nawet ją wypierają.

Jak powstają baśnie?

W swoich pionierskich pracach, zwieńczonych popularną książką „Logika katastrofy” (The Logic of Failure. Recognizing and Avoiding Error in Complex Situations), niemiecki psycholog Dietrich Dörner badał wzorce postępowania ludzi w różnych sytuacjach niepewności.

W swoich pomysłowych eksperymentach, między innymi realizowanych z pomocą komputerowych gier i symulatorów, Dörner poddawał osoby badane różnym formom nieWygląda to rozczulająco i zabawnie, cza- pewności, takim jak brak informacji, wielka sem żałośnie, kiedy młodych ludzi, nie bardzo złożoność sytuacji, zmienność, opóźniona injeszcze radzących sobie z własnym życiem, formacja zwrotna. własnymi hormonami i porządkiem we własnym mieszkaniu, albo pokoju, rozmaite kursy Oto prosty przykład: eksperymentator udoi studia siłą uczą zarządzania, w tym zarzą- stępnił osobom badanym dwa przełączniki dzania trudnymi przedsięwzięciami IT. Nie ma elektryczne, a w pokoju, oprócz zwykłej lamdziś trendu na porządne robienie tego, co py, były dwie żarówki, czerwona i zielona. Posię robi, natomiast bardzo popularne są wy- łączenie, – o czym badani nie wiedzieli - było rażanie siebie, samorealizacja, wywieranie bardzo proste, jeden przełącznik był od czerwpływu i kreatywność. Wielu wydaje się, że wonej żarówki, a drugi od zielonej. Tyle tylko, wykonywanie nie daje pola do rozwoju tych że działały z pięciosekundowym opóźnieniem. cech, natomiast rządzenie daje, co wzmaga Postawmy się w sytuacji uczestnika badania: pstryka lewy przełącznik (ten, o czym badany tendencję do kultu zarządzania. nie wie, od zielonej żarówki), czeka chwilę, nic Kiedy coś jest bardzo ważne, ale brak nam się nie dzieje, więc pstryka drugi przełącznik na ten temat rzetelnej wiedzy, rodzą się mity. (od czerwonej lamki), zaraz zapala się… zieSzczególną formą takich mitów są systemy lona lampka, bo właśnie minęło pięć sekund. certyfikacji, przypisujące sobie nieomylność. Badany wraca do pierwszego przełącznika, Zresztą, istnienie dobrej wiedzy nie przeszka- pstryk – i po chwili zapala się czerwona lampdza mitom, bo wiedza rozczarowuje: nie ka (minęło kolejne pięć sekund). I już amen, obiecuje gruszek na wierzbie, nie poprawia gotowe, zupełnie fałszywa teoria jest ugrunnastroju, nie daje prostych, uspokajających towana i nie daje się usunąć. recept na bolączki ani gwarancji sukcesu, arządzanie, a jeszcze bardziej jego angielski odpowiednik management, to bardzo modne określenie. Wygląda wręcz, jeśli spojrzeć na rzeczywistość pod odpowiednim kątem, że nikt nie chce robić, a wszyscy chcą kierować, nadzorować, zarządzać. „Inżynieria wymagań” to nazwa niepopularna, „zarządzanie wymaganiami” brzmi dla wielu osób lepiej.

22

Jeśli pozwolić osobie badanej na kontynuowanie eksperymentu, fakty szybko zaprzeczały wstępnej teorii i tutaj zaczynało się najciekawsze. Niektórzy badani upierali się przy swojej pierwszej teorii, wbrew faktom, wymyślając piętrowe wyjaśnienia, tłumaczące niezgodność. Inni szli w kierunku szukania skomplikowanych serii: kombinacji lampek czerwonych i zielonych. Jeszcze inni szukali wyjaśnień zewnętrznych, przypisując kolor zapalającej się żarówki szybkości naciskania przełącznika, użyciu lewej lub prawej dłoni, lub jeszcze bardziej fantastycznym czynnikom.

wierzymy równie chętnie dziś, jak dziesięć tysięcy lat temu, choć oczywiście są to wciąż nowe bzdury.

Jest wiele powodów, dla których lubimy i wierzyć w bzdury, i głosić bzdury. Niepewność, której pełen jest ten świat, a w nim także projekty IT, budzi lęk i niepokój, których próbujemy się pozbyć. Metody naukowe są czasochłonne, a poza tym często udzielają zgodnej z prawdą, ale rozczarowującej odpowiedzi, że czegoś nie wiadomo, lub że przyszłości nie da się przewidzieć, więc o ileż bardziej pocieszające jest myślenie magiczne.

Obrona przed mitologią

To, że w inżynierii oprogramowania dość bezkarnie szerzą się rozmaite modne bzdury, nie oznacza przecież, że nic innego tam nie ma.

Przeciwnie – jest tam mnóstwo trafnych, słusznych metod, technik, technologii, twórczych pomysłów, których przemysł IT nie wykorzystuje nawet w połowie.

Jedną z przyczyn jest właśnie popularność łatwych, pozornie skutecznych, obiecujących gruszki na wierzbie modnych bzdur, który szumem informaSkoro tak nas cyjnym przykrypogrąża system wają metody dwóch przełączników i dwóch żarówek, cóż mówić o zawiłych sprawdzone i skuteczne. Jeśli nauczymy się je wykrywać i odwracać do nich plecami, bęsystemach społecznych i organizacyjnych? dziemy pracować lepiej, sprawniej, efektywniej.

Wiara w modne bzdury

Głoszenie bzdur, jeśli tylko inni w nie wierzą, zapewnia nam wyższe miejsce w stadnej hierarchii. Jak wszystkie ssaki naczelne, żyjemy w grupach o rozbudowanych relacjach społecznych i wysokie miejsce w hierarchii zapewnia jednostkom wiele korzyści. Ten, któremu wierzą, którego naśladują i cytują, uzyskuje wszechstronną przewagę nad tymi, którzy nawet mają rację, ale nie zdołali się z nią przebić do innych.

Wierząc w bzdury, unikamy lęku przed nieznanym. Głosząc bzdury w taki sposób, aby brzmiały przekonywująco i dawały pociechę i komfort innym, zapewniamy sobie liczne społeczne korzyści. Wszystko to może dziać się zupełnie nieświadomie, więc w bzdury

Wąska i ciernista jest ścieżka wiodąca do praktycznej mądrości w zarządzaniu projektami IT. Z jednej strony, kuszą nas niezliczone metodyki i teorie zarządzania o chwytliwych nazwach, często nierzetelne. Z drugiej strony, sceptycyzm - praktyka mówi, żeby zamiast na ulotnych zasadach zarządzania, skoncentrować się na tym, co rozumiemy najlepiej, czyli samej technologii, porzucając zarządzanie.

Z trzeciej strony, skoro sama technologia nie wystarczy, a teorie zarządzanie budzą słuszną podejrzliwość, mamy ochotę w ogóle zrezygnować z próby nauczenia się jakichkolwiek zasad i poprzestać na chaotycznych, nieskutecznych i niepełnych, wyrwanych z kontekstu przykładach i tak zwanych najlepszych praktykach. Unikanie tych trzech pokus wymaga trudu, a ich rozpoznanie – solidnej interdyscyplinarnej wiedzy, szerszej, niż zakres jednego certyfikatu, choćby miały go setki tysięcy osób.

23

2. Czym różni się IT? Musimy to brać pod uwagę?

długich serii jednakowych egzemplarzy pralek albo samochodów, nie ma w IT racji bytu.

Swoista hackerska kultura branży, idealizująca twórczy aspekt budowania oprogramowania IT jest dziedziną szczególną, różniącą się od oraz debugowanie, a wybitnie niechętna prowielu innych gałęzi przemysłu. Stąd nie za- cedurom i nieznacznie choćby sformalizowawsze zasady zarządzania projektami, których nym dobrym praktykom, a szczególnie inżynienauczyło nas doświadczenie tysięcy lat, obo- rii wymagań, powoduje, że nawet w bardzo wiązują i sprawdzają się w IT. hierarchicznych i planowanych działaniach dominuje poBrak obciążeń prawianie (deIT jest dziedziną szcze- b u g o w a n i a ) tradycji w IT gólną, różniącą się nad zapobiegabłędom, od wielu innych gałę- niem Gałęzie przemysłu takie czyli kontrola jak konstruowanie okręzi przemysłu.

Stąd nie jakości jest potów czy budownictwo istnieją od tysięcy lat, me- zawsze zasady zarządzania pro- w s z e c h n i e j s z a zapewnietalurgia i mechanika od jektami, których nauczyło nas od nia jakości, czesetek lat, a nawet dzieobjawem dziny nowsze – przemysł doświadczenie tysięcy lat, obo- go jest nadmierna motoryzacyjny, lotniczy, wiązują i sprawdzają się w IT. w IT popularność elektronika – mają swoje „testowania”, korzenie w tych starszych. jego metod i naIT jest o wiele młodsza i do innych przemysłów rzędzi, podczas gdy praca z wymaganiami, dość niepodobna, ponadto swój złoty wiek – ulepszanie procedur i zapobieganie powstaokres szczególnie burzliwego rozwoju – przewaniu defektów bywa postrzegane jako biużywała w czasach hippisowskiej kontr-kultury, więc łatwiej w niej – psychologicznie - o nie- rokratyczne i nieskuteczne.

standardowe rozwiązania.

Elastyczność oprogramowania

Łowiecki charakter przedsięwzięć IT

Technologia IT, zbudowana wokół architektury von Neumanna, pozwala na znacznie większą elastyczność procesu wytwarzania, a koszt modyfikacji jest niższy. Architektura von Neumanna oznacza, że zarówno instrukcje, jak i dane komputera znajdują się w jego pamięci i mogą być modyfikowane. Kamieniarz, który musi zmienić wykute na granitowym pomniku nazwisko, solidnie się napracuje, więc dba o dokładne i trafne wymagania, natomiast programista zmienia ciąg znaków, czy inne dane, w mgnieniu oka. A więc, zalecane przez metody lean – odkładanie jak najdłużej podejmowania nieodwracalnych, krytycznych decyzji, jest możliwe w znacznie wyższym stopniu przy wytwarzaniu oprogramowania, niż przy wytwarzaniu produktów z kamienia.

Wiele produktów IT jest tego typu, do których wytwarzania formuła łowiecka pasuje lepiej, niż hieratyczne metody konstruowania piramid. Istnieją wprawdzie systemy IT nawet bardziej złożone i bardziej zawiłej architekturze nawet niż transatlantyk czy Airbus A380 – na przykład systemy sygnalizacyjne, systemy kontroli lotów, systemy nadzoru produkcji - ale większość systemów IT jest stosunkowo prostych, niewymagających bardzo dokładnego planowania. Przy ich tworzeniu korzystniejsza biznesowo jest elastyczność, zdolność do zmian i szybkość dostawy pierwszej wersji, niż dokładność, trafność przewidywań i możliwość dokładnego planowania z wyprzedzeniem.

Brak produkcji taśmowej w IT

Zrozumienie, w jaki sposób systemy IT różnią się od piramid, domów i okrętów, pozwala lepiej zrozumieć, jak zasady zarządzania budowaniem oprogramowania różnią się od zasad kierowania budową innych, bardziej tradycyjnych produktów. Tak, istnieje wiele zasad wspólnych dla zarządzania w ogóle i dla zarządzania projektami, bardzo różnymi

IT nigdy na dobrą sprawę nie dorobiło się odpowiednika efektywnej produkcji taśmowej.

Ma to pewne uzasadnienie, bo w IT większość przedsięwzięć ma charakter pionierski, tworzy odmienne od poprzednich prototypy, więc proces produkcyjny, taki jak przy tworzeniu 24

Podsumowanie

projektami, ale projekty IT mają swoją specyfi- w strefę zarządzania kryzysowego. Nie możkę, którą trzeba brać pod uwagę, chcąc nimi na wykluczyć, że – być może nieświadomie dobrze zarządzać.

– takie tworzenie sztucznego chaosu ma za zadanie utrudnić rzetelną ocenę własnych umiejętności sprawnego i skutecznego zarzą3. O młodych wilkach dzania.

Młode wilki, albo, jak niektórzy mówią celowo niepoprawnie gramatycznie, „młodzi wilcy”, to określenie, stosowane ironicznie wobec osób, nie zawsze młodych w sensie wieku kalendarzowego, usiłujących zastąpić rzetelną wiedzę przekonaniem, że posiedli tajemnicze umiejętności, a szerokie doświadczenie – wiarą w jedną cudowną metodę, wspartą dezynwolturą i pewnością siebie.

Młode wilki w zarządzaniu IT często głoszą prymat celu biznesowego, jakim jest szybki zysk, nad rzekomo zbędnymi względami technologicznymi. Wiele żartów na ten temat jest w popularnych komiksach „Dilbert”. Postawę młodych wilków cechuje też lekceważenie celów długoterminowych, a koncentracja na krótkoterminowych.

Postawa, którą można zaklasyfikować do zestawu cech „młodego wilka”, często narzucana jest przez specyficzną kulturę danej organizacji. Organizacje, gdzie szybką realizację potrzebnej funkcjonalności osiąga się kosztem rosnącego długu technicznego, na przykład źle napisanego, trudnego w utrzymaniu i modyfikowaniu kodu, oraz gdzie chaotyczne naprawianie i debugowanie ceni się wyżej, niż tworzenie dobrych procesów lub dokładne określanie wymagań, pozwalających unikać pomyłek i błędów, tworzy kulturę, gdzie takie postawy są nagradzane i utrwalane.

O leśnych dziadkach Podobnie, jak w spektrum politycznym skrajna prawica często wyznaje system wartości paradoksalnie podobny do skrajnej lewicy, tak w zarządzaniu IT postawy „młodych wilków” często zaskakująco potrzebują istnienia postaw pozornie przeciwstawnych, polegających na nadmiernym przywiązaniu do formalnych zasad i reguł, na przesadnym i nieliczącym się z potrzebami biznesu, drobiazgowym planowaniu i projektowaniu. Spektakularne niepowodzenia jednych są wykorzystywane przez drugich jako argument, na rzecz słuszności ich ekstremalnych zasad.

Umiejętność pracy w pośpiechu nie jest wadą, ale wadą jest tworzenie sztucznego, nieuzasadnionego pośpiechu, pomijania kluczowych faz projektu, takich jak praca z wymaganiami. Niekiedy styl pracy osób zarządzających IT robi wrażenie celowego tworzenia sytuacji wprowadzających projekty

Kiedy nie działa zarządzanie przez stres?

Czytając ogłoszenia oferujące pracę programisty, testera, analityka, czy innego uczestnika projektu IT, ma się czasem wrażenie, że treść ogłoszenia jest deklaracją… zupełnego braku umiejętności zarządczych jego autorów.

Jeśli wymaga się, aby uczestnik projektu był odporny na stres, miał rozwinięte umiejętności interpersonalne oraz potrafił sobie radzić z gwałtownymi zmianami, świadczy to bez wątpienia o tym, że w projekcie generowany jest stres, procedury nie działają i wszystko trzeba załatwiać „interpersonalnie”, czyli czasochłonnie i bałaganiarsko, a zupełnie błędne planowanie generuje konieczność gwałtownych zwrotów.

Jeśli ktoś nie radzi sobie z takimi wyzwaniami rodem z partyzantki, niech lepiej z tej pracy zrezygnuje, albo skrzętnie ukrywa ten swój deficyt podczas rozmowy kwalifikacyjnej, bo przecież chaotyczny manager, który w każdym, nawet całkiem spokojnym projekcie narzuca metody zarządzania kryzysowego, nie będzie się zmieniał dla wrażliwców! Tyle, że… powinien się zmienić, jeśli chce być dobrym managerem, także dla pracowników szczególnie zdolnych – i wrażliwych.

Do takiej grupy – zdolnych i wrażliwych - zaliczają się na przykład osoby, mające tak zwany syndrom Aspergera (szczególną formę autyzmu). Jedną z nich był Albert Einstein. Nie każdy, kto ma cechy autystyczne, jest koniecznie Einsteinem, ale opłaca się taką możliwość wziąć pod uwagę, w przeciwnym razie dobór naturalny spowoduje, że wśród pracowników firmy w przewadze znajdą się najzdolniejsi w projektowo-korporacyjnej sztuce przetrwania, zamiast w technice i w realizowaniu potrzeb klientów.

Polecam dalszą lekturę http://pl.specialisterne.com/kim-jestesmy/fundacja-specialist-people/ - Fundacja „Specialist People” Polska.

4. Jest moda na szczupłych Grubi nie są dziś popularni, co widać nawet w nazewnictwie metodyk IT. Pewne popularne zasady zarządzania nazwano „lean” (szczupłe). Wprawdzie oryginalnie dotyczyły one procesów produkcyjnych, nie procesu 25

projektowego, ale pewne idee z nich przeflancowano tak, aby pasowały również do projektów. Na przykład, zalecany w oryginalnej wersji produkcji „lean”, pochodzącej z Toyoty, brak zbędnych zapasów w procesie produkcyjnym, bo trzymanie zapasów kosztuje, przetworzono na projektową zasadę unikania wąskich gardeł.

No i oczywiście „agile” – cały świat metodyk, znanych, jako zwinne.

Te metodyki nie są złe, przeciwnie, mają mnóstwo autentycznych zalet, ale trzeba zachować ostrożność: ich atrakcyjne, sugerujące jakąś niejasną lepszość nazwy, mogą wprowadzić w błąd. Obsesja szczupłości i zwinności, tej cielesnej, nie projektowej, jest dziś tak potężna, że potrafi stłumić zdrowy rozsądek.

Liczne miarodajne sondaże pokazuję, że dziś depresja jest znacznie powszechniejsza niż 50 lat temu, oraz że cierpi na nią znacznie więcej kobiet, niż mężczyzn. Wiele wskazuje na to, że przyczyną tego stanu rzeczy jest obsesja zachowania szczupłej sylwetki, której ofiarą padamy dziś znacznie bardziej, niż dawniej, i częściej kobiety, niż mężczyźni. Depresję u skutecznie odchudzonego powoduje chroniczne uczucie głodu, a u nieskutecznie odchudzonego – poczucie klęski i winy. Skłonność do otyłości ma ewolucyjny sens: w czasach niedostatku, grubas chudł i przeżywał, podczas gdy chudzielec umierał.

Nie przesadzajmy z naciąganiem tej powierzchownej analogii do konkretów świata IT, ale niechże będzie ona dla nas inspiracją do zachowania ostrożności wobec modnych metodyk. Metodyki „agile” oraz zasady „lean” są często lepsze niż inne metodyki, nie dlatego, że tak ładnie się nazywają, tylko z powodu tych swoich konkretnych zasad, które w określonej sytuacji są korzystne. Przykładowo, agile jest lepsze niż nie-agile wówczas, gdy korzystne jest iteracyjne budowanie, gdy mają sens dostawy przyrostowe, gdy korzyści z komunikacji bezpośredniej są większe, niż koszty braku obszernej dokumentacji. Stosowanie tych nazw pozwala dostrzegać faktyczne zalety i wady metodyk, a nie kierować się emocjami i ładnymi, ogólnikowymi nazwami.

Historyczne pomyłki Historia IT obfituje w przykłady, kiedy pewne autentycznie dobre metody, mające nośną nazwę, stały się modne poza zakres swojego faktycznego zastosowania.

Niektórzy z czytelników wiedzą, a może nawet pamiętają, że w językach programowania w latach 50-ych i 60-ych dominowały straszne konstrukcje z użyciem instrukcji GOTO, a ich 26

efektem był tak zwany kod „spaghetti”: trudny albo i niemożliwy do zrozumienia, do przetestowania, do modyfikowania.

Słynny holenderski informatyk Edsger Dijkstra wynalazł dramatycznie lepszy sposób: języki programowania pozbawione GOTO, a dysponujące instrukcjami takimi jak IF, CASE, WHILE, FOR. Dzięki temu wynalazkowi nastąpił prawdziwie kwantowy skok wydajności pracy programistów: zamiast tracić czas i energię na walkę z potworem GOTO, mogli skoncentrować się na sprawnej implementacji algorytmów. Testowanie kodu stało się możliwe!

Takie nowe języki Dijkstra nazwał strukturalnymi. Odtąd w latach 70-ych zaczęła się wielka kariera tego słowa, masowo nadużywanego, sprowadzonego przez złodziei idei do nic nieznaczącego, ogólnikowego przymiotnika zastępującego słowo „dobry”. Tej modzie na słówko „strukturalny” ulegali zarówno cwaniacy, szmuglujący przy jego pomocy modne bzdury, jak i rzetelni fachowcy, zmuszeni z powodów marketingowych popularyzować swoje dobre pomysły przy użyciu słowa-klucza STRUKTURALNY. Znani - słusznie - do dziś twórcy systematycznych zasad analizy i dekompozycji wymagań DeMarco, Yourdon i Constantine nazwali swoje podejście ANALIZĄ STRUKTURALNĄ. Strukturalne programowanie i strukturalna analiza nie mają za sobą nic wspólnego, oprócz tego modnego słówka, pewnie wtedy koniecznego, aby zostać w ogóle zauważonym.

5. O folwarcznym stylu zarządzania Mówiąc inaczej, chodzi tutaj o niepartycypacyjny, niedemokratyczny styl zarządzania, ale nie tylko. Słowo „folwarczny” oznacza więcej, niż jedynie przepływ rozkazów z góry na dół, sugeruje też pewne prostactwo, brak wyrafinowania oraz stwarzanie pozorów nierówności między zarządzającym, a zarządzanym.

Przykłady, jak projekt IT zmieniał się w folwark Wielokrotnie byłem świadkiem sytuacji, gdy zleceniodawca, albo sponsor projektu, albo właściciel firmy dość brutalnie – nawet odwołując się do groźby zwolnienia – narzucał kierownikowi nieprzemyślany harmonogram i termin ostateczny projektu, a kierownik w ten sam sposób traktował uczestników projektu. Częstym objawem folwarcznej kultury jest zmuszanie zespołu do tworzenia kodu, bez poprzedzającej, niezbędnej analizy biznesowej oraz inżynierii wymagań.

Nie zawsze takie działanie wynika ze złej woli Odejście od kultury folwarcznej lub nadmiaru testosteronu, może być wyrazem autentycznej troski, że informatycy, Aby zmienić kulturę, którą – za Jackiem Sanzwłaszcza dział IT własnej firmy, będą nad- torskim – nazwałem „folwarczną”, trzeba zamiernie przedłużać projekt, realizując w nim cząć od diagnozy aktualnej kultury i wskazazbędne wymagania nia, do jakiej kultury lub stosując bez poWystarczy Umiejętność pracy dążymy. trzeby, tylko z ciedo tego zwykła ankawości, najnowsze w pośpiechu nie jest kieta, jeśli tylko wytechnologie, archiją anoniwadą, ale wadą jest pełniamy tektury, języki programowo, i jeśli mamy mowania. tworzenie sztucznego, odwagę zmierzyć Inny, często spotykasię z jej wynikami. ny przykład, to prze- nieuzasadnionego pośpiechu, Jest wiele sposobów świadczenie, że za- pomijania kluczowych faz pro- klasyfikacji i opisów sady procesu dobre kultur organizacyjsą dla maluczkich, jektu, takich jak praca z wyma- nych. Jeden z nich, ale nie dla szefa. ganiami. według mnie szczeW pewnej firmie, usigólnie przydatny łującej wdrożyć dysw praktyce, opisuje cyplinę Agile Scrum, nagminnym problemem kulturę przy pomocy dwóch zmiennych: orienbyło nieustanne wyrywanie przez prezesów tacji na zewnątrz - do wewnątrz, oraz kontrouczestników zespołów scrumowych do nieza- li – elastyczności. Cztery szczególnie wyraźne planowanych zadań. formy tej kultury nazywane są kulturą klanową, adhokracją, kulturą rynkową (zorientowaną na rynek) oraz kulturą hierarchiczną (Rys.1).

Określenie kultury własnej organizacji i zadanie sobie pytania, czy obecna kultura jest odpowiednia do zadań, jakie przed nami stoją, to dopiero początek. Kultura niedopasowana do celów organizacji rodzi wprawdzie napięcia i frustracje, których wyrazem mogą być „folwarczne” relacje, ale ich usunięcie nie gwarantuje jeszcze dobrych relacji – istnieje w każdym z nas wiele napięć wewnętrznych i toksycznych emocji, ale jak sobie Rysunek 1. Przykładowa klasyfikacja kultur organizacyjnych z nimi radzić – to temat, na co najmniej dwudniowy warsztat, nie zmieści się już w tym artykule.

Podobnie, łamana bywa zasada niezmienności wymagań podczas trwania przebiegu (sprint) Agile Scrum, przez tak zwane „wrzutki”.

Jak sobie radzić z podobnymi sytuacjami, jak samemu unikać folwarcznego stylu zarządzania? Tutaj nie wystarczą dobre chęci. Tak zwany dobry kierownik, unikający takich metod, w organizacji o folwarcznej kulturze będzie przez innych, w tym swoich podwładnych, lekceważony i oszukiwany. To wymaga diagnozy kultury organizacji i podjęcia wysiłku jej zmiany na wielu płaszczyznach. Taką zmianą może być transformacja agile, ale nie tylko.

6. Wszystko, byle nie wymagania W pewnym piśmie rzucił mi się w oczy artykuł „Zarządzanie projektami: jak definiować oczekiwane rezultaty i nimi zarządzać?”. Artykuł traktuje o inżynierii wymagań, cały czas skutecznie omijając właściwe nazwy i udając, że dotyczy zarządzania projektami. „Wczesne zaangażowanie” opowiada, że projekt trzeba rozpocząć od określenia wymagań, bez tego nici - ale są tam jakby rozważania na temat sprzedaży (?): ani słowa o wizji biznesowej, ani o wymaganiach. „Zaangażowanie wszystkich stron, zwłasz27

cza IT” mówi na temat kluczowego procesu określenia granic i kontekstu systemu, o konieczności uwzględnienia wszystkich interesariuszy... nie wymieniając tych nazw, za to cytując jakiegoś Richarda Bextona z Namu Trabel Group. Kto to jest? Co on wie o inżynierii wymagań? Po co go cytować? „Czytelne i wspólnie uzgodnione priorytety” owszem, istotne. Priorytety wymagań. Nawet na ten temat jest certyfikat i szkolenie: IREB CPRE „Pozyskiwanie i konsolidacja wymagań”. O tym w artykule ani słychu, ani widu - artykuł za to udaje, że odkrywa Amerykę, albo zgoła Księżyc, głosząc swoje banały.

Jak kierownik projektu radzi sobie z wymaganiami?

Jeśli z wymaganiami jest bardzo źle, czyli często, wtedy kłopoty spadają na cały projekt, ale próby poradzenia sobie z nimi spadają przede wszystkim na kierownika projektu. Jeśli projekt IT nie uda się z powodu braku, niejasności czy zbytniej zmienności wymagań, czy też z braku jasnej wizji biznesowej celu projektu, winę przypisuje się kierownikowi projektu.

Toteż bardzo często, to właśnie kierownicy biorą na siebie odpowiedzialność za ich określenie.

Zarządzanie projektem IT oznacza planowanie, monitorowanie i nadzór nad wysiłkami, służącymi do osiągnięcia konkretnego celu.

Ponieważ ten cel określają i opisują właśnie wymagania, są one osią, wokół której zarządzanie projektami się obraca. Nic dziwnego, że elementy inżynierii wymagań wchodzą w skład wzorców zarządzania. Popularne standardy zarządcze, takie jak PMI, IPMA i PRINCE

28

2, w znacznej części o niej właśnie mówią, co trafnie odzwierciedla fakt, że w projektach, gdzie inżynierii wymagań, jako osobnej aktywności pozornie nie ma, zwykle uprawiają ją właśnie kierownicy projektów.

Co w tym złego? Takie rozwiązanie, jak i inne przeze mnie tutaj opisane, do pewnego stopnia sprawdza się przecież. Zgoda – w niewielkich projektach łączenie wielu ról przez jedną osobę jest pożądane, nawet konieczne: programista jest zarazem architektem i testerem, a kierownik projektu wykonuje obowiązki analityka systemowego oraz inżyniera wymagań.

Jednak to bardzo ryzykowne rozwiązanie.

Jeśli inżynieria wymagań – w istocie osobna dziedzina – kryje się pod innymi rolami, często prowadzi do jej zaniedbywania, do licznych błędów, niełatwych do wykrycia. Czasem takie łączenie ról kierownika projektu oraz inżyniera wymagań jest sposobem na pozorne zaoszczędzenie czasu i pracy, co oczywiście skutkuje błędami i koniecznością późniejszych, bardzo kosztownych przeróbek. Wiele z typowych problemów w projektach IT, na przykład brak dostatecznej znajomości wymagań przez programistów i zwłaszcza testerów, bierze się z tego PM-centrycznego sposobu uprawiania inżynierii wymagań.

Co na to zaradzić?

Co na to zaradzić? W szczegółach, będzie to zależeć od modelu realizacji projektu, na przykład inaczej wyglądając w agile, a inaczej w projekcie sekwencyjnym, ale ogólna zasada będzie ta sama: wyodrębnić inżynierię wymagań, traktować ją, jako osobną dziedzinę i przyjąć zasadę, że szczegóły zarządzania wynikają z wymagań, a nie odwrotnie.

Agile jest gotowe na taki sposób działania: tam osią, wokół której kręci się projekt, jest (w Agile Scrum) rejestr wymagań produktu (product backlog), a rola klasycznego kierownika jest zastąpiona przez właściciela wymagań (product owner).

W dużym, realizowanym sekwencyjnie projekcie, rozwiązaniem najczęściej jest stworzenie roli inżyniera wymagań, zarządzającego produktem.

W projektach, gdzie dużą

rolę dogrywa klient, rozszerzenie i uprawnień, i obowiązków popularnego „analityka biznesowego” bywa dobrą metodą, a w małym, hackerskim projekcie rolę tę mogą pełnić sami programiści – byle w uporządkowany sposób.

7.Ucieczka przed ryzykiem Częstym błędem, zaburzającym zarządzanie projektami IT, jest nieuwzględnianie analizy ryzyka przy szacowaniu przewidywanej pracochłonności projektu.

Niezależnie od stosowanych metod oszacowania – a jest ich wiele – każde oszacowanie obciążone jest pewną niepewnością.

Mogą nastąpić niekorzystne wydarzenia, które spowodują większą pracochłonność. Aby to uwzględnić, pracochłonność i wynikający z niej harmonogram, należałoby określać sta-

wagi różnych atrybutów jakości, wymaganego poziomu jakości w ramach istotnych atrybutów, oraz wymaganej trafności i precyzji pomiaru tych atrybutów.

To, czy dla danego systemu IT ważniejsze jest doświadczenie użytkownika, czy funkcjonalność, czy niezawodność, czy może wydajność, ma kluczowe znaczenie dla oszacowania, które z tych atrybutów należy testować przede wszystkim, a które mniej. Poziom jakości, wymagany dla danego atrybutu, wpływa na czasochłonność i wytwarzania, i testów. Te czynniki trzeba nauczyć się brać pod uwagę i uwzględniać w oszacowaniach. W przeciwnym razie mają miejsce tak absurdalne działania jak szacowanie pracochłonności projektu według wzoru: czas projektu = czas tworzenia * 120%

Wzór zakłada, że testowanie to stały odsetek – na przykład 20% - kosztów tworzenia.

Jest to oczywiście zupełnie błędne założenie.

Tradycyjne wręcz błędy popełniane przy zarządzaniu testowaniem, to: • pomijanie w planowaniu konieczności naprawiania znajdowanych podczas testowania defektów, oraz potrzebę wykonywania na kolejnych wersjach testów regresji; • przy próbach wdrożenia automatyzacji testów, chronicznie zaniżaRys.2. Metody szacowania pracochłonności i harmonogramu projektu na jest czasochłonność zarówno samego wdrożenia, tystycznie, czego z reguły się nie robi. jak i późniejszego utrzymania Ilustracja (Rys.2) pokazuje te zależności. i modyfikacji programów testowych.

Mimo zmian na lepsze, testowanie nadal bywa po prostu niedoceniane, traktowane 8. Sprawdzajcie, ale nie znajduj- jak zło konieczne i zbędny koszt.

cie błędów

Samo testowanie również ma kłopoty z plaTestowanie, choć w ciągu ostatnich dwudzie- nowaniem, jaki tryb testowania jest najkostu lat z pomijanego pariasa IT przeistoczyło rzystniejszy. Zagadnienie pierwsze, to względsię w dziedzinę docenianą i lepiej realizowa- ne korzyści i koszty wczesnego testowania. ną, nadal bywa niepoprawnie traktowane podczas planowania, monitorowania i nad- Dobrze nam znana krzywa Boehma (czerwozorowania projektów. na na ilustracji powyżej) mówi, że testowaOszacowania pracochłonności z reguły nie nie należy zacząć jak najwcześniej, gdyż, we uwzględniają dostatecznie trzech czynników: 29

wczesnych fazach projektu, zmiany – w tym na zbyt długi czas potrzebny IT do realizacji nawet małych zmian. Prawdziwą przyczyną poprawianie bugów – są tańsze. tej sytuacji nie jest technika, a finanse!

Działy IT z reguły finansowane są nie za wykonywane zadania, lecz w formie stałego, rocznego budżetu, natomiast jego usługi są dla pozostałych działów dostępne pozornie za darmo. Powstaje klasyczny efekt gospodarki socjalistycznej: zapotrzebowanie na „darmowe” usługi jest nieskończone, motywacja zleceniodawcy do precyzyjnego określenia swoich potrzeb i wymagań – zerowa, a motywacja wykonawcy do usprawnienia swojej pracy, minimalna.

Rysunek 3. Krzywa Boehm’a oraz krzywa Rybera

10. Owszem, jakość jest za darmo

Krzywa Rybera (zielona linia) przypomina, że z kolei przygotowanie i wykonywanie testów Książka „Jakość nic nie kosztuje” („Quality staje się często tym tańsze, im później w proIs Free”, nie tłumaczona na polski) Philipa B. jekcie jest wykonywane.

Crosby’ego wyszła 35 lat temu, ale jej tezy nadal nie dotarły do wielu osób, zarządzają9. Dział IT a gospodarka socjali- cych projektami IT. Wciąż pokutuje przesąd, że jeśli chcemy ograniczać koszty wytwarzastyczna nia, to powinniśmy pracować na łapu-capu, Szczególna forma złej organizacji powstaje pośpiesznie, bo staranne procedury są koszniekiedy na styku własnego działu IT firmy z jej towne. Tymczasem, w rzeczywistości, do pewdziałami biznesowymi: marketingiem, sprze- nego poziomu, staranność jest w sumie tańdażą, produkcją. Chronicznym problemem, sza, niż praca byle jaka (Rys.4).

o którym często słyszymy w praktyce, jest z jednej strony przeciążenie działu IT, a z drugiej strony narzekania pozostałych działów

Rysunek 4. W jakim sensie, jakość może być za darmo?

11. To nie jest skandynawski kryminał!

pogmatwanych szczegółów. Ludzie, uczestnicy projektu, kiedy są zestresowani i zaniepokojeni, chętnie chronią się w gąszczu szczegółów i wymaga wielkich psychologicznych Skandynawskie kryminały są dziś bardzo mod- umiejętności, żeby skłonić ich do pracy w tryne. Akcja jest tam chaotyczna i skomplikowa- bie przejrzystej prostoty. na, motywy bohaterów niejasne, czytelnik ma uczucie, że ugrzązł w jakimś sennym, ponurym i bardzo długotrwałym koszmarze. W rzeczywistości jednak, zwykle działania biznesowe i organizacyjne Skandynawów cechuje oszczędność, skuteczność i prostota, zupełnie inne niż nastrój ich kryminałów.

Podobnie jest z zarządzaniem projektami. Lektura PMBOK, czy rozbudowanych sylabusów PRINCE2 wzbudza wrażenie, że zanurzamy się w rzeczywistości ogromnie skomplikowanej, pełnej tajemniczych nazw i nie do końca zrozumiałych rytuałów, których opanowanie w teorii wymaga wielu lat, a stosowanie w praktyce, drugie tyle. W rzeczywistości, skuteczne zarządzanie projektami musi być proste, w przeciwnym razie jest nieskuteczne. Trudną sztuką jest osiągnięcie tej prostoty w zawiłej, chaotycznej rzeczywistości, pełnej

Bogdan Bereza, uczestnik w różnych rolach (programista – tester – kierownik) dziesiątków projektów IT, zarówno tradycyjnych jak i agile) w Szwecji, w Polsce i w innych krajach. Doświadczony konsultant i doradca oraz trener. Prowadzi szkolenia w zakresie IT, zarządzania oraz psychologii biznesu od ponad 20 lat. Autor wielu książek i artykułów. Między innymi, trener szwedzkiej „Agile Academy”.

30

31

Karolina Alama

§

Dział Prawny

Jeden konflikt- wiele ścieżek ku jego rozwiązaniu,

czyli rozwiązywanie sporów dotyczących nowych technologii

N

Mediacja

ajbardziej popularnym na świecie, choć w Polsce nadal mocno niedocenianym, pozasądowym sposobem rozwiązywania sporów jest mediacja.

Często jest ona definiowana jako stymulowane negocjacje, ponieważ strony dobrowolne siadają do stołu w celu podjęcia próby dojścia do ugody i negocjują istotne dla nich kwestie w obecności bezstronnej i neutralnej wobec sporu osoby trzeciej (mediatora), który pomaga im dojść do porozumienia.

Mediatora, tak jak arbitra, wybierają strony sporu. Mediator nie wydaje wyroku i co do zasady nie udziela porad prawnych.

W mediacji brak jest sformalizowanej procedury postępowania – nie składa się pozwów ani żadnych formalnych pism (a przynajmniej nie ma takiego obowiązku), sesję można przerwać w dowolnym momencie, strony mogą porozumiewać się z mediatorem na osobności, a mediacja może przybrać właściwie dowolną formę – od mediacji tzw facylitatywnej, 32

gdzie mediator jest jedynie moderatorem rozmowy, pomagającym stronom odnaleźć punkty styczne i odpowiednio je wykorzystać, poprzez mediację ewaluatywną – tu mediator dodatkowo ocenia stanowiska stron i udziela im wskazówek, analizuje ich położenie i sugeruje rozwiązania, aż do mediacji wahadłowej, gdzie strony nie przebywają wspólnie w jednym pomieszczeniu, porozumiewając się poprzez osobę mediatora, który krąży pomiędzy jedną stroną sporu a drugą (ten ostatni rodzaj jest bardzo popularny w USA i w Wlk. Brytanii).

W Polsce w kwestii inicjowania mediacji istnieją dwie drogi – mediacja ze skierowania sądu (coraz częstsza, także w sporach IT) albo tzw. mediacja umowna, czyli mediacja zainicjowana poprzez wyrażenie zgody na mediację, gdy druga strona o nią wnioskowała.

W umowie o mediacje strony określają m.in. przedmiot mediacji, osobę mediatora, ewentualnie sposób jego wyboru – na wszystkie te ustalenia strony muszą wspólnie wyrazić zgodę. Mediacja zostaje wszczęta przez stronę z chwilą doręczenia mediatorowi wniosku o przeprowadzenie mediacji, z dołączonym dowodem doręczenia jego odpisu

drugiej stronie. W przypadku mediacji umownej strony oraz mediator powinni jeszcze przed przystąpieniem do niej ustalić wysokość wynagrodzenia należnego mediatorowi, a także zakres wydatków poniesionych w związku z mediacją podlegających zwrotowi.

Gdy istnieje wola wypracowania rozwiązania polubownego dojście do ugody zabiera zazwyczaj kilka sesji z mediatorem, podczas których rozwiązywane są poszczególne kwestie sporne i stopniowo konstruowana jest ugoda. Gdy strony już się porozumieją, mediator – sam lub na podstawie dokumentów zaproponowanych przez strony i/lub ich prawników spisuje ugodę. W naszym systemie prawnym ugoda zawarta przed mediatorem nie ma jeszcze mocy równorzędnej z wyrokiem sądowym – funkcjonuje jako zwykła umowa między stronami, które zobowiązują się do konkretnych zachowań. Aby nadać temu dokumentowi klauzulę wykonalności, należy złożyć go w sądzie (co robi mediator), gdzie w ogromnej większości przypadków po sprawdzeniu kwestii formalnych (czy ugoda jest jasna, wykonalna i nie budzi wątpliwości od strony prawnej) sąd zatwierdza ugodę.

Podsumowując wątek mediacji, trzeba podkreślić, że podjęcie mediacji – to ze skierowania sądu czy też własnej inicjatywy stron - nie wyłącza późniejszej drogi sądowej w razie niepowodzenia w czasie próby dojścia do ugody. Strony nic więc (poza czasem i ewentualnymi opłatami) nie tracą, jako że nie ograniczają sobie szans na definitywne rozwiązanie sporu inną drogą – czy to w sądzie powszechnym czy też w arbitrażu. Podpisanie ugody w czasie mediacji oraz zatwierdzenie jej przez sąd wraz z nadaniem klauzuli wykonalności jest równoważne z prawomocnym wyrokiem sądowym. Jeśli jednak stronom nie uda się porozumieć - nadal mają one otwartą drogę do rozpoczęcia postępowania.

W wielu krajach mediacja w fazie przedsądowej jest wręcz obowiązkowa, jako mniej in-

wazyjna, mniej kosztowna i bardziej efektywna czasowo metoda rozwiązywania sporów.

W Polsce póki co, nie wprowadzono mediacji obligatoryjnej (choć trwają prace legislacyjne w tym zakresie).

Formy mieszane (hybrydy) i sprawa IBM v. Fujitsu W Stanach Zjednoczonych dość popularnym rozwiązaniem są klauzule multi-step, zakładające określoną konfigurację działań w razie konfliktu, np. strony najpierw przystąpią do negocjacji, następnie w razie niepowodzenia spróbują mediacji, która trwać będzie przykładowo nie dłużej niż dwa tygodnie, a w ostateczności skierują sprawę do sądu arbitrażowego.

Metodami, które wykształciły się wprost z potrzeb praktyki, są tzw. metody hybrydowe, czyli połączenia różnych narzędzi w jak najbardziej efektywnego rozwiązania sporu, jak np. med/arb i arb/med, czyli połączenia mediacji i arbitrażu w jednym procesie rozwiązywania sporu. Łączą one główne zalety obu tych form rozwiązywania sporów, a mianowicie ugodowy charakter mediacji z ostatecznym charakterem arbitrażu. W skrócie proces med/arb przebiega w następujący sposób – strony próbują dojść do ugody z pomocą mediatora, a gdy ta metoda zawodzi – osoba trzecia, którą może być (i najczęściej jest) ten właśnie mediator, który staje się arbitrem, wydaje wiążące rozstrzygnięcie, co do kwestii spornych, których strony nie były w stanie same polubownie rozwiązać. Jest to, więc dość specyficzna formuła, gdzie jedna osoba (lub zespół, jeśli strony tak sobie zażyczą) występuje w podwójnej roli – mediatora i arbitra, jeśli dojdzie do obu faz procesu.

Metoda ta, choć posiadająca wiele niepodważalnych plusów, niesie za sobą również wiele wątpliwości i zagrożeń, jak chociażby kwestia używania w czasie drugiej fazy postępowania – rozprawy arbitrażowej - informacji, które jedna ze stron posiadła w czasie pierwszej fazy, czyli sesji mediacyjnych, jako że jednymi z głównych założeń mediacji są poufność oraz zakaz używania informacji zdobytych w czasie mediacji w ewentualnym późniejszym postępowaniu sądowym (w przypadku niedojścia do ugody).

Jednym z najbardziej spektakularnych i jednocześnie przełomowych w kwestii metody rozwiązywania konfliktów sporem była sprawa pomiędzy IBM i Fujitsu.

33

Po raz pierwszy użyto wtedy med/arb jako gramów w przeszłości i w przyszłości. kluczowej metody przy rozwiązywaniu sporu Strony zgodziły się również na odpłatne doz dziedziny IP, IT i nowoczesnych technologii, konywanie wymiany ściśle ograniczonych a powszechnie uważa się, że właśnie dzię- informacji. I ostatnia kwestia – ugoda przeki niej spór został definitywnie zażegnany. kazywała rozstrzyganie wszystkich przyszłych Sprawa toczyła się głównie w latach 1982 – sporów stron dotychczasowym arbitrom/me1987. IBM twierdził, że Fujitsu użyła na własne diatorom. potrzeby programów IBM w celu rozwinięcia Kolejnym etapem była intensywna praca software’u systemów operacyjnych kompa- ze stronami nad stworzeniem umowy, któtybilnych z systemami IBM. W związku z tym ra regulowałaby proces wymiany informacji IBM zażądał setek milionów dolarów odszko- oraz definiowała opłatę licencyjną. Ostatnie dowania. Wstępnie spór zakończył się zawar- kwestie sporne zostały rozstrzygnięte w drodze tzw. final offer arciem w 1983 r. ugody, bitration, gdzie strony gdy Fujitsu zgodziła a każdym musiały wybrać jedno się wypłacić IBM okrerozwiązań zapropośloną kwotę oraz złorazem, kiedy znowanych przez arbiżyła oświadczenie, iż widzisz biznes, trów. Wartość ugody ograniczy użycie prozostała oszacowana gramów IBM. Ostatnie który odnosi sukces, na $ 833.3 milionów stwierdzenie, co mało zaskakujące, okazało oznacza to, że ktoś kiedyś dolarów1. się niezbyt precyzyjne podjął odważną decyzję.

Warto zaznaczyć, że i w efekcie niebawem w tym konkretnym strony znowu znalazły przypadku klauzula arsię przy stole w celu bitrażowa nie zawieranegocjacji bardziej konkretnych warunków – ła opcji przejścia do mediacji. To same strojednak tym razem zupełnie bez skutku. ny podczas sporu zdecydowały się pozwolić W 1985 r. IBM, powołując się na zawartą arbitrom na użycie innych metod, takich jak w pierwotnej ugodzie klauzulę arbitrażową, właśnie mediacja. Dzięki niej strony uniknęły rozpoczął postępowanie arbitrażowe pod żmudnego, sformalizowanego postępowaauspicjami American Arbitration Association nia dowodowego (discovery) oraz stworzyły (AAA). fundamenty dla dalszej współpracy. Zajęły Obie firmy były gotowe do walki, co nie po- się rozstrzyganiem kolejnych kwestii przez prywinno nikogo dziwić, biorąc pod uwagę, że zmat interesów biznesowych, bez przerzucaIBM stawiał na szali stratę niebotycznych pie- nia się argumentami mającymi dowieść, po niędzy zainwestowanych w rozwój swoich sys- której stronie leży wina. temów operacyjnych, a dla Fujitsu przegrana Rezultat był dla obu stron satysfakcjonujący – oznaczała zablokowanie możliwości rozwija- całe postępowanie z udziałem arbitrów zajęnia software’u kompatybilnego z IBMowskim ło kilkukrotnie mniej czasu niż byłoby to możlioraz utratę klientów, którzy na tę kompatybil- we w przypadku postępowania przed sądem ność systemów liczyli. powszechnym. Należy podkreślić, że w tym Arbitrami i jednocześnie mediatorami w tym przypadku zawarta ugoda może być postrzesporze byli światowej sławy prawnicy - Robert gana jako rzadko spotykane swoiste win-win H. Mnookin i John L. Johnes. Proces rozwiązy- dla obu stron – Fujitsu zachowało możliwość wania sporu rozpoczął się od arbitrażu, jed- utrzymania kompatybilności z systemami IBM, nak szybko zmieniono go na mediację. Celem a drugiej strony IBM miał pewność, że Fujitsu mediatorów było rozszyfrowanie prawdzi- używa jedynie wybranych elementów, za któwych interesów stron, co miało pomóc unik- re płaci ściśle określoną kwotę. nąć rozległego i przewlekłego poszukiwania Nie jest to oczywiście jedyny przypadek tego dowodów oraz ich przedstawiania na kolej- typu w historii – wiele sądów arbitrażowych nych rozprawach, a z pewnością miałoby to wprowadziło regulacje dotyczące metod miejsce biorąc pod uwagę setki programów hybrydowych do swoich regulaminów, co wypuszczonych na rynek przez Fujitsu. uczyniły także niektóre polskie sądy arbitraPierwszy etap rozwiązywania konfliktu zaowo- żowe. Oczywiście nie oznacza to, że praktycował wypracowaniem ugody ramowej, któ- ka ich używania jest powszechna. Co gorsza, ra stworzyła fundamenty dla późniejszej pracy w Polsce zbyt często mediacja ogranicza się nad rozwiązywaniem kwestii szczegółowych. do wysłuchania racji obu stron, bez aktywnej Strony zgodziły się na określoną kwotę (paid- próby znalezienia rozwiązania.

-up licence), którą Fujitsu miało zapłacić IBM w ramach wynagrodzenia za używanie pro-

Z

1 więcej na ten temat można przeczytać na http://www.nytimes.com/1988/11/30/business/software-arbitration-ruling-gives-ibm-833-million-from-fujitsu.html?pagewanted=2&src=pm; wejście z dnia 9 marca 2014 r.

34

Słuchając doświadczeń z rynków zachodnich, mediator wykonuje zdecydowanie cięższą pracę, skłaniając strony do zmiany stanowisk i zawarcia ugody.

By krótko podsumować, rozwiązywanie sporów nigdy nie jest rzeczą szczególnie prostą, a w przypadku sporów w IT – sytuacja komplikuje się kilkukrotnie m.in. z racji na brak regulacji prawnych podążających za potrzebami rynku nowych technologii oraz brak podstawowej wiedzy w tym temacie wśród prawników i sędziów, odpowiedzialnych za rozstrzyganie tych sporów.

Dużą rolę odgrywają dobrze napisane umowy, które ułatwiają interpretację woli stron

i zdarzeń w projekcie. Nie są w stanie jednak zapobiec sporom, więc przed wdaniem się w proces, warto rozważyć inne formy rozstrzygania sporów, by ograniczyć czas i wydatki oraz mieć szansę na pełną prezentację swojego stanowiska. W wielu przypadkach profesjonalna mediacja byłaby rozwiązaniem o wiele rozsądniejszym niż ścieżka sądowa.

Karolina Alama - w Kancelarii Maruta i Wspólnicy od 2013 roku.Specjalizuje się w doradztwie z zakresu prawa nowych technologii, własności intelektualnej oraz sporów sądowych i arbitrażowych. Brała udział w projektach obejmujących tworzenie i negocjowanie kontraktów IT, w tym m.in. umów wdrożeniowych, serwisowych, licencyjnych oraz w audytach i stałym doradztwie prawnym. Uczestniczyła w sporach sądowych i arbitrażowych z zakresu prawa własności intelektualnej oraz prawa IT. Uczestniczka programu podyplomowego Computer and Communications Law Queen Mary University of London. Doktorantka prawa oraz absolwentka Wydziału Prawa i Administracji UW, Wydziału Zarządzania UW oraz Wydziału Ekonomii University of Skovde w Szwecji. Członkini Chartered Institute of Arbitrators w Londynie (tytuł MCIArb). Mediatorka sądowa wpisana na listę Sądu Okręgowego w Warszawie oraz w Krakowie. Uczestniczka szkoleń zawodowych z zakresu rozwiązywania sporów dotyczących własności intelektualnej i nowychtechnologii w World Intellectual Property Organization (WIPO) w Genewie. Autorka publikacji z zakresu rozwiązywania sporów w języku polskim i angielskim oraz uczestniczka międzynarodowych konferencji naukowych.

35

chcesz układać puzzle w

?

inżynierii wymagań

razem z nami

Facebook

Linkedin

http://www.facebook.com/ reqmagazyn

Reklama

www.linkedin.com/groups/ Stowarzyszenie-Inżynierii- czasopismo@wymagania.org.pl Wymagań-7464107

Współpraca

Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: czasopismo@wymagania.org.pl