Dawno temu (około 2001 roku) w prężnie rozwijającym się startupie (ok. 200 osób naówczas), znanym szerzej jako Google - Larry Page (co-founder), jako jeszcze mało opierzony CEO wymyślił, że zwoła zebranie dla wszystkich, którzy na firmowej wizytówce mają stanowisko manager (czy project manager). No i jak już ich zwołał to poinformował wszystkich, żeby już sobie poszli (z firmy) i nie zakłócali pracy inżynierom. "Zatrudniamy najlepszych z najlepszych, najtęższe umysły branży IT", miał uzasadniać Larry. "Tacy ludzie spojojnie ogarną sobie te wszystkie managerskie rzeczy, a raportować będą do mnie".
Eksperyment zakończył się paroma zaskakującymi (głównie dla Larry'ego) wnioskami:
- Ponieważ cała zabawa miała skrócić dostęp inżynierów do Larry'ego, to coraz więcej osób przychodziło do niego po decyzje, po które kiedyś przychodzili do swoich (project) managerów.
- Dużo spraw, z którymi się zgłaszali były zadaniami typowo administracyjnymi, które wcześniej leżały w gestii managerów średniego szczebla.
- Co więcej, okazało się, że bez osób odpowiedzialnych za dowiezienie tematu i go-live inżynierowie oddawali się jednemu z "inżynierskich grzechów głównych", czyli tzw. "gold plating'owi". Cóż to za zjawisko - w skrócie jest to przeświadczenie, że może warto przesunąć w czasie wypuszczenie produktu, aby dodać jeszcze jeden/dwa ficzery, które sprawią, że rozwiązanie będzie naprawdę genialne. Niestety to zjawisko jest jak spirala śmierci dla produktu, bo bez weryfikacji z klientami / użytkownikami te wszystkie dodatkowe ficzery mogą być zupełnie niepotrzebne i nie generować żadnej wartości (a wręcz powodować straty). W każdym razie projekty przestały kończyć się na czas, a niektóre sprawiały wrażenie, że nie skończą się nigdy.
Konsekwencje eksperymentu były następujące:
- inwestorzy Google'a wymusili znalezienie profesjonalnego CEO (zdaje się wtedy wjechał na białym koniu Eric Schmidt, który przejął stery na długie lata)
- pół roku po pamiętnym spotkaniu firma ponownie zrekrutowała middle management i kierowników projektów
Sentyment, którym kierował się Larry jest częsty wśród specjalistów IT, w szczególności zajmujących się tworzeniem oprogramowania. Specjaliści często nie widzą wartości w posiadaniu kierownika projektu w zespole.
"Po co mi ten kierownik projektu? Sam(a) ustalę wszystko co jest do zrobienia lepiej, bez pośredników".
I wszystko niby fajnie - jeśli realizujemy projekt, który po stronie IT zajmuje w całości pracę tylko jednej osoby. Wtedy rzeczywiście wystarczy bezpośrednia współpraca pomiędzy użytkownikiem biznesowym, a programis(-tą/-tką). Tak z doświadczenia powstają najlepiej dopasowane funkcjonalnie rozwiązania.
Jednak jeśli projekt wymaga zaangażowania większej liczy osób, potrzebne jest skoordynowanie działań projektowych z innymi równoległymi projektami, dostawcami zewnętrznymi, działem QA, dziełem UX, DevOps'ami, adminami, komunikację z interesariuszami (jak np. zarząd) to ktoś, kto zajmie się tymi wszystkimi czynnościami dookoła jest niezbędnym elementem układanki. Dodatkowo, gdy dochodzą jeszcze kwestie związane z terminowym dostarczeniem rozwiązania (bo od tego zależą w łańcuchu powiązań inne działania w firmie, jak np. kampania promocyjna rozwiązania, która musi zostać uruchomiona w danym momencie roku, bo inaczej nie będzie miała sensu), a całość ma się zamknąć w sensownym budżecie, to bez kierownika projektu robi się coraz trudniej.
Jeśli mamy jakiś zespół, który zwiększa swoją liczebność, to dochodzą kolejne zagadnienia:
- informacja zwrotna
- rozwój członków zespołu
- rozwiązywanie konfliktów (wewnątrz zespołu i ze światem zewnętrznym)
- "zwykła" administracja: urlopy, szkolenia, umowy, podwyżki, ...
I tej pracy, której raczej na siebie nie wezmą specjaliści od IT / architekci / programiści, robi się więcej i więcej.
A więc, czy manager (projektów) w IT to zło konieczne, finansowa ekstrawagancja, czy wartościowy członek zespołu i organizacji?
Odpowiadając na to pytanie, wbrew przeświadczeniu i sentymentom niektórych (wielu?) osób, dobry manager (bo wiadomo, że nie mówimy o kiepskich ) to nie finansowy i komunikacyjny narzut dla działań projektowych, czy operacyjnych zespołu, a raczej jeden z ważnych składników udanych realizacji i sprawnego działania firmy.