Twój projekt się opóźnia i nie wiesz co robić, więc dodajesz nowych programistów? Myślisz, że więcej osób ukończy projekt szybciej? – nic bardziej mylnego. Zobacz jakie ta decyzja niesie ze sobą ryzyka oraz jak rozwiązać ten problem minimalizując je.
W każdym projekcie IT istnieją bardziej i mniej nerwowe sytuacje. Często najbardziej stresującą sytuacją dla kierownika projektu jak i jego członków jest opóźnienie projektu. Zdarza się, że jeżeli z tego kryzysu są wyciągane konsekwencje – ludzie w nerwach obwiniają się wzajemnie. Często może wyglądać to mniej więcej tak:
CEO: Kierowniku projektu, dlaczego nie ukończyłeś projektu na czas?
PM: Programiści, dlaczego zadania się opóźniały?
Programiści: Kierowniku projektu, projekt był źle zarządzany bo… [xyz]
PM: CEO, miałem za mało zasobów by ukończyć projekt!
Tzw „odbijanie piłeczki”. Szef ma pretensję do kierownika projektów, który obarcza winą programistów. Oni z kolei zarzucają złe zarządzanie projektem argumentując to. Natomiast często kierownik projektu wraca z powodem do szefa – dlaczego projekt był opóźniony.
Często wnioskiem takiej sytuacji jest to, że do opóźniającego się projektu należy dołożyć zasoby. Argumentem popierającym tą tezę jest to, że więcej osób skończy projekt szybciej bo więcej pracy może być wykonanej równolegle. To tak jak w tym kawale…
Kierownik projektu to osoba, która uważa, że 9 kobiet urodzi dziecko w miesiąc.
Ja bym to porównał do sytuacji, w której znajdujemy się na tonącym statku i zamiast zatkać dziurę, którą dostaje się woda – skupiamy się na wylewaniu wody za burtę. W takiej sytuacji zamiast pracować mądrzej (i krócej) wybieramy pracę dłuższą (i mniej mądrą).
Tymi przykładami, chcę powiedzieć, że w sytuacji gdy projekt się opóźnia – dodanie nowej osoby, nie jest rozwiązaniem. W większości przypadków tylko opóźni termin ukończenia projektu. Dlaczego tak się dzieje? – wyjaśnienie poniżej.
Projekty IT różnią się od projektów z innych branż np budowlanej czy wykończeniowej. Jeśli remont mieszkania się opóźnia bo jest jeden malarz ścian i wiele pokoi to dokładając kolejnego malarza prawdopodobnie uda nam się ukończyć remont wcześniej. Dzieje się tak dlatego, że nowy malarz od pierwszej minuty pracy staje się produktywny. Czyli jego praca ulega konwersji na osiąganie celu projektu. W tym przykładzie to działa bo każdą ścianę maluje się tak samo – bez względu od mieszkania czy farby (ogólnie rzecz biorąc), trzeba też wspomnieć, że zdecydowana większość osób potrafi malować ściany.
Taka rzeczywistość nie występuje w projektach IT – dobra znajomość technologii nie zapewni ci bycia produktywnym od pierwszego dnia w każdym projekcie, w którym jest użyta technologia, którą znasz. Wraz z poziomem skomplikowania i wielkością projektu czas wdrożenia nowego programisty się wydłuża i nie jesteś w stanie tego ominąć.
Nowa osoba musi zdobyć wiedzę, którą mają inni członkowie zespołu. Siłą rzeczy osoba szukająca wiedzy będzie pytała zespół: „jak rozwiązać ten problem?”. Pamiętaj, że odpowiedź na pytanie, przeanalizowanie problemu, znalezienie rozwiązania i przekazanie go zajmuje czas. Tak więc twój „nowy zasób” będzie absorbował czas (którego i tak brakuje) produktywnym członkom zespołu. Może wystąpić sytuacja, że dokładając nowego programistę nie tylko nie przyśpieszysz prac, ale jeszcze je zwolnisz.
Musisz sobie zdawać sprawę z tego, że wraz z rozmiarem zespołu rośnie czas zarządzania tym zespołem. Więcej ludzi = więcej problemów. Wyobraź sobie sytuację, w której dokładasz trzy nowe osoby… wtedy pomnóż te problemy przez 9.
jak żyć?
Opisałem możliwe problemy, które mogą wiązać się z dodaniem nowego zasobu do projektu, ale nie napisałem rozwiązania problemu. Jeżeli dodanie nowego zasobu w twoim przypadku powoduje ryzyko powiększenia opóźnienia projektu spróbuj bardziej zaangażować produktywne zasoby. Motywatorem może być zwiększone wynagrodzenie w związku z dodaniem dodatkowej godziny lub dwóch pracy dziennie. Można też spróbować pracy w weekendy. Wiem, że brzmi to nieciekawie i taki stan rzeczy na pewno nie może być długotrwały. Kolejną kluczową rzeczą w tym układzie jest to, żeby to było dobrowolne, kierownictwo nie może naciskać by wymusić pracę po godzinach lub w weekendy. Jeśli część zespołu się nie zgodzi na ten układ, nie powinieneś dać im odczuć dyskomfortu – nie ma mowy o szantażach emocjonalnych. Taki stan rzeczy wynika najczęściej z błędów z zarządzania projektami, nie wymuszajmy więc pokuty na developerach.
Podsumowanie
Nie zrozum mnie źle – nie mówię, że w każdej sytuacji podczas opóźnień dołożenie zasobów jest czymś złym. Istnieją sytuację, w których dodanie nowych programistów do projektu ratuje sytuację i działa lepiej niż zaangażowanie istniejącego zespołu na większy wymiar pracy. Świat nie jest czarno biały. Natomiast wiem z doświadczenia, że często dodanie nowego zasobu do projektu wydłuża czas opóźnienia zamiast przyśpieszyć czas realizacji. Stojąc przed takim problemem przeanalizuj najpierw czy mogą wystąpić ryzyka, które opisałem powyżej.
Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze lub LinkedIn lub subskrybuj mój kanał YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).
Karol Wójciszko 
Błędne myślenie młodej kadry kierowniczej, który myśli że wszystko można przełożyć na liczby 🙂
Dodanie do projektu programisty, który pracował wcześniej z pozostałymi ludźmi w zespole może się udać w dużej części przypadków. Potrzebna wiedza szybko zostanie przekazana. Ludzie wiedzą czego mogą się po sobie spodziewać. Pewne „konwencje” zarówno w kodzie jak i w samym procesie pracy nad projektem zostaną zachowane.
Najgorszy scenariusz moim zdaniem to dodanie całkiem nowego ambitnego programisty z zewnątrz w momencie kiedy jest naprawdę gorąco. Pozostali mają zbyt dużą spinę więc wiedzą dzielą się zdawkowo.
Co robi taki świeży pracownik? Stara się sprostać wymaganiom za wszelką cenę – wiadomo „świeżak”, często na umowie próbnej musi się wykazać. I choć często tak nie jest to jednak mózg płata figla i tacy nowi ambitni pracownicy wpadają w taką pułapkę pod tytułem: „dam radę choćby nie wiem co”.
Efekt – klęska w 2 obszarach:
1) BŁĘDY W PROJEKCIE – dublowanie się części rzeczy, słaba jakość kodu, dług tech. I choć na pierwszy rzut oka wszystko działa ok to jednak niezrozumiałe błędy pojawią się wcześniej czy później na produkcji. A projekt w dalszej fazie rozwoju mocno zwolni tempo. W następstwie niezadowolenie kierownictwa/słabe wyniki finansowe murowane.
2) SAMOPOCZUCIE NOWEGO PROGRAMISTY – średnie bo pracował pod dużą presją i ma świadomość, że to co zrobił mógł zrobić dużo lepiej gdyby tego czasu miał więcej. Przy nadarzającej się okazji znika a w jego miejsce do projektu przychodzi nowy… „świeżak” i pętla się zaciska
Jeszcze jedna uwaga słowo „świeżak” nie używam tu z pogardą. Wręcz przeciwnie, mocno szanuję za odwagę dołączenia do nowej grupy w ciężkim momencie projektu.
PolubieniePolubienie
Dzięki za komentarz!
Zgadzam się z tym, że od wiedzy projektowej ważniejsze jest zgranie zespołu.
Imho bardzo dużo rzeczy można przełożyć na liczby – tyle, że często jest zbyt wiele czynników, które musimy uwzględnić, że staje się to bardzo trudne 🙂
PolubieniePolubienie
Dokładnie tak, my to wiemy, management nie bardzo 😉 Mamy takich ambitnych świeżaków, zwykle dokładają 2 nowe bugi na 1 rozwiązany (zwykle w tragiczny sposób), nagle code review znowu stało się standardem, skończyło się zaufanie 😉 no i projekt ekstremalnie zwolnił…
PolubieniePolubienie
Zgadzam się z prawie wszystkim – poza nadgodzinami – w dobrym projekcie z potrójnym buforem szacowania nie powinny one mieć miejsca 😉
PolubieniePolubienie
Duża wielkość buforu nie zapewnia ukończenia w terminie. W skrócie – czym większy bufor tym bardziej jest marnowany. Czasami ciężko wyegzekwować od klienta „duży” bufor.
Imho z nadgodzinami nie ma żadnego problemu jeśli dwie strony się na nie godzą – często zdarza się, że programista chce dorobić ekstra pieniądze. Natomiast (tak jak pisałem) – jestem przeciwnikiem wymuszania nadgodzin na programistach i stosowania szantażu emocjonalnego żeby ktoś pomógł po godzinach. 🙂
PolubieniePolubienie