Metodyki zwinne zdominowały IT. Jak świat długi i szeroki, ludzie szkolą się na product ownerów i scrum masterów. Tradycyjne podejścia do projektów informatycznych są w odwrocie. Zamiast harmonogramów królują dziś burndown charty i kanban boardy. Klasyczny waterfall jest krytykowany za brak elastyczności - ociężałe reagowanie na zmiany i małe zaangażowanie zespołów skutkuje notorycznym przekraczaniem harmonogramu, budżetu i niezadowoleniem klienta. PMP czyli certyfikacja Project Management Professional, prowadzona przez amerykański Project Management Institute, przez wielu kojarzona jest właśnie z tradycyjnym, kaskadowym podejściem do projektów informatycznych. A przecież we współczesnym świecie nie potrzeba już project managerów, a scrum masterów, prawda?
Nie do końca. Poniższy tekst wyjaśnia jak niezrozumienie roli project managera oraz założeń certyfikacji PMP może prowadzić do powyższych, błędnych wniosków. Napiszemy o tym, co robi project manager a co nie jest zadaniem scrum mastera oraz o czym tak naprawdę jest Project Management Body of Knowledge (merytoryczna podstawa do PMP). Zapraszam do lektury!
Czy Scrum nie lekarstwem na wszystko?
Dział IT pewnej średniej wielkości firmy z branży farmaceutycznej zdecydował się na przejście na zwinne wytwarzanie oprogramowania. Zatrudniony został scrum master oraz product owner, który miał być reprezentantem biznesu. Firma zdecydowała się na rozbudowę swojego systemu CRM wewnętrznymi siłami. Product owner przystąpił do pracy, robiąc wywiad wśród jednostek biznesowych i przygotowując backlog user stories według swojego zrozumienia potrzeb.
Prace nad projektem postępowały sprawnie, wszyscy byli zadowoleni z przejścia na zwinny model. Scrum master poprawnie poprowadził spotkania daily, planowania, retrospekcje. Product owner na bieżąco weryfikował nowe funkcjonalności oraz zarządzał backlogiem. Mógł się na tym skupić, gdyż nie był wyrywany do bieżącej pracy operacyjnej działów biznesowych. Dyrektor działu sprzedaży również był zadowolony, gdyż nikt nie odrywał jego ludzi od aktualnych zadań. Było to dla niego szczególnie istotne, gdyż był to ostatni kwartał roku księgowego - dział sprzedaży pracował w pocie czoła nad osiągnięciem rocznych celów.
Gdy nadszedł nowy rok księgowy, dział sprzedaży odetchnął. Jego dyrektor zapragnął zobaczyć, co do tej pory wytworzył dla niego dział IT i bardzo się rozczarował. Niestety okazało się, że zatrudniony product owner nie zrozumiał dobrze potrzeb biznesowych. Wytworzone funkcjonalności odpowiadały wizji product ownera, ale ta nie pokrywała się z faktycznymi wymaganiami działu sprzedaży. Projekt okazał się porażką a prace trzeba było zaczynać od nowa...
Kluczowe jest zarządanie projektem
Powyższa fikcyjna historia ilustruje co może się wydarzyć, jeśli firma skupi się tylko na metodologii scrum, zapominając o faktycznym zarządzaniu projektem, w tym interesariuszami, komunikacją i ryzykami. Scrum master wykonał właściwie swoją pracę. Jego zespół scrumowy nie napotkał większych przeszkód. Product owner wykonywał też swoje obowiązki zgodnie z procesem scrumowym. Kto zatem zawinił? Można powiedzieć, że product owner powinien był na bieżąco sam prosić dział sprzedaży o dodatkowe weryfikowanie nowych funkcjonalności. Faktycznie jednak problem był bardziej globalny - zabrakło faktycznego zaangażowania kluczowego interesariusza - dyrektora działu sprzedaży. Nikt nie zwrócił uwagi na oczywiste ryzyko wynikające z faktu, że product owner był świeżo zatrudnioną osobą, zewnętrzną wobec działu, który miał reprezentować. Zabrakło zarządzania projektem.
Powtórzmy: naczelnym zadaniem scrum mastera jest dbanie o przebieg procesu scrumowego, organizowanie i czuwanie nad przebiegiem spotkań (daily scrum, retrospekcja, sprint planning itd.), właściwym używaniu narzędzi (kanban board). Owszem, jego zadaniem jest także ochrona zespołu scrumowego przed czynnikami zewnętrznymi i usuwanie przeszkód, niemniej scrum master i w ogóle scrum koncentruje się na samym etapie wytwarzania oprogramowania, nie na realizacji celu biznesowego.
Właśnie ten aspekt jest tutaj kluczowy. Niezaprzeczalnie programowanie jest esencją i największą częścią współczesnego IT, ale projekt informatyczny bywa pojęciem o wiele szerszym. Zanim zespół scrumowy rozpocznie prace, trzeba zebrać interesariuszy i upewnić się, że cel, wysokopoziomowe wymagania oraz uzasadnienie biznesowe są znane i akceptowane przez kluczowe osoby. Potem określić ramową architekturę rozwiązania, kamienie milowe oraz podjąć decyzję: outsourcing czy własne zasoby ludzkie. Wreszcie: wyznaczyć product ownera, scrum mastera i członków zespołu scrumowego, czasami też zorganizować ich kolokację w jednym miejscu. I te wszystkie aktywności koordynuje właśnie kierownik projektu. Jeśli zespół programistyczny pochodzi z zewnątrz firmy, project manager dodatkowo bierze udział w procesie zakupowym, zbierając wkład techniczny do zapytania ofertowego, koordynuje merytoryczną ocenę ofert.
Dopiero po tych wszystkich etapach zespół scrumowy może rozpocząć prace.
Poniższe zestawienie przedstawia kluczowe różnice między zarządzaniem projektem, a zarządzaniem wytwarzania oprogramowania według metodyk zwinnych:
Widzimy więc, że rola kierownika projektu i samo pojęcie zarządzania projektem jest niejako bardziej ogólną kategorią od zwinnego wytwarzania oprogramowania. Z punktu widzenia projektu, programowanie jest jednym z obszarów/pakietów zadań (ang. work package), ale nie jedynym. I na takim właśnie szeroko pojętym zarządzaniu projektami skupia się Project Management Body of Knowledge. Jest to zespół dobrych praktyk stworzony przez amerykański Project Management Institute. Co bardzo ważne i niekiedy mylone, PMBoK nie narzuca sposobu realizacji projektu - nie mówi w żaden sposób by robić to zwinnie, kaskadowo lub hybrydowo. Stwierdza, że model realizacji powinien być dostosowany do potrzeb projektu.
PMBoK nie narzuca sposobu realizacji projektu. Stwierdza, że model realizacji powinien być dostosowany do potrzeb projektu.
PMBoK definiuje 49 procesów zarządzania projektem. Są to de facto czynności, które powinien wykonywać kierownik projektu. Część ma charakter jednorazowy (np. stworzenie karty projektu), część powtarzalny (np. kontrola jakości), a część ciągły (np. monitorowanie ryzyk). PMBoK klasyfikuje te 49 procesów w 10 obszarach wiedzy (m.in. ryzyko, zakres, czas, koszt, jakość, zasoby, komunikacja) ale też w 5 procesów: inicjacja, planowanie, realizacja, monitorowanie i kontrola, zamykanie. I to być może właśnie podział na te 5 grup procesów może konfundować i sprawiać wrażenie kaskadowości (najpierw inicjacja, potem planowanie, następnie realizacja, co stoi w pewnej sprzeczności z podejściem zwinnym, gdzie planowanie przeplata się z realizacją). Jest to błędna interpretacja! Wspomniane 5 grup procesów jest wydzielonych tylko ze względu na logiczne przyporządkowanie. PMBoK jednak w żaden sposób nie sugeruje, że całe planowanie musi być zakończone przed rozpoczęciem realizacji. Więcej - PMBoK mówi wprost, że grupy procesów mają prawo się przenikać i nakładać. I to właśnie zadanie project managera jest dobrać odpowiedni zestaw czynności, adekwatny do danego rodzaju projektu.
Skoro wiemy już, że klasyczne zarządzanie projektem nie stoi w sprzeczności z podejściem zwinnym, warto zadać sobie pytanie - czy warto aspirować do certyfikacji PMP? Jeśli jesteś scrum masterem, pracujesz w kilkuosobowej firmie, rozwijacie własny produkt w sposób ciągły, a nie projektowy, bądź macie zespół pracujący na zlecenie, a Ty chcesz pozostać w takim obszarze specjalizacji, wtedy zgłębianie zarządzania projektami nie ma dla Ciebie sensu. Jeśli jednak pracujesz dla organizacji prowadzącej projekty, w których wytwarzanie programowania jest tylko częścią większej całości oraz interesuje Cię kariera zarządcza, wtedy nauka dobrych praktyk zarządzania projektami może być właściwą drogą, wówczas warto zainteresować się szkoleniami, które pomogą Ci zdobyć certyfikację PMP. Sprawdź nasze szkolenie z tego tematu
