Prawo Brooksa: dlaczego nowi ludzie opóźniają projekt IT

Lekarstwo też bywa podejrzanie proste — zatrudnić kolejnych programistów, dorzucić kilka osób do testów, znaleźć jeszcze jednego kierownika i ogłosić, że teraz produkt naprawdę nabierze tempa. Najlepiej na najbliższym spotkaniu z inwestorem.

To właśnie w tym momencie działa prawo Brooksa. Im później dokładamy ludzi do opóźnionego projektu IT, tym większa szansa, że zamiast przyspieszenia dostaniemy kolejne tygodnie poślizgu, więcej błędów i zespół, który większość czasu spędza na tłumaczeniu nowym osobom, co właściwie próbował zbudować.

Nie jest to zaklęcie ani wymówka dla leniwego działu technicznego. Prawo Brooksa opisuje bardzo konkretny mechanizm: wdrożenie nowych osób kosztuje czas, zwiększa liczbę zależności i odciąga doświadczonych pracowników od właściwej pracy. W efekcie firma może mieć więcej etatów, a mniej realnego postępu. Klasyczny paradoks skalowania: rośnie organizacja, maleje prędkość.

Prawo Brooksa powstało przy projekcie, który miał być przełomem

Fred Brooks sformułował swoje obserwacje w 1975 roku w książce The Mythical Man-Month. Nie pisał z pozycji konsultanta, który przez godzinę ogląda tablicę z kolorowymi karteczkami i po wszystkim proponuje zmianę nazwy zespołu. Wnioski wynikały z doświadczeń z zarządzania pracami nad systemem operacyjnym IBM OS/360.

Brooks zauważył rzecz, która dla wielu firm pozostaje niewygodna do dziś: w projekcie programistycznym nie da się przeliczać ludzi na jednostki mocy obliczeniowej. Dziesięciu programistów nie zawsze wykona pracę dwa razy szybciej niż pięciu. Czasami nie wykona jej nawet równie szybko, bo część energii zespołu zostanie skonsumowana przez komunikację, ustalanie odpowiedzialności i naprawianie problemów wywołanych przez pośpiech.

Prawo dotyczy przede wszystkim projektów już opóźnionych. To rozróżnienie ma znaczenie. Dodanie ludzi na wczesnym etapie, kiedy jest jeszcze czas na spokojne wdrożenie i podział pracy, nie musi prowadzić do katastrofy. Problem zaczyna się wtedy, gdy firma próbuje nadrobić utracony czas samym zwiększeniem liczby osób.

To trochę tak, jakby spóźniony pociąg miał odzyskać rozkład jazdy przez doczepienie kolejnych wagonów. Wagonów jest więcej, peron wygląda poważniej, a lokomotywa nadal jedzie z tą samą prędkością.

Jeśli projekt jest już spóźniony, nowe osoby nie kupują czasu. Najpierw trzeba im poświęcić czas zespołu.

Skąd bierze się opóźnienie po zatrudnieniu nowych osób

Na pierwszy rzut oka rachunek wygląda rozsądnie. Do wykonania zostało dużo zadań, a ludzi jest mało. Skoro każdy programista może realizować część pracy, większy zespół powinien zamknąć temat szybciej. Taki model działa przy prostych, niezależnych czynnościach. Programowanie dużego produktu rzadko jest jednak zbiorem niezależnych czynności.

Nowy członek zespołu musi zrozumieć kod, architekturę, sposób podejmowania decyzji, zasady wdrażania zmian, historię błędów i ograniczenia, których nie ma w dokumentacji. A jeśli dokumentacji nie ma, zaczyna się archeologia prowadzona przy żywym systemie.

Doświadczony programista musi wtedy przerwać własne zadanie. Pokazuje strukturę projektu, odpowiada na pytania, sprawdza pierwsze zmiany i tłumaczy, dlaczego pozornie eleganckie rozwiązanie rozwali mechanizm napisany trzy lata wcześniej. To nie jest strata czasu w sensie organizacyjnym — wdrożenie jest konieczne. Jest jednak stratą czasu z perspektywy pierwotnego harmonogramu.

W praktyce pojawiają się cztery nakładające się koszty:

• Wdrożenie nowych osób — zanim nowy pracownik zacznie samodzielnie dostarczać wartość, musi poznać produkt, kod i sposób pracy.
• Odciągnięcie najbardziej doświadczonych członków zespołu — osoby, które najlepiej znają system, stają się nieformalnymi nauczycielami, przewodnikami i działem pomocy technicznej.
• Wzrost ryzyka błędów — pracownik, który nie zna jeszcze zależności w systemie, może wprowadzić zmianę poprawną lokalnie, ale destrukcyjną dla całego produktu.
• Rozrost komunikacji — więcej osób oznacza więcej relacji, spotkań, uzgodnień i punktów, w których informacja może zostać zniekształcona.

Właśnie ten ostatni element jest często niedoceniany. Menedżerowie widzą dodatkowe ręce do pracy, ale nie widzą wszystkich nowych połączeń między tymi rękami.

Matematyka komunikacji nie zna litości

Liczbę możliwych kanałów komunikacji w zespole można opisać wzorem:

n(n − 1) / 2

Litera n oznacza liczbę osób. Nie trzeba być matematykiem ani inwestorem po trzech rundach finansowania, żeby zobaczyć problem.

Zespół pięcioosobowy ma dziesięć możliwych relacji komunikacyjnych. Po podwojeniu liczby osób nie dostajemy dwudziestu kanałów, tylko czterdzieści pięć. Przy pięćdziesięciu osobach robi się ich 1225.

Oczywiście nie każda osoba musi komunikować się bezpośrednio z każdą inną. W zdrowej organizacji stosuje się podział na mniejsze zespoły, jasno określone odpowiedzialności i ograniczenie liczby spotkań. Sama liczba pokazuje jednak, dlaczego komunikacja nie rośnie liniowo.

W małym zespole można szybko podejść do biurka albo napisać krótką wiadomość. W większym trzeba ustalić, kto jest właścicielem danego fragmentu systemu, czy zmiana wymaga zgody innego zespołu, czy testy obejmują cały moduł i kto podejmuje decyzję, kiedy pojawiają się sprzeczne opinie. Potem ktoś organizuje spotkanie, ktoś przygotowuje notatkę, a ktoś inny pyta, czy decyzja ze spotkania nadal obowiązuje.

Tak powstaje organizacyjny odpowiednik korka na autostradzie. Każdy samochód ma silnik, paliwo i kierowcę. Problem w tym, że wszystkie próbują wjechać na ten sam pas.

W zaleceniach dotyczących zespołów Scrum często wskazuje się grupy liczące od 3 do 9 osób. Przy dziewięciu osobach liczba potencjalnych kanałów komunikacji wynosi 36. To wciąż dużo, ale skala pozostaje możliwa do opanowania. Przekroczenie tej granicy nie oznacza automatycznie porażki. Oznacza natomiast, że komunikacja musi być projektowana, a nie pozostawiana spontaniczności. Spontaniczność w organizacji zwykle kończy się spotkaniem, na którym ustala się kolejne spotkanie.

Najdroższy zasób nie siedzi w tabeli zatrudnienia

Firmy lubią raportować liczbę pracowników, bo łatwo ją pokazać. Jest konkretna, rośnie z miesiąca na miesiąc i dobrze wygląda w prezentacji dla inwestorów. Trudniej policzyć, ile czasu tracą najlepsi inżynierowie, kiedy próbują przekazać wiedzę nowym osobom.

A właśnie ten koszt bywa kluczowy.

Jeśli doświadczony programista przez kilka tygodni dzieli czas między własne zadania a wdrażanie nowych pracowników, jego produktywność spada. Nie dlatego, że nagle pracuje gorzej. Dlatego, że wykonuje dwa różne rodzaje pracy, a przełączanie kontekstu jest kosztowne. Raz analizuje problem w kodzie, chwilę później tłumaczy strukturę modułu, następnie wraca do błędu, po czym odpowiada na pytanie o proces wdrażania.

W materiałach dotyczących prawa Brooksa często mówi się o spadku wydajności doświadczonych osób. Nie ma jednak uniwersalnego procentu, który można uczciwie wpisać do arkusza kalkulacyjnego. Skala zależy od złożoności projektu, jakości dokumentacji, doświadczenia nowych pracowników i tego, czy zadania da się od siebie odseparować.

Kto podaje jedną precyzyjną wartość dla każdej firmy, prawdopodobnie sprzedaje nie analizę, lecz slajd.

Wiedza ukryta w głowach programistów jest jednym z największych hamulców skalowania zespołu deweloperskiego. Jeśli tylko jedna osoba wie, jak działa krytyczny fragment systemu, każda próba zwiększenia zespołu prowadzi do tej samej kolejki: wszyscy czekają na jej czas.

Dlatego dokumentacja nie jest biurokratycznym dodatkiem do pracy technicznej. Jest infrastrukturą wzrostu. Powinna opisywać nie tylko to, jak uruchomić aplikację, lecz także:

• które elementy systemu są krytyczne dla działania produktu;
• jakie zależności istnieją między modułami;
• dlaczego podjęto określone decyzje architektoniczne;
• gdzie znajdują się znane ograniczenia i ryzyka;
• jak wygląda proces testowania, wdrażania i wycofywania zmian;
• kto odpowiada za poszczególne obszary, ale bez tworzenia pojedynczych punktów awarii.

Dobra dokumentacja nie eliminuje kosztu wdrożenia. Ogranicza jednak konieczność każdorazowego odtwarzania całej historii projektu przez najbardziej zajęte osoby.

Prawo Brooksa a skalowanie zespołu deweloperskiego

Najczęstszy błąd nie polega na tym, że firma zatrudnia ludzi. Polega na tym, że zatrudnia bez zmiany struktury pracy.

Dodanie trzech programistów do zespołu, który już nie radzi sobie z komunikacją, nie tworzy automatycznie większej przepustowości. Tworzy większy zespół z tym samym problemem, tylko z dodatkowymi spotkaniami.

Skalowanie powinno odpowiadać na pytanie, które zadania można rozdzielić bez tworzenia nowych zależności. Jeśli wszyscy pracują nad tym samym modułem, dokładanie osób może zwiększyć liczbę konfliktów w kodzie i koniecznych uzgodnień. Jeśli system można podzielić na względnie niezależne obszary, nowi pracownicy mają szansę przejąć konkretne odpowiedzialności.

To dlatego sama liczba etatów nie jest dobrą miarą zdolności zespołu do rozwoju. Lepsze pytania brzmią:

• Czy nowe osoby dostają samodzielny, jasno ograniczony obszar?
• Czy zadania są wystarczająco niezależne?
• Czy zespół ma dokumentację, która pozwala zacząć pracę bez ciągłego pytania starszych kolegów?
• Czy ktoś został wyznaczony do wdrożenia nowych pracowników, a jego obciążenie zostało uwzględnione w planie?
• Czy decyzje techniczne są podejmowane wystarczająco szybko?
• Czy wzrost liczby osób wymaga nowego podziału na zespoły?

Jeśli odpowiedzi brzmią źle, firma nie ma problemu z liczbą programistów. Ma problem z konstrukcją organizacji.

Kiedy zatrudnienie ma sens

Prawo Brooksa nie mówi, że zatrudnianie jest złe. Mówi, że zatrudnianie jako desperacka reakcja na opóźnienie może pogorszyć sytuację.

Nowe osoby mają większą szansę pomóc, gdy:

1. Projekt znajduje się jeszcze na etapie planowania lub wczesnej realizacji. Jest wtedy czas na wdrożenie bez konieczności gaszenia pożaru w każdy piątek po południu.

2. Praca daje się podzielić na niezależne moduły. Nowy członek zespołu może przejąć odpowiedzialność za konkretny obszar zamiast wchodzić w sam środek wspólnego bałaganu.

3. Zespół ma jawną dokumentację. Nowa osoba nie musi poznawać całego systemu wyłącznie przez rozmowy z jednym ekspertem.

4. Wdrożenie jest zaplanowane. Firma nie udaje, że nowy pracownik zaczyna wnosić pełną wartość od pierwszego dnia.

5. Odpowiedzialności są czytelne. Więcej osób nie oznacza wtedy automatycznie większego chaosu decyzyjnego.

W takich warunkach rozbudowa zespołu może być inwestycją w kolejne etapy produktu. Bez nich staje się raczej próbą kupienia spokoju za pomocą rekrutacji.

Opóźniony projekt wymaga najpierw diagnozy

Gdy termin jest zagrożony, presja skłania zarządzających do ruchu, który można łatwo zakomunikować: zatrudniliśmy nowych ludzi. Trudniej ogłosić, że trzeba ograniczyć zakres, usunąć część funkcji albo przyznać, że pierwotny plan był fantazją w arkuszu kalkulacyjnym.

Tymczasem opóźnienie może mieć różne przyczyny. Niedobór ludzi jest tylko jedną z nich. Projekt może zwalniać przez niejasne wymagania, częste zmiany priorytetów, zależności między modułami, problemy architektoniczne albo decyzje odkładane tak długo, aż zaczynają blokować wszystkich.

Jeśli źródłem problemu jest zakres, kolejni programiści go nie zmniejszą. Jeśli problemem są decyzje, nowi ludzie nie podejmą ich za zarząd. Jeśli problemem jest skomplikowana architektura, dodatkowe osoby będą musiały najpierw nauczyć się poruszać po systemie, który już dla obecnego zespołu jest trudny.

Najpierw trzeba ustalić, co blokuje projekt. Dopiero potem można rozstrzygać, czy potrzebni są nowi ludzie, czy raczej odwaga do usunięcia połowy obietnic.

W praktyce często pomaga ograniczenie zakresu i podział prac na mniejsze, możliwie niezależne części. Nie brzmi to tak efektownie jak zapowiedź budowy kolejnego jednorożca, ale pozwala odzyskać kontrolę nad przepływem pracy.

Warto też oddzielić zadania krytyczne od tych, które tylko dobrze wyglądają w prezentacji produktu. Wiele zespołów próbuje dostarczyć naraz funkcje dla klientów, usprawnienia wewnętrzne, nową wersję aplikacji, integracje i elementy, które kiedyś mogą zwiększyć sprzedaż. Potem wszystko jest ważne, a skoro wszystko jest ważne, nic nie ma prawdziwego priorytetu.

W takim środowisku dokładanie osób nie rozwiązuje problemu. Powiększa liczbę frontów, na których firma próbuje walczyć jednocześnie.

Wdrożenie nie jest kosztem, który można wymazać

Jednym z najbardziej naiwnych założeń przy rekrutacji do zespołu IT jest przekonanie, że nowy pracownik zaczyna od razu realizować zadania. Owszem, może od razu otworzyć komputer i zacząć pisać kod. To nie znaczy, że jego praca od razu przyspiesza projekt.

Początkowo nowa osoba potrzebuje kontekstu. Musi wiedzieć, gdzie kończy się jej odpowiedzialność, jakie decyzje są już zamknięte, które fragmenty kodu są delikatne i jak wygląda ścieżka dostarczania zmian. Bez tego szybko powstaje kod, który działa w izolacji, ale nie pasuje do reszty systemu.

Dobrze zaprojektowane wdrożenie powinno mieć kilka warstw:

• dostęp do środowiska i narzędzi bez wielodniowego oczekiwania;
• uporządkowaną dokumentację produktu i architektury;
• zadania startowe, które pokazują sposób pracy, ale nie wystawiają nowej osoby od razu na najbardziej ryzykowny obszar;
• jednego opiekuna lub jasno określony kanał pytań;
• przegląd pierwszych zmian z naciskiem na przekazywanie wiedzy, nie tylko poprawianie błędów;
• stopniowe zwiększanie odpowiedzialności.

To wszystko wymaga pracy istniejącego zespołu. Próba ukrycia tego kosztu prowadzi do fikcyjnego planowania. Firma zakłada, że dostała dodatkową osobę, choć faktycznie przez pewien czas otrzymała osobę uczącą się oraz część czasu pracownika, który ją wdraża.

Nie ma w tym nic złego. Problem pojawia się wtedy, gdy harmonogram udaje, że ten proces nie istnieje.

Jak ograniczyć skutki prawa Brooksa

Prawa Brooksa nie da się unieważnić deklaracją, że tym razem będzie inaczej. Można natomiast zmniejszyć jego siłę. Nie przez magiczne narzędzie do zarządzania zadaniami, lecz przez ograniczenie tarcia.

Pierwszym krokiem jest ujawnienie wiedzy. Dokumentacja powinna być aktualna na tyle, by nowy pracownik mógł zrozumieć podstawowe zależności bez ciągłego angażowania jednej osoby. Nie musi opisywać każdego wiersza kodu. Powinna odpowiadać na pytania, które pojawiają się przed rozpoczęciem samodzielnej pracy.

Drugim krokiem jest podział odpowiedzialności. Jeśli wszyscy są odpowiedzialni za wszystko, w rzeczywistości nikt nie ma pełnej odpowiedzialności za nic. Nowe osoby powinny otrzymywać obszary, w których mogą podejmować decyzje i widzieć efekt pracy.

Trzecim jest ograniczenie liczby bezpośrednich zależności. Duży zespół warto dzielić na mniejsze jednostki z jasno zdefiniowanymi punktami współpracy. Wtedy nie każda decyzja musi przechodzić przez wszystkich.

Czwartym — i najbardziej niepopularnym — jest ochrona czasu osób wdrażających. Jeśli firma przydziela seniorowi dwóch nowych pracowników, a jednocześnie utrzymuje jego dotychczasowe cele bez zmian, plan jest matematycznie podejrzany. Ktoś zapłaci za tę różnicę. Najczęściej terminem albo jakością.

Piątym krokiem jest ostrożność wobec zmian w trakcie krytycznej fazy projektu. Każda nowa osoba potrzebuje kontekstu, a każda reorganizacja tworzy dodatkową warstwę niepewności. Gdy produkt jest blisko ważnego wydania, przyjęcie nowych ludzi może być rozsądne tylko wtedy, gdy mają jasno wydzielone zadania i nie będą destabilizować głównego strumienia pracy.

Co prawo Brooksa mówi o liderach

Z perspektywy zarządzania prawo Brooksa jest mniej opowieścią o programistach niż o jakości decyzji przywódczych.

Słaby lider widzi opóźnienie i pyta: ilu ludzi możemy jeszcze zatrudnić? Lepszy pyta: co dokładnie powoduje opóźnienie, jakie zależności blokują pracę i które elementy planu można usunąć?

Pierwsze pytanie jest wygodne, bo prowadzi do działania, które można pokazać na zewnątrz. Rekrutacja wygląda jak rozwój. Nowe twarze na firmowym profilu dobrze pasują do narracji o skalowaniu. Nikt nie robi zdjęcia zespołowi, który właśnie skrócił zakres produktu, usunął zbędną funkcję i dzięki temu odzyskał dwa tygodnie.

A jednak to właśnie takie decyzje często decydują o powodzeniu projektu. Wzrost nie polega na tym, że organizacja robi więcej wszystkiego. Polega na tym, że potrafi zwiększać zdolność do dostarczania wartości bez proporcjonalnego zwiększania chaosu.

Lider powinien więc pilnować nie tylko liczby osób, ale też:

• czasu potrzebnego na podjęcie decyzji;
• liczby zależności między zespołami;
• koncentracji wiedzy w rękach pojedynczych ekspertów;
• jakości dokumentacji;
• stabilności zakresu projektu;
• kosztu przełączania kontekstu;
• tego, czy nowe osoby przejmują odpowiedzialność, czy jedynie uczestniczą w coraz większej liczbie spotkań.

To mniej efektowne niż wykres zatrudnienia idący w górę i w prawo. Niestety, produkt nie jest wykresem.

Nie każda rekrutacja jest błędem, ale każda ma cenę

Prawo Brooksa bywa wykorzystywane jako argument przeciwko rozbudowie zespołów. To również uproszczenie. Organizacja, która nigdy nie zatrudnia, nie skaluje się — po prostu długo pozostaje mała i nazywa to dyscypliną.

Nowe osoby są potrzebne, gdy firma rośnie, wchodzi na nowe rynki, utrzymuje większą liczbę klientów albo buduje kompetencje, których wcześniej nie posiadała. Rozsądne skalowanie wymaga jednak uwzględnienia opóźnienia między zatrudnieniem a pełną samodzielnością.

Rekrutacja nie jest przełącznikiem. Jest procesem. Najpierw trzeba znaleźć właściwą osobę, potem ją wdrożyć, następnie przekazać odpowiedzialność i dopiero później oczekiwać stabilnego wpływu na tempo pracy. Jeżeli firma planuje wzrost tak, jakby ten okres nie istniał, tworzy harmonogram oparty na fikcji.

Najgorszy scenariusz wygląda znajomo: projekt jest spóźniony, więc zatrudniamy ludzi; nowi ludzie potrzebują wdrożenia, więc projekt spóźnia się jeszcze bardziej; rośnie presja, więc zatrudniamy następnych. Na końcu firma ma większy zespół, więcej zależności i mniej pewności, co właściwie powinno zostać dostarczone.

To nie jest skalowanie. To palenie gotówki w rytmie cotygodniowych spotkań statusowych.

Zamiast kolejnego hasła o wzroście

Prawo Brooksa przetrwało od lat siedemdziesiątych nie dlatego, że technologia stoi w miejscu. Przetrwało, bo ludzie nadal próbują rozwiązywać problemy organizacyjne samą liczbą osób.

W zespołach IT nie da się oddzielić pracy od komunikacji, wiedzy i zależności. Każda nowa osoba może zwiększyć możliwości organizacji, ale może też zwiększyć koszt uzgodnień. Każdy dodatkowy etat może być inwestycją, ale w opóźnionym projekcie bywa również kolejną warstwą obciążenia.

Dlatego przed zatrudnieniem warto zadać pytanie mniej wygodne niż popularne hasło o skalowaniu: czy rzeczywiście brakuje nam ludzi, czy brakuje nam podziału pracy, dokumentacji i decyzji?

Jeśli problemem jest liczba rąk, rekrutacja może pomóc. Jeśli problemem jest chaos, dostaniemy po prostu większy chaos. Z lepszym budżetem na wynagrodzenia i znacznie bardziej imponującą narracją dla rynku.