Prawo Brooksa 

Realizujemy projekt, nie wiemy czy zdążymy z jego realizacją, więc w najlepszej wierze dokładamy ludzi do jego realizacji. Znacie to? Dlaczego nam nie wyjdzie opisał Fred Brooks, a zjawisko to znane jest jako Prawo Brooksa.

„Dorzućmy ludzi”

To już nie tylko błędy poznawcze czyhają na nas, gdy działamy w najlepszej wierze. Przecież żaden kierownik projektu nie będzie działał na swoją szkodę, a tym bardziej na szkodę projektu, nad którym pracuje. Od tego projektu przecież często zależy jego dalsza kariera w firmie. Jeśli więc występują problemy z realizacją harmonogramu, szukamy jakiegoś działającego wyjścia. Zdrowy rozsądek podpowiada nam, że jednym z nich jest… zatrudnienie dodatkowych osób.

Dlaczego musimy je zatrudnić? Sprawa wydaje się prosta. Łączy nas z klientem umowa, kontrakt, zobowiązanie. Podpisaliśmy się pod zakresem, który mieliśmy wykonać w danym czasie. Ponieważ linia mety drastycznie się oddala musimy poszukać rozwiązań pozwalających nam dogonić ją w zakładanym czasie. Oczywistym pomysłem, które zawsze pojawia się jako pierwszy to „dozasobowanie” projektu. Dorzućmy ludzi!

No bo jeśli nie zatrudnienie dodatkowych osób, to co? Często spotykanym rozwiązaniem jest delikatne pudrowanie trupa, pisaliśmy o tym chociażby przy okazji omawiania kolorów z palety RAG i tzw. arbuzowych projektów.

Im więcej, tym później, czyli Prawo Brooksa

Dorzucanie kolejnych osób do już opóźnionego projektu jest problematyczne. Przede wszystkim, patrząc z punktu widzenia krótkoterminowej wydajności zespołu, zawsze okazuje się być złym pomysłem. Nie ma znaczenia, czy zatrudniamy najlepszych na świecie specjalistów, zawsze będziemy mieli do czynienia z progiem wejścia. Zrozumienie projektu, Celu Produktu, poznanie koleżanek i kolegów czy wreszcie zdobycie ich zaufania to tylko część z wyzwań. Tego etapu nie da się przeskoczyć, musi się on odbyć zgodnie z zasadami.

I chociaż dorzucenie większej liczy osób to odruch, a często też najłatwiejsza z dróg, jakie możemy podjąć, to jednak zwykle nie osiągniemy dzięki temu zamierzonego celu. Bo każda zmiana w składzie zespołów oznacza spadek wydajności. Zespoły muszą się „wygrzać”, żeby pracować efektywnie.

To właśnie z tego powodu mówi się, że Zespół powinien być maksymalnie stały w swoim składzie. Każda zmiana w jego składzie powoduje w pierwszym momencie spadek produktywności, co jeszcze bardziej oddala od nas metę naszego projektu. To właśnie wtedy bardzo często mamy do czynienia z jeszcze bardziej radykalnymi krokami. One również jak się często okazuje nie pomogają.

„Adding manpower to a late software project makes it later.” – Fred Brooks

Nie jest to jedyny powód, dla którego Prawo Brooksa wydaje się być boleśnie prawdziwe. W dywagacjach o idealnej wielkości zespołu mówiliśmy, że im nas więcej, tym więcej ścieżek komunikacyjnych. Co za tym idzie, trudniej o transparentność i zrozumienie. Ale to jeszcze nie wszystko…

Zwinność kontra…

Przykład dotyczy oczywiście projektów, które z góry posiadają wyznaczony cel i zakres. Nie taka jest jednak charakterystyka projektów zwinnych. W nich przecież Produkt, jego zakres i rozumienie powstają czy ujawniają się w miarę trwania pracy wytwórczej. Nie mamy więc formalnej mety, mamy zaledwie Cel Produktu. Dlaczego zaledwie? W tym przypadku to pozytyw, mając wyłącznie cel jesteśmy w stanie wybrać najlepszą drogę jego osiągnięcia.

To jak z wycieczką w góry. Idąc nad Morskie Oko (założę się, że większość z Was tam była) mamy do wyboru kilka skrótów. Są mniej komfortowe, idzie się po kamieniach, ale jeśli komuś spieszy się w drodze w górę lub w dół…

Powyższe nie oznacza, że w zwinności Prawo Brooksa nie ma prawa wystąpić. Ma, ale śmiem twierdzić, że szansa na zaobserwowanie tego zachowania jest wielokrotnie mniejsza. W końcu w Zespole mamy Product Ownera, który dba o kompletność i terminowość dostarczania (definiując kolejność) poszczególnych elementów składowych naszej funkcjonalności.

Prawo Brooksa

Pewnie nie zaskoczę nikogo stwierdzeniem, że Prawo Brooksa nie jest niczym nowym. Powstało prawie 60 lat temu, jest efektem empirycznej obserwacji sytuacji w dużym projekcie w IBM. Skoro tam się nie udało, dlaczego u nas miałoby być inaczej? Oczywiście, świat, a co za tym idzie również nasze projekty nie są zero-jedynkowe. Jestem przekonany, że istnieją uwarunkowania, które powodują, że dodanie nowego członka zespołu może pomóc. Wydaje się jednak, że będą to pojedyncze przypadki.

Prawo Brooksa bowiem podkreśla jeszcze jeden aspekt. Jak skomentował to Fred Brooks – dziewięć kobiet nie urodzi dziecka w jeden miesiąc. Trudno się z nim nie zgodzić! Dodając ludzi do prostych, powtarzalnych czynności oczywiście skracamy czas ukończenia całego zadania. Ale tworzenie oprogramowania nie jest proste, a bardzo często nie jest też podzielne. Ścieżki krytycznej bardzo często nie może wykonywać kilka osób na raz, musi to zrobić ograniczona grupa specjalistów. A co za tym idzie, dodanie kolejnych osób nic nie zmieni!

Co możemy począć w sytuacji, w której zorientowaliśmy się, że meta nam ucieka? Jest to blog o zwinności, nie będziemy więc zajmować się metodami klasycznymi. W tych zwinnych mamy wiele mechanizmów, które pozwalają nam zoptymalizować zakres budowanego rozwiązania. Pierwszą z nich jest MVP, a inne mam nadzieję, że podpowiecie w komentarzach do wpisu!