estymacja | On software development

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.

Do zadania tytułowego pytania i próby udzielenia na nie odpowiedzi skłonił mnie ten artykuł: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/ , w którym autor odnosi się do idei #noestimate, czyli postulatu porzucenia wyceny zadań, Dla wielu osób zabrzmi to pewnie, jak zgrzyt paznokci na tablicy i wierutna bzdura, ale prawdę mówiąc coś jest moim zdaniem na rzeczy.

Programiści oczywiście wiedzą, czemu nie lubią wyceniać zadań. Wydaje mi się jednak, że osoby z biznesu mogą nie do końca rozumieć tę awersję do deklarowania szacowanego czasu wykonania pracy…

Wstyd i poczucie winy

Zacząłbym od tego, że spora część programistów jest dobrymi, pracowitymi ludźmi. Taka osoba nie lubi rzucać słów na wiatr. Jeśli mówi, że coś zajmie tydzień, a okazuje się, że nie da się go wykonać, odczuwa negatywne emocje. Wstyd, poczucie braku wymaganych umiejętności, wrażenie, że się kogoś zawiodło. Rozwiązania w tej sytuacji są dwa – odmowa udzielania kolejnych wycen lub ich zawyżanie.

Zadanie niemożliwe

Fundamentalny problem polega na tym, że w wielu przypadkach prawidłowe wykonanie wyceny, oszacowanie czasu wykonania zadania jest po prostu niemożliwe.

Kiedy ktoś zapyta nas, ile czasu zajmie nam przygotowanie kotleta schabowego, jesteśmy w stanie odpowiedzieć w miarę konkretnie. Zakładamy przy tym, że mamy wszystkie składniki i nic się nie wydarzy oraz że już kiedyś to robiliśmy.

Zwróćmy uwagę na te założenia. Zastanówmy się, co się dzieje, gdy nie są spełnione.

Zaczynamy pracę nad schabowym. Oszacowaliśmy ją na 30 minut. Otwieramy lodówkę i okazuje się, że mięso jest zepsute. Idziemy więc do mięsnego. Po 45 minutach wracamy z mięsem. Mówimy sobie – powinniśmy o tym pomyśleć. Nauczeni na błędzie rozglądamy się po kuchni i zastanawiamy się, co jest nam niezbędne. Tłuszcz, patelnia, kuchenka, panierka, tłuczek, deska, jajka. Wydaje się, że wszystko mamy. Zaczynamy raz jeszcze. I nagle okazuje się, że mimo dobrego terminu przydatności do spożycia wszystkie cztery jajka, jakie mieliśmy w domu są zepsute. Oczywiście powinniśmy mieć ich więcej, może dwie paczki, myślimy. Idziemy do sklepu i kupujemy jajka. “Zmarnowaliśmy” kolejne 30 minut, a jeszcze nie zaczęliśmy smażyć mięsa…

Mamy nowe jajka. Mamy mięso. Mamy wszystko. Ubiliśmy mięso tłuczkiem, obtoczyliśmy w panierce. Zaczynamy smażyć. I nie wierzymy własnym oczom. Wyłączono prąd.

Na szczęście tylko na 15 minut. W końcu udało się coś ugotować. Z początkowych 30 minut zrobiło się jednak… ponad dwie godziny.

Rzetelna wycena

Zakładając, że chcielibyśmy wykonać rzetelną wycenę musielibyśmy mieć:

kompletną specyfikację zadania, bez żadnych niespodzianek i improwizacji
doświadczenie w wykonywaniu analogicznych zadań
znamy narzędzia i zależności oraz system
wszystkie nasze zależności już istnieją i są niezawodne

Doświadczenie uczy, że nie tylko nie wszystko powyższe udaje się spełnić, lecz zwykle wręcz nic. Co więcej zrealizowanie tak rzetelnej wyceny zajmuje ogrom czasu i jest po prostu dysfunkcjonalne.

Współczynnik fi

Patrząc na powyższe problemy próbujemy zatem wycenę zawyżyć. Niektórzy mnożą przez dwa, inni przez współczynnik fi, czy inne pi albo stałą Plancka. Nic to nie daje, bo jak nieskończoność mnożona przez stałą daje nieskończoność, tak iloraz – czy choćby iloczyn – niepewności przez dowolną liczbę również równa się niepewności.

Czy jest na tym bożym świecie zadanie estymowalne?

Rozkładając już ręce w żałosnym geście zadajemy sobie powyższe pytanie. I w zasadzie odpowiedź brzmi: tak. Owszem, w wielu scenariuszach da się sensownie wyceniać. Kiedy robimy kolejną stronę wizytówkę w tej samej technologii, kiedy po edycji produktu tworzymy feature edycji kategorii w tym samym projekcie itp.

Niestety jednak sposobu wyceny projektów nowych, nowych feature’ów, implementacji w nieznanych frameworkach, wykonywanych przez nowo powstałe zepoły – nie ma. Po prostu nie ma.

Po co zatem szacować?

Na koniec odniosę się znów do wspomnianego na początku artykułu. Wyjaśnia on dobrze do czego – mimo ich pozornego braku logiki i ich niedokładności – potrzebne są wyceny. Warto rzucić okiem: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/

W wielkim jednak skrócie, by nie powtarzać niepotrzebnie argumentów, potrzebne są do planowania biznesu, budżetowania i alokacji zasobów. Możemy się w wycenie pomylić, choćby i dwukrotnie, ważne tylko, by nie o rząd wielkości, by z dwóch godzin nie zrobiło się godzin dwieście. Warto o tym pamiętać zarówno będą programistą, jak i zarządzając projektem.

Tag: estymacja

Prawo Brooksa