Czy to wprowadzenie do gry RPG?

Niestety nie. Tak rozpoczyna się wiele projektów IT. Przez ostatnie 10 lat byłem na niezliczonej ilości takich spotkań. Zarówno w Polsce, jak i w zachodniej Europie i Skandynawii, w małych firmach i wielkich międzynarodowych korporacjach, wszędzie przebieg tych spotkań był bardzo podobny:

1. Nakreślenie ambitnej, ale mało precyzyjnej wizji (np. Nasz nowy produkt sprawi, że staniemy się liderem na rynku e-usług handlowych.).
2. Dyskusja na temat rozwiązań i pomysłów, bez jasno określonych wymagań projektu (rozmowa dotyczy tego jak coś chcemy zrobić, bez zrozumienia jaki problem chcemy rozwiązać, czyj to jest problem i dlaczego istnieje).
3. Z góry przyjęte założenia dotyczące wykorzystania określonej technologii, wzorców projektowych oraz rozwiązań (To musi być aplikacja mobilna na iOS z dużą i użyteczną wyszukiwarką na środku ekranu!).
4. Brak świadomości, że poza użytkownikami i klientami jest cała sieć interesariuszy, którzy mogą w każdej chwili ujawnić swoje krytyczne wymagania i doprowadzić do sporych problemów w projekcie.
5. Z góry przyjęte założenia na temat cech i wymagań interesariuszy (częste używanie stereotypów (np. na temat roli społecznej, płci, wieku, czy znajomości technologii) i uogólnień (np. wszyscy ludzie tak robią, nikt z tego tak nie korzysta, większość tak myśli).

Powyżej wymieniłem tylko kilka głównych błędów, które pojawiają się podczas planowania projektów.

No dobrze, ale jakie ryzyko wiąże się z takim planowaniem? Są to często utopione miliony euro na produkt, który nie ma sensu, oraz tysiące godzin zmarnowanego ludzkiego potencjału, który można by twórczo wykorzystać.

Czy jest zatem przepis, który gwarantuje sukces projektu?

Uważam, że nie ma złotych zasad, których przestrzeganie zapewni 100% sukces. Natomiast wiem, że istnieją sprawdzone zasady, które pomagają lepiej radzić sobie z bardzo złożonymi problemami (takimi jak np. projekty IT), szybko identyfikować źródła ryzyka oraz maksymalizować szanse sukcesu.

Poniżej przedstawiam główne zasady, których nauczyłem się od Toma Gilba i którymi kieruję się planując i realizując projekty (zarówno te IT, jak i konferencje, czy projekty wzornicze).

1. Rozpoczynaj projekt od analizy interesariuszy.Gdy realizujemy projekt, to zmieniamy kawałek otaczającej nas rzeczywistości. W tej rzeczywistości funkcjonują interesariusze (osoby, normy społeczne, przepisy, etc.), którzy mają wpływ na nasze działania, jak również na których nasze działania będą bezpośrednio, bądź pośrednio wpływać. Każdy z tych interesariuszy, jak sama nazwa wskazuje, ma do nas jakiś interes (wymaganie). Jeżeli nie przeprowadzimy analizy interesariuszy na samym początku projektu, a potem nie będziemy jej sukcesywnie pogłębiać, to może się okazać, że w pewnym momencie pojawi się interesariusz, którego krytyczne wymaganie nie zostało przez nas uwzględnione. W wielu przypadkach może się to okazać przyczyną sporego opóźnienia, a nawet porażki projektu.
2. Zastanów się, jaką wartość dostarczysz każdemu z interesariuszy. Po określeniu interesariuszy warto zadać sobie pytania: Jakie są wymagania interesariuszy wobec mojego projektu? Jaką wartość dostarczę każdemu z interesariuszy w ramach realizowanego projektu? Którzy z interesariuszy są krytyczni w tej chwili, bym mógł rozpocząć projekt? Często na tym etapie warto włączyć badaczy (UX) i/lub analityków biznesowych, którzy dostarczą wartościowych danych na temat interesariuszy.
3. Nie pisz poezji, tylko inżynierskie wymagania. Krytyczne wymagania należy kwantyfikować, czyli nie opisowo, a ilościowo definiować wartość, jaką chcemy dostarczyć interesariuszom. Wykorzystanie języka naturalnego np. notacji User Stories wiąże się m.in. ze zbyt szeroką możliwością interpretacji, co może wprowadzić sporo zamieszania w projekcie. Precyzyjnie określone wymagania krytycznych interesariuszy to podstawa, by rozpocząć projekt i wiedzieć, co, na jakim poziomie jakości i na kiedy ma zostać zrealizowane. Przykład: User Story: Jako kierowca chcę szybko wezwać pomoc, gdy zobaczę wypadek na drodze. Wymaganie skwantyfikowane: Nasz system ma umożliwić, by 95% zauważonych przez kierowców w każdym miesiącu wypadków na drodze było zgłoszonych w ciągu 5 sekund od chwili ich zauważenia.
4. Przeanalizuj możliwe rozwiązania, zanim zdecydujesz się coś wybrać. Bardzo częstym problemem projektów jest to, że technologia, w której projekt będzie realizowany albo konkretny pomysł na rozwiązanie są forsowane od samego początku, bez zastanowienia się, czy to jest właściwa strategia. Skąd wiadomo, że dane rozwiązanie jest najlepsze i co oznacza najlepsze? W celu doboru najlepszych rozwiązań, które pozwolą dostarczyć wartość interesariuszom, z uwzględnieniem zasobów, jakimi dysponujemy polecam korzystać z Impact Estimation Table, która powinna być w narzędziowniku każdego, inżyniera, Project Managera, czy Product Ownera!
5. Podziel projekt na krótkie etapy dostarczania wartości. Szczegółowe plany na zbyt długi czas, to strategia bardzo ryzykowna. Świat nie stoi w miejscu, dlatego też plany musimy adaptować do dynamicznie zmieniających się warunków i okoliczności. Rozsądną strategią planowania jest podział projektu na krótkie (np. tygodniowe albo dwutygodniowe) cykle dostarczania wartości. Ważne, by każdy cykl kończył się dostarczeniem mierzalnej wartości interesariuszom oraz wyciągnięciem odpowiednich wniosków, które będą stanowiły wkład w kolejny cykl.
6. Mierz dostarczaną wartość. Jeżeli jesteś w stanie zmierzyć wartość, którą dostarczasz interesariuszom, to istnieje spora szansa, że faktycznie tworzysz wartość (i potrafisz to wykazać). Jeżeli natomiast tylko mówisz, że dostarczasz wartość, pokazując kolejne funkcjonalności, czy produkty, bez umiejętności zmierzenia jak przekłada się to na interesariuszy, to bardzo możliwe, że wytwarzana przez Ciebie wartość to ułuda i za moment okaże się, że realizujesz projekt, który nie kreuje żadnej nowej wartości. Jak powiedział Lord Kelvin:
   

   „When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind.”.

7. Wyciągaj wnioski i podejmuj decyzje. Jeżeli pracujesz w krótkich cyklach, mierzysz dostarczaną wartość oraz na bieżąco analizujesz koszty projektu, to masz większe możliwości, by precyzyjniej określać, czy realizujesz przyjęte cele projektowe, czy potrzebna jest korekta Twoich planów. Realizowane projekty to proces ciągłej nauki, która wymaga z jednej sprawnego i mądrego planowania i działania, a z drugiej strony wyciągania wniosków i podejmowania decyzji.

Evolutionary Value Delivery Cycle

Jeżeli projekty, w których uczestniczycie już trwają, to wdrożenie nawet małych usprawnień w procesie będzie lepszą strategią, niż nie zrobienie niczego, lub rozpoczęcie projektu od początku. Ewolucja ma większy współczynnik sukcesu, niż rewolucja, dlatego polecam nie czekać zbyt długo na wdrożenie powyższych zasad, tylko zacząć stosować je od zaraz.

Jeżeli jesteście zainteresowani szczegółowym poznaniem opisanych powyżej zasad i narzędzi, a przede wszystkim uratowaniem bieżącego lub kolejnego projektu, w którym będziecie uczestniczyć, to zapraszam Was na listopadowe szkolenie prekursora Agile – Toma Gilba do Warszawy , który przez 5 dni bardzo szczegółowo i praktycznie omówi powyższe zagadnienia i podzieli się z Wami 60 latami swoich doświadczeń pracy w IT.