Project Manager, więc kto? Analityka, czyli definiowanie zakresu projektu
Jest to trzeci artykuł z cyklu Project Manager, więc kto., jeżeli nie czytałeś/aś od początku to zachęcam do przejścia na stronę Project Manager, więc kto? Wstęp.
Rola project managera może być skrajnie różna w zależności od firmy. Często stanowiska nazywane zwrotem “project manager” - nie są dla project managerów. Seria artykułów będzie zawierać pewne uproszczenia i ograniczony kontekst.
Ten artykuł nie jest o analityce.
Czym jest projekt?
Słowo projekt jest jednym z najbardziej nadużywanych określeń XXI wieku. Projekty robi każdy, w każdy możliwy sposób. Co to właściwie jest? Kilka lat temu usłyszałem definicję mówiącą o tym, że jest to zakres działań przeprowadzających nas od pewnego stanu zastanego do stanu docelowego. Wszystko to dzieję się w zdefiniowanych ramach czasowych (ang. deadline), osobowych (ang. people, resources) oraz kosztowych (ang. cost). Anglojęzyczna wikipedia przytacza następującą definicję:
Contemporary business and science treat as a project (or program) any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned (usually by a project team) to achieve a particular aim.
Czym jest zakres projektu (ang. scope)?
Pomińmy większość elementów projektu wspomnianych w poprzednim akapicie i skupmy się na dwóch: stan zastany oraz stan docelowy. Czym w ramach tego jest zakres projektu? Jest to jak najdokładniejsze określenie wymagań, które muszą być spełnione, aby osiągnąć cel projektu. Co ważne, nie jest to lista konkretnych zadań prowadzących do osiągnięcia danego wyniku. Jest to informacja mówiąca o tym co powinno być zrobione, ale nie jak.
Zakres wyznacza ramy, które służą nam w początkowym szacowaniu kosztu oraz czasu realizacji, a także w późniejszym doborze zespołu oraz kontrolowaniu tych parametrów względem zakresu. Te trzy zmienne tworzą tak zwany “magiczny trójkąt” (ang. project management triangle).
Zakres jest parametrem zmiennym i podczas realizacji projektu może być modyfikowany przez tzw. change requesty (z punktu widzenia zarządzania projektami) lub dostosowywanie kierunku w którym zmierzamy (z punktu widzenia zwinnych metodyk wytwarzania).
Uwaga: Świadomie pominęliśmy tu rozbicie zakresu na projektowy i produktowy.
Role wspierające project managera w definiowaniu zakresu
Przed rozpoczęciem projektu definiujemy jego zakres. Zazwyczaj na tym etapie mamy małą ilość danych o tym co i jak będzie wytwarzane. My, jako project managerowanie mamy również ograniczoną wiedzę i umiejętności, i być może nie jesteśmy w pełni kompetentni do samodzielnego zdefiniowania całego zakresu, który doprowadzi nas do osiągnięcia celu projektu.
W takich sytuacjach, w zależności od firmy w której pracujemy możemy posiłkować się wsparciem innych osób. Czasami jest to zespół sprzedażowy, który dostarczył do nas projekt. Czasami jest to architekt / programista. Czasami projektant użyteczności. Czasami analityk. Musimy pamiętać, że w tym procesie nie jesteśmy sami i możemy korzystać ze wsparcia kolegów i koleżanek, prezentujących odmienny punkt widzenia. Wracając do definicji zakresu mówiącej “jak najdokładniejsze określenie” pamiętajmy o tym, że jak najdokładniejsze zdefiniowanie zakresu możemy osiągnąć jedynie przez patrzenie na ten sam problem z różnych perspektyw, korzystając z pomocy ludzi o innych specjalizacjach i innym doświadczeniu. Róbmy to pamiętając, że później zespół lub zespoły projektowe będą musiały go wspólnie z nami zrealizować.
Jeżeli naszym celem byłoby wdrożenie systemu magazynowego o którym wspominaliśmy w poprzednim artykule z serii, to naszym stanem początkowym byłaby firma bez systemu WMS, stanem końcowym wdrożony system WMS, a zakresem wszystko to co musi być spełnione, aby zmienić stan z jednego na drugi.
The worst thing you can do
W roli project managera tak naprawdę nie musimy brać udziału w definiowaniu zakresu projektu. Mamy uprawnienia do delegowania, bo na tym polega nasza rola. Możemy otrzymać zakres projektu od sprzedawców i go po prostu zacząć robić. Możemy poprosić analityka, aby przeanalizował sytuację i przygotował zakres, a my go po prostu zaczniemy realizować. Jest to idealna droga do poniesienia porażki w ramach zarządzania takim projektem… droga, którą kiedyś zdarzyło mi się podążać.
Jak można kontrolować projekt w ramach którego znamy tylko cel, ale nie wiemy jak go osiągnąć? W przeszłości współpracowałem z project managerami po stronie klientów, których zarządzanie opierało się na przeczytaniu listy kamieni milowych oraz terminów ich osiągnięcia, ustawienia przypomnień w kalendarzu i wysyłania maili z zapytaniem “czy milestone został osiągnięty?” w dzień pokazania popupu przypominającego o terminie. Niezależnie od stanu faktycznego, wystarczyło napisać “jest ok”, aby manager został zaspokojony.
Stop crying, be a (wo)man
Jeżeli jesteśmy project managerami w wielkiej firmie realizującej projekt za 50 milionów to prawdopodobnie jesteśmy oddaleni od setek osób go wytwarzających. Jeżeli jesteśmy product ownerami w małej firmie to prawdopodobnie jesteśmy bardzo blisko osób realizujących dany projekt. Niezależnie od sytuacji w której się znajdujemy - musimy znać zakres projektu. Bez tego prosimy się o porażkę, stres oraz wychodzenie na niekompetentnych w kontaktach z interesariuszami i zespołami.
Sposoby definiowania zakresu
Jeżeli musimy znać zakres to jak go zdefiniować? Tak jak wspomnieliśmy w akapicie o rolach wspierających jego definiowanie - może to zostać osiągnięte na wiele różnych sposobów. Przedstawiając dwie skrajności: możemy wykonać głęboką analizę, której wynikiem będzie szczegółowa dokumentacja lub możemy skorzystać z lekkich metod znanych w świecie agile. Ten artykuł jest zdecydowanie za krótki, aby omówić jedną czy drugą. Przytoczę jednak dwa źródła z którymi warto się zapoznać.
Pierwszym z nich jest analiza biznesowa i systemowa, której dobrym przykładem jest działalność Jarosława Żelińskiego. Ze szczegółami można zapoznać się na stronie https://it-consulting.pl/ oraz znajdującym się na niej blogu (po wejściu na stronę trzeba kliknąć w logo :)). Pan Jarosław jest również autorem książki Analiza biznesowa. Praktyczne modelowanie organizacji, którą polecam.
Drugą skrajnością jest np. user story mapping. Jest to metoda pozwalająca nam przy wykorzystaniu ściany oraz kolorowych karteczek zdefiniować tzw. ścieżkę użytkownika oraz elementy prowadzące do osiągnięcia każdego z jej kroków. Dodatkowo, technika ta pozwala nam na bardzo elastyczne i zwinne definiowanie priorytetów oraz kolejnych działań przybliżających nas do realizacji projektu. Wszystko o user story mappingu możecie przeczytać na stronie User Story Mapping - Jeff Patton & Associates.
Kontrola zakresu
Rolą project managera jest kontrola zakresu projektu przez cały czas jego trwania. Dlaczego? Zespół projektowy prawdopodobnie będzie szukał uproszczeń w realizacji celów, a nasz klient będzie dążył do realizacji swoich oczekiwań, które często będą wychodzić poza zdefiniowany zakres (ta strefa działań project managera okreslana jest również jako expectation management). Wyjście poza zakres prowadzi do potencjalnego zwiększenia kosztów projektu i wydłużenia czasu jego realizacji. Naszą odpowiedzialnością jest zarządzanie zakresem, aby osiągnąć wyznaczony cel w ramach zakresu, kosztu, czasu … oraz jakości. Jeżeli te parametry ulegną zmianie, a my odpowiednio tego nie zakomunikujemy i nie skorygujemy to mamy porażkę lub proces sądowy.
Zakres w agile
W ramach serii artykułów Project Manager, więc kto? staram się pojednać ze sobą świat twardego zarządzania projektami, ze światem metodyk zwinnych. Większość tej tematyki zostanie omówiona w ramach artykułów o Prince2 oraz Scrum. Jednak już teraz chcąc uchronić się od negatywnych opinii na temat powyższej treści, muszę wspomnieć o tym, jak ma się zakres projektu do pracy np. w metodyce Scrum, a jak w warunkach skrajnej niepewności.
W przypadku Scruma, odpowiedź jest dość prosta. Scrum jest frameworkiem pracy zespołowej. Nie jest narzędziem do definiowania tego co będziemy robić. W warunkach niepewności, wspiera on jednak ciągłe definiowanie i dostosowywanie zakresu. Z punktu widzenia treści tego artykułu pamiętajmy, że pracujemy nad osiągnięciem pewnego celu. Niezależnie od przyjętych metod - musimy go osiągnąć.
Co możemy powiedzieć o tzw. skrajnej niepewności? Kiedyś byłem na kilku konferencjach dotyczących wytwarzania oprogramowania. Pojawiały się na nich prelekcje porównujące Scruma z Prince2. W mojej ocenie, mówiły o czymś, co było jak porównywanie jabłek z czerwonym młotkiem i zdecydowanie się z nimi nie zgadzałem. Jednak pojawiał się na nich jeden w miarę sensowny wykres ukazujący zasadność wykorzystania metodyk waterfallowych lub agilowych. Prezentował on czas na osi poziomej oraz stopień niepewności na osi pionowej. W sytuacji gdy na realizację “projektu” mamy dużo czasu, ale nasza wiedza jest bardzo mała, a co za tym idzie stopień niepewności jest olbrzymi - jest to miejsce dla metodyk zwinnych. W takiej sytuacji trudno jest zdefiniować zakres. Musimy się liczyć nawet z tym, że po kilku miesiącach pracy warunki biznesowe mogą nas zmusić do wykonania tzw. pivotu. W takich sytuacjach, zazwyczaj mamy jednak świadomość celu, a także dostęp do metryk z których możemy korzystać podobnie jak z technik kontrolowania zakresu, aby w rezultacie - spełnić oczekiwania naszego klienta.
Dla pogłębienia wiedzy o powyższym problemie warto zapoznać się z frameworkiem Cynefin. To o czym chciałbym, abyśmy pamiętali to - unikajmy mówienia “nie da się” - niezależnie od sytuacji w której się znajdujemy w kontekście kontrolowania zakresu. Gdy przychodzą nam takie słowa do głowy, starajmy się wykorzystać dostępną wiedzę i narzędzia do weryfikacji stawianych przez nas kroków, względem celu do którego zmierzamy. Pomóc nam w tym może książka Lean Analytics, którą przytaczam poniżej.
Do posłuchania i poczytania
W celu uzupełnienia wiedzy, która może przydać się w tym obszare prac PMa - zachęcam do zapoznania się z poniższymi podcastami oraz książkami mówiącymi o analizie, Lean Startup, MVP oraz mierzeniu.
- Podcast: Analiza IT. Hania Tomaszewska.
- Podcast: DevTalk #83 – Idea Validation with Pat Flynn. Maciej Aniserowicz.
- Metoda Lean Startup. Wykorzystaj innowacyjne narzędzia i stwórz firmę, która zdobędzie rynek. Eric Ries.
- Minimum viable product. Wikipedia.
- Lean Analytics. Use Data to Build a Better Startup Faster. Alistair Croll, Benjamin Yoskovitz.