Koniec projektového manažmentu v riadení SW projektov?

Že user story vie (na)písať každý je lajtmotív mojej misie.

Do mojej schránky dorazila otázka:

“Keď bude biznis vedieť sám písať user story, a komunikovať de facto priamo s výrobcom softvéru, potom nebude treba projektových manažérov?”

V striktnom ponímaní lean a agile všetko ostatné okrem kódovania (t.z. aktivity, ktoré netvoria softvérový produkt) sa považuje za odpad (waste, overhead). V tejto optike niekto (projekťák) kto pripomína prioritu úloh, prestavuje dátum splnenia, sa javi ako veľmi nepotrebný člen tímu.

Čo?! Ok, neni to take čiernobiele, tak čítaj ďalej. Všetci hardcore agilisti, hlavne extrémni programátori (xP), nemusia pokračovať v čítaní ďalej. Pre nich však mám posolostvo, že  ja vidím zmysel v tom, aby sme sa hrali najprv so slovami (písali user stories, dizajnovali procesy) a kreslili procesné diagramy, mockovali hrubé prototypy (breadboarding), až potom išli kódiť.

Osobne si myslím, že niektorí súčasní projekt manažéri softvérových projektov budú konvertovať k produktovým vlastníkom (PO - product owner). Hlavne tí, ktorí inklinujú viac k tomu, čo riešime, nie ako zabezpečíme zdroje (na riešenie).

PO je špecifická rola v metodike SCRUM. Častovať niektorých PO produktovými manažérmi môže byť overkill alebo urážka produktových manažérov. Každopádne produktový manažér je strategická rola, PO je taktická rola. Stále platí, že to môže byť tá istá osoba. PO je zvyčajne osoba ktorá robí prepojenie medzi biznisom a IT, a varí user stories.

Od projektu k produktu

Rola projekťáka sa transformuje do role odstraňovača prekážok. Úspešných self managed tímov nebude (zatiaľ) až tak veľa, a keď príde na to, že:
a) treba pritlačiť a niečo presadiť u C-level,
b) treba sa zbaviť nejakého neproduktívneho člena tímu,
všetci tieto “manažérske” úlohy, radi odovzdajú na vyriešenie niekomu inému.

Riešiteľský tím si žije v tak kvalitnej bublinke, akú im dokáže manažér zabezpečiť.

Ako sa priblížiť k agilnému a lean prístupu?

Pre firmu, ktorej hlavným produktom/službou nie je IT produkt/služba, vieš aplikovať metodiku SCRUM (presne podľa príručky) len v prípade in-house vývojárskeho tímu. Ak IT službu obstarávaš od dodávateľa, je treba sa prispôsobiť. Ideálne je sa tomuto scenáru (mať inhouse tím vývojárov) približovať, ale to nie vždy je možné.

Agilné metodiky nepoznajú rámcovanie projekt. Organizácie práce sa točí okolo priebežného došpecifikovávania eposov (epic) do detailnejších user stories, požiadavka na to, aby user stories po doručení v rámci šprintu (časové ohraničenie pre vývoj) mali aj biznis hodnotu (rešpektovali tzv. definition of done).

Odporúčam každému projektovému manažérovi, aby dĺžku projektov vedome skracoval, čo má potom vplyv na to, že zásadné otázky, ktoré riešim ako projektový manažér (viď tabuľka), majú menšiu váhu, preto môžu napáchať menej škody.

Aby som však neriešil diskonektnuté mini projekty, potrebujem víziu produktového vlastníka, ako tieto (mini) projekty na seba nadväzujú (ako sa dopĺňajú) - roadmapu. V SCRUme produktový vlastník túto víziu preberá od C-level manažérov. Alebo sami C-level manažéri sú produktovými vlastníkmi.

Projekt v kontexte vývoja digitálneho produktu je vlastne vedomé rámcovanie toho, ako plánované vylepšenie (inkrement, deliverable) na produkte dosiahnem. Medzi hlavné atribúty projektu patri čas (zostáva kvalita a peniaze). Planovať na dlhé obdobie a myslieť si, že ten plán splním je naivné. A ešte horšie je, keď potom všetko prispôsobujem tomu, aby som ten plán (čas naplnil).

Čím chceš byť?

Ak som ti dnes pomohol odpovedať na otázku, čím chceš byť, keď budeš veľký, tak som trafil týmto článkom klinec po hlavičke. Uvedomenie si zodpovedností a kompetencií spomínaných rolí a zameranie sa na jednu z nich prinesie lepšie konečné výsledky. Never tomu, že generalistov ako MacGyver čaká svetlá budúcnosť. Tá čaká T-shaped špecialistov. 😄