Estymacja się nie udała, deadline nas pokonał, nie wyrobimy się. Manager dorzuca ludzi do projektu, ale okazuje się to być gaszeniem pożaru benzyną. Poznajcie prawo Brooksa.
Fred Brooks jest jedną z najbardziej znanych postaci z dziedziny rozwoju oprogramowania. W Polsce nie wiedzieć czemu jest stosunkowo nieznany, a szkoda. Brooks zrobił w życiu dwie wielkie rzeczy – solidnie przyłożył się do rozwoju produktów IBM, w tym OS/360 oraz napisał książkę Mityczny osobomiesiąc. To właśnie z niej, a konkretniej z tytułowego eseju pochodzi prawo nazwane jego nazwiskiem – prawo Brooksa.
Prawo Brooksa mówi:
„dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej”
Bardzo bym chciał, by świadomość tej reguły upowszechniła się nad Wisłą, bo oszczędziłoby to wielu programistom i menedżerom zbędnego stresu…
Dziewięć kobiet nie urodzi dziecka w miesiąc
W eseju opisującym prawo Brooksa, autor rozróżnia zadania na trzy rodzaje:
- zadania idealnie podzielne
- zadania niepodzielne
- zadania podzielne, wymagające komunikacji
Zadania idealnie podzielne
Skręcanie długopisów lub zbieranie szparagów to przykłady zadań idealnie podzielnych. Dzielimy to, co jest do wykonania na części i przydzielamy różnym pracownikom. Nie istnieje potrzeba by się między sobą komunikowali. Chcąc wykonać pracę szybciej możemy wysłać na pole albo do skręcania więcej ludzi. Wyślemy dwukrotnie więcej, dwukrotnie szybciej skończą.
Zadania niepodzielne
Choćbyśmy do wymiany oleju w samochodzie przydzielili pięciu mechaników, to nie zrobią tego szybciej. Olej musi spłynąć, nowy musi być nalany. Nic nie da dodawanie ludzi.
Zadania podzielne, wymagające komunikacji
I tu właśnie dochodzimy do tworzenia programowania. Wykonanie nowej aplikacji wymaga koordynacji między członkami zespołu. Co więcej wymaga również wdrożenia nowych osób.
Poniższa grafika ilustruje, jak lawinowo rośnie potencjalna ilość interakcji w zespole w zależności od ilości członków. Każda interakcja, rozmowa, wymiana wiedzy między dwoma osobami kosztuje czas, czas tym cenniejszy im bardziej spóźniony jest projekt.
Nowi ludzie w projekcie
Najgorsze w prawie Brooksa jest to, że jest ono sprzeczne z intuicją. Wydaje się bowiem oczywiste, że jeśli jakieś zadanie będzie wykonywała większa ilość osób to muszą je skończyć szybciej. W końcu projekt to nie jedno, ale wiele zadań. Na tablicy „do zrobienia” są różne taski, więc wezmą je i zaczną działać. Co może pójść nie tak?
Wbrew pozorom – sporo.
Przychodzą nowe osoby. Konfigurują swoje komputery, instalują oprogramowanie, ściągają kod źródłowy. Niby coś robią, ale żadnego z tego widocznego efektu przez pierwsze godziny/dni. Wydaliśmy pieniądze, a nie zyskaliśmy jeszcze nic.
Wszystko jest technicznie gotowe, nowi mogą zacząć pracę. Muszą się jednak dowiedzieć, co mają do zrobienia. Organizuje się więc spotkania wyjaśniające naturę projektu. Teraz już nie tylko nowe osoby w projekcie nie posuwają pracy do przodu, ale też dotychczasowi członkowie zespołu przestali pracować nad tym co kluczowe.
Spotkania się zakończyły. Nowi mniej więcej wiedzą, co robić. Zaczynają pracę. Wydaje się, że postęp w końcu ruszy z kopyta. Tymczasem wszystkie okresowe spotkania w zespole zaczęły zajmować więcej czasu. Zakładając, że pracujemy w scrum – dłuższe stają się daily, refinementy, planowanie sprintu i retrospekcja.
Wszystko wydaje się iść do przodu, ale to, czego nie widać na pierwszy rzut oka, to nieustanne pytania nowych osób do starej części zespołu. Nie da się również zauważyć, że te pytania przerywając pracę rujnują ich skupienie. Czasami po kilku minutach rozmowy programista potrzebuje piętnastu minut lub pół godziny, by wrócić do produktywności sprzed rozproszenia. Co więcej programiści pracują przecież nad tymi samymi plikami w zespole. Kiedy było ich trzech nie wchodzili sobie za bardzo w drogę. Nagle okazuje się, że merge’owanie, scalanie plików po zmianach kolejnych trzech osób staje się zmorą i zajmuje dużo czasu. Wydajność wszystkich znacząco spadła, zadowolenie również, a postęp jest wolniejszy, niż się spodziewaliśmy. Dopadło nas prawo Brooksa.
To co, nic nie robić?
Co robić w przypadku opóźnionego projektu to oczywiście doskonałe pytanie, na które jak sądzę nie da się odpowiedzieć ogólnie. Nie byłbym na tyle ortodoksyjny, by stwierdzić, że na pewno nie można dodać kolejnej osoby do zespołu, ale sądzę, że warto się nad tym dobrze zastanowić, przemyśleć ile takich osób i na jak długo planujemy dokoptować, a także koniecznie trzeba porozmawiać z zespołem i zapytać, jak taki pomysł im się podoba.
W wielu przypadkach naprawdę nie ma sensu dodawać ludzi do spóźnionego projektu. Deadline i tak będzie przekroczony, praca zakończy się szybciej, niż gdyby nie dodawać nikogo, a koszt będzie niepotrzebnie zwiększony.
Co jednak bardziej istotne, czasami dodanie ludzi do zespołu może skończyć się autentyczną tragedią. Wtedy prawo Brooksa ujawnia się z całą jaskrawością. Jeśli termin jest naprawdę krótki, a ilosć osób już oscyluje wokół dziewięciu i chcemy dorzucić jeszcze czwórkę, może się okazać, że zespół się kompletnie komunikacyjnie zakorkuje i nie tylko nie dostarczy produktu na czas, ale dostarczy zdecydowanie później, niż byśmy się spodziewali i to absurdalnie większym kosztem.