Prawo Brooksa: dlaczego większy zespół IT spowalnia projekt?

Więcej osób oznacza więcej godzin, a więcej godzin powinno oznaczać szybsze dostarczenie produktu.

W praktyce ten rachunek często się nie zgadza. Zwłaszcza gdy projekt jest już spóźniony i znajduje się w późnej fazie realizacji. Nowe osoby nie trafiają wtedy na czystą kartę, dobrze opisane zadania i spokojny proces wdrożenia. Wchodzą w środek problemu: zmieniającą się architekturę, zaległe decyzje, błędy do naprawienia i zespół, który sam pracuje pod presją.

To właśnie opisuje prawo Brooksa w projektach IT. Dodanie ludzi do opóźnionego projektu może sprawić, że projekt opóźni się jeszcze bardziej. Nie dlatego, że nowi programiści są niekompetentni. Przyczyną są koszty komunikacji, wdrożenia i koordynacji, a także fakt, że nie każdą pracę można podzielić na większą liczbę równoległych strumieni.

Nie jest to jednak żelazne prawo obowiązujące w każdym przedsięwzięciu programistycznym. Najlepiej działa jako ostrzeżenie dotyczące konkretnych warunków: opóźnionego projektu, późnej fazy prac, dużej zależności między zadaniami i zespołu, który nie ma już wolnych zasobów na wdrażanie kolejnych osób.

Geneza prawa Brooksa: lekcja z systemu IBM OS/360

Fred Brooks był związany z projektem IBM OS/360, jednym z najważniejszych przedsięwzięć programistycznych swojej epoki. W książce „The Mythical Man-Month”, wydanej w 1975 roku, opisał problemy wynikające z próby zarządzania dużym projektem systemowym. Nie przedstawił prostego przepisu na organizację pracy. Pokazał raczej, że czas pracy ludzi nie jest wymienną walutą, którą można bez ograniczeń dokładać do dowolnego zadania.

Najbardziej znane zdanie z książki brzmi: „Adding manpower to a late software project makes it later” — dodanie ludzi do opóźnionego projektu programistycznego opóźnia go jeszcze bardziej.

To zdanie bywa cytowane jako uniwersalna zasada, ale jego sens jest bardziej precyzyjny. Brooks pisał o projekcie, który już ma opóźnienie, a nie o każdym powiększaniu zespołu. Jeśli zadania są dobrze rozdzielone, interfejsy między modułami stabilne, a nowi pracownicy mogą zostać wdrożeni bez odciągania kluczowych osób od pracy, zwiększenie zespołu może pomóc. Problem pojawia się wtedy, gdy kierownictwo próbuje użyć rekrutacji jako szybkiego lekarstwa na opóźnienie, którego źródłem jest zła architektura, niejasny zakres albo praca o charakterze sekwencyjnym.

Historia OS/360 jest często upraszczana do opowieści: projekt się spóźniał, IBM podwoił zespół, a sytuacja natychmiast się pogorszyła. Taki skrót nie oddaje jednak złożoności przedsięwzięcia ani nie powinien być traktowany jako precyzyjny opis jednej decyzji kadrowej. Wnioski Brooksa wynikają z doświadczeń pracy nad dużym systemem i z obserwacji mechanizmów organizacyjnych, a nie z prostego eksperymentu, w którym zmienną było wyłącznie zatrudnienie kolejnych inżynierów.

W podobny sposób należy podchodzić do późniejszych przykładów, takich jak Windows Vista czy portal Healthcare.gov. Oba projekty miały problemy z terminami, zakresem, integracją i jakością dostarczenia, ale nie ma podstaw, by sprowadzać ich historię do jednej wspólnej przyczyny: zwiększenia zespołu przez zarząd. Mogą ilustrować ryzyko dużych, złożonych przedsięwzięć, lecz nie stanowią prostego dowodu, że każda rekrutacja w czasie kryzysu pogarsza sytuację.

Brooks wskazał kilka mechanizmów, które powtarzają się w projektach o wysokiej złożoności:

• komunikacja między ludźmi nie rośnie liniowo wraz z wielkością zespołu;
• nowi członkowie potrzebują wiedzy, której nie da się przekazać wyłącznie przez dokumentację;
• osoby wdrażające nowych pracowników tracą część czasu przeznaczonego na realizację zadań;
• część prac ma ograniczoną możliwość równoległego wykonania;
• każda nowa osoba zwiększa liczbę zależności, miejsc potencjalnych nieporozumień i decyzji wymagających uzgodnienia.

Zespół nie jest sumą swoich członków. Jest siecią zależności, a ta sieć potrafi rosnąć szybciej niż liczba osób przy stole.

Matematyka chaosu: dlaczego kanałów komunikacji przybywa tak szybko

Zarząd patrzy na zespół jak na sumę dostępnych rąk do pracy. Projekt patrzy na niego jak na sieć. Każda osoba musi wymieniać informacje z innymi: ustalać zakres odpowiedzialności, uzgadniać interfejsy, omawiać błędy, przekazywać decyzje i rozumieć konsekwencje zmian w kodzie.

W uproszczonym modelu liczba potencjalnych połączeń między osobami wynosi:

n(n−1)/2

Litera „n” oznacza liczbę członków zespołu. Model nie opisuje całej komunikacji w firmie, bo w prawdziwym projekcie część osób nie kontaktuje się bezpośrednio. Pokazuje jednak kierunek zmian: każde zwiększenie zespołu dodaje nie tylko kolejne ręce do pracy, ale też nowe relacje, przez które trzeba przekazywać informacje.

Przy czterech osobach liczba możliwych par jest niewielka. Przy szesnastu rośnie już wielokrotnie. Nie oznacza to, że każda para musi codziennie odbywać osobne spotkanie. Oznacza natomiast, że rośnie liczba miejsc, w których informacja może zostać zniekształcona, opóźniona albo całkowicie pominięta.

W małym zespole wystarczy czasem krótka rozmowa przy zadaniu. W większym trzeba ustalić, kto podejmuje decyzję, gdzie ją zapisuje, kogo należy poinformować i w jaki sposób sprawdzić, czy wszystkie zespoły pracują na tej samej wersji założeń. Z czasem pojawiają się dodatkowe role: liderzy techniczni, architekci, właściciele obszarów produktowych i osoby odpowiedzialne za wydanie. Ich obecność może uporządkować pracę, ale nie jest darmowa. Każda kolejna warstwa koordynacji wprowadza własny czas oczekiwania.

Nie każda komunikacja jest problemem

Samo istnienie wielu kanałów komunikacji nie oznacza jeszcze chaosu. Duży zespół może działać sprawnie, jeśli podział odpowiedzialności jest czytelny, a zespoły komunikują się przez stabilne interfejsy. Problemem staje się dopiero komunikacja nieprzewidywalna: pytania kierowane do przypadkowych osób, decyzje podejmowane na spotkaniach bez śladu w dokumentacji, sprzeczne interpretacje wymagań i zależności odkrywane dopiero podczas integracji.

W projektach rozproszonych dochodzą kolejne obciążenia. Informacja jest rozłożona między system zarządzania zadaniami, komunikator, dokumentację, repozytorium i spotkania. Część rozmów odbywa się asynchronicznie, więc decyzja nie zapada wtedy, gdy pojawia się problem, lecz dopiero po kolejnej rundzie pytań i odpowiedzi. Różnice stref czasowych mogą wydłużyć ten proces jeszcze bardziej.

Dlatego problemy z komunikacją w zespole IT nie wynikają wyłącznie z liczby zatrudnionych osób. Zależą też od architektury produktu, sposobu podejmowania decyzji i dojrzałości procesu. Duży zespół z wyraźnymi granicami odpowiedzialności może być skuteczniejszy niż mały zespół, w którym wszystkie decyzje przechodzą przez jednego eksperta.

Ważne jest również rozróżnienie między komunikacją potrzebną a komunikacją naprawczą. Pierwsza pomaga rozwiązać problem. Druga pojawia się dlatego, że wcześniejsza informacja nie dotarła, wymaganie było niejasne albo dwie osoby wykonały tę samą pracę. Prawo Brooksa najbardziej boli właśnie wtedy, gdy powiększenie zespołu zwiększa drugi rodzaj komunikacji.

Pułapka onboardingu: koszt wdrożenia nowych osób w fazie kryzysu

Nowy programista nie zaczyna od pisania najbardziej krytycznej funkcji systemu. Najpierw musi uzyskać dostępy, uruchomić środowisko, zrozumieć strukturę repozytorium i poznać sposób wdrażania zmian. Potem dochodzą decyzje architektoniczne, ograniczenia domeny, konwencje kodu, procedury testowania oraz wiedza, która nigdy nie została zapisana, bo dotychczasowy zespół przekazywał ją sobie w rozmowach.

To nie jest wada konkretnej osoby. Każdy zespół posiada wiedzę jawną i ukrytą. Ta druga jest często najcenniejsza, a zarazem najtrudniejsza do przekazania. Dokument może opisywać strukturę usługi, ale nie wyjaśni w pełni, dlaczego kilka lat wcześniej zrezygnowano z pozornie prostszego rozwiązania. Nowy pracownik poznaje takie decyzje dopiero wtedy, gdy zaczyna zadawać pytania albo natrafia na ograniczenie w kodzie.

Koszt ponosi nie tylko osoba wdrażana. Senior przerywa pracę, by wyjaśnić kontekst. Lider techniczny odtwarza historię decyzji. Inżynier odpowiedzialny za infrastrukturę pomaga skonfigurować środowisko. Jeśli kilka nowych osób dołącza jednocześnie, obciążenie się nakłada. Zespół, który miał dostarczyć zaległe funkcje, zaczyna pełnić rolę zespołu szkoleniowego.

Nowy programista nie jest czystym zyskiem od pierwszego dnia. Najpierw trzeba zainwestować w jego kontekst, dostęp do systemu i relacje z zespołem.

Przykład hipotetyczny, nie prognoza

Załóżmy hipotetycznie, że opóźniony projekt ma niewielki zespół, a jego najważniejsza wiedza znajduje się w głowach kilku doświadczonych osób. Zarząd zatrudnia kolejnych programistów i oczekuje natychmiastowego przyspieszenia.

W pierwszej fazie nowi pracownicy potrzebują wsparcia. Jednocześnie obecni eksperci odpowiadają na pytania, przygotowują zadania i sprawdzają pierwsze zmiany. Jeśli nowi dostają fragment systemu silnie zależny od reszty produktu, ich praca wymaga dodatkowych przeglądów. W efekcie liczba osób rośnie, ale ilość samodzielnie dostarczanej pracy nie rośnie w tym samym tempie.

Później sytuacja może się poprawić. Nowi członkowie zespołu zdobywają kontekst, przejmują część zadań i odciążają bardziej doświadczonych pracowników. Nie ma jednak uczciwej, uniwersalnej reguły mówiącej, że nastąpi to w konkretnym miesiącu. Tempo wdrożenia zależy od dokumentacji, jakości kodu, złożoności domeny, sposobu pracy i tego, czy zespół ma w ogóle czas na mentoring.

W projekcie znajdującym się w późnej fazie realizacji ryzyko jest większe. Zmiany są bardziej powiązane, błędy kosztowniejsze, a decyzje podejmowane wcześniej trudniej odwrócić. Nowa osoba może być bardzo wartościowa, ale zanim zacznie samodzielnie wpływać na termin, musi zrozumieć kontekst, którego wczesna faza projektu jeszcze nie wymagała.

Jak rozpoznać, że rekrutacja zaczyna obciążać zespół

Sygnałem nie jest sama liczba nowych pracowników. Bardziej miarodajne są zachowania zespołu:

• kluczowe osoby spędzają coraz więcej czasu na odpowiadaniu na te same pytania;
• zadania są dzielone tylko po to, by znaleźć pracę dla nowych osób, a nie dlatego, że podział ma sens techniczny;
• rośnie liczba przeglądów, poprawek i konfliktów przy integracji;
• dokumentacja powstaje w pośpiechu i nie nadąża za decyzjami;
• nowe osoby nie mają własnego, ograniczonego obszaru odpowiedzialności;
• zespół przenosi uwagę z dostarczania produktu na obsługę procesu wdrożeniowego.

W takiej sytuacji zwiększanie zatrudnienia może pogłębić problem. Czasem lepszą decyzją jest najpierw uporządkowanie architektury, przygotowanie środowiska i wyznaczenie osób odpowiedzialnych za wdrożenie. Dopiero później można ocenić, czy kolejni programiści rzeczywiście zwiększą przepustowość.

Niezależność zadań a ograniczenia sekwencyjne w inżynierii

Drugim źródłem problemu jest założenie, że każdą pracę da się podzielić na dowolną liczbę części. Programowanie nie działa w ten sposób. Niektóre zadania można prowadzić równolegle, inne są od siebie zależne, a jeszcze inne wymagają jednej decyzji, zanim kilka zespołów będzie mogło ruszyć dalej.

Dziewięć kobiet nie urodzi dziecka w ciągu miesiąca — ta analogia Brooksa jest celowo prosta, ale trafia w sedno. Jeśli zadanie ma niepodzielny etap krytyczny, dodanie ludzi nie skróci go proporcjonalnie.

W oprogramowaniu takim etapem może być na przykład:

• decyzja o granicach odpowiedzialności między usługami;
• zaprojektowanie interfejsu, od którego zależą inne moduły;
• wybór modelu danych dla funkcji, której nie da się łatwo przepisać;
• przygotowanie mechanizmu bezpieczeństwa;
• uzgodnienie wymagań prawnych lub audytowych;
• rozwiązanie problemu z jakością danych potrzebnych do dalszej pracy.

Nie oznacza to, że żadnego z tych zadań nie można wesprzeć dodatkową osobą. Część analiz, testów, przygotowania danych czy prac dokumentacyjnych da się zrównoleglić. Bezwzględne stwierdzenie, że etap zbierania i czyszczenia danych zawsze musi wykonywać jeden zespół, byłoby równie błędne. Można podzielić źródła, przygotować niezależne potoki, automatyzować walidację albo równolegle analizować różne klasy danych. Granicą jest nie sam typ pracy, lecz stopień zależności między jej elementami.

Jak znaleźć prawdziwe wąskie gardło

Przed powiększeniem zespołu trzeba ustalić, co faktycznie ogranicza postęp. Warto odróżnić cztery sytuacje.

Brak rąk do pracy. Zadania są niezależne, wymagania stabilne, a obecny zespół nie jest w stanie obsłużyć wszystkich elementów. To sytuacja, w której zatrudnienie może pomóc.

Blokada decyzyjna. Praca czeka na decyzję architektoniczną, produktową albo prawną. Więcej programistów zwiększy liczbę osób oczekujących, ale nie usunie blokady.

Zależności integracyjne. Każdy moduł z osobna wygląda na gotowy, lecz całość nie działa razem. Rekrutacja może zwiększyć liczbę modułów, a tym samym także liczbę problemów przy integracji.

Niestabilny zakres. Zespół nie kończy zadań, ponieważ wymagania ciągle się zmieniają. Wtedy problemem nie jest przepustowość programistów, lecz sposób podejmowania decyzji i kontrolowania zakresu.

W projektach z dużą liczbą niezależnych komponentów łatwiej znaleźć pracę dla kilku zespołów. W monolicie zależności mogą być silniejsze, choć sam monolit nie oznacza automatycznie braku możliwości skalowania. Czasem można wydzielić moduł, ustabilizować interfejs albo odseparować proces wdrożeniowy bez pełnej przebudowy systemu.

Projekty z obszarów regulowanych mają dodatkowe ograniczenia. Audyt, bezpieczeństwo i zgodność z wymaganiami nie znikają po zatrudnieniu kilku programistów. Można równolegle przygotowywać dokumentację, testy i implementację, ale niektóre decyzje nadal wymagają przejścia przez określoną ścieżkę zatwierdzeń.

Wniosek nie brzmi więc: „nie zatrudniaj”. Brzmi: „zatrudniaj tam, gdzie istnieje niezależna praca, a nie tam, gdzie brakuje wyłącznie kolejnej osoby czekającej na decyzję”.

Strategia skalowania: model Spotify i autonomiczne zespoły zamiast prostego dodawania rąk do pracy

Jeśli firma rośnie, dokładanie ludzi do istniejącego zespołu nie jest jedyną drogą. Można również zmienić granice odpowiedzialności. Zamiast tworzyć jeden coraz większy zespół, organizacja dzieli produkt na obszary, za które odpowiadają mniejsze, możliwie autonomiczne zespoły.

Model Spotify stał się popularną nazwą takiego podejścia. W opisach organizacji Spotify pojawiały się zespoły produktowe, zwane squadami, grupowane wokół obszarów produktu. Miały one dużą samodzielność i odpowiadały za dostarczanie wartości w określonym zakresie. Z czasem sama firma rozwijała sposób pracy, a publikowane opisy nie powinny być traktowane jako gotowy, niezmienny podręcznik wdrożenia.

To ważne zastrzeżenie. Wiele organizacji skopiowało nazwy — squad, tribe, chapter — bez rozwiązania problemu zależności. Samo przemianowanie działów nie tworzy autonomii. Zespół jest autonomiczny dopiero wtedy, gdy ma realny wpływ na swój obszar, dostęp do potrzebnych kompetencji i możliwość podejmowania decyzji bez każdorazowego oczekiwania na akceptację centralnego komitetu.

Skalowanie przez autonomiczne zespoły wymaga kilku warunków:

• odpowiedzialność zespołu musi obejmować konkretny fragment produktu, a nie przypadkową listę technologii;
• granice między obszarami powinny być zrozumiałe dla wszystkich zainteresowanych;
• interfejsy techniczne i kontrakty między usługami muszą być stabilne;
• zespół powinien posiadać kompetencje potrzebne do samodzielnego dostarczenia i utrzymania swojej części produktu;
• decyzje wspólne dla wielu zespołów powinny mieć właściciela, ale nie mogą być automatycznie przenoszone do jednej centralnej kolejki.

W takim układzie dodanie osoby do konkretnego obszaru nie musi zwiększać liczby zależności w całej organizacji. Nadal rośnie złożoność wewnątrz zespołu, ale granice komunikacji pozostają czytelniejsze. Firma skaluje nie tylko liczbę programistów, lecz także strukturę, w której pracują.

Co można zrobić bez pełnej reorganizacji

Nie każda firma potrzebuje wdrażać modelu Spotify. Czasem wystarczą mniejsze zmiany.

Wydzielenie właścicieli obszarów. Zespół nie powinien za każdym razem ustalać od początku, kto odpowiada za moduł, usługę lub proces. Jasna odpowiedzialność skraca ścieżkę decyzji.

Stabilne interfejsy. Jeśli dwa zespoły muszą współpracować, kontrakt między nimi powinien być opisany i testowany. Dzięki temu mogą rozwijać swoje elementy bez ciągłego uzgadniania szczegółów implementacji.

Małe, kompletne zespoły. Lepiej zbudować zespół, który może sam przeprowadzić pracę od analizy do wdrożenia, niż grupę osób posiadających wyłącznie jeden typ kompetencji i uzależnionych od kilku innych działów.

Ochrona zespołu wdrażającego. Onboarding musi mieć właściciela i określony zakres. Jeśli każdy członek zespołu odpowiada po trochu za nowych pracowników, koszt jest rozproszony i trudny do zauważenia.

Automatyzacja powtarzalnych czynności. Automatyczne testy, przygotowanie środowiska i proces wdrażania zmniejszają koszt wejścia do projektu. Nie rozwiązują problemów architektonicznych, ale sprawiają, że nowa osoba szybciej może działać samodzielnie.

Redukcja zakresu. W opóźnionym projekcie najtańszym sposobem odzyskania terminu bywa usunięcie części funkcji, a nie zwiększenie liczby osób. Mniejszy zakres ogranicza liczbę zależności i pozwala skoncentrować zespół na wartości, która jest rzeczywiście potrzebna.

Kiedy powiększenie zespołu ma sens, a kiedy tylko zwiększa koszt

Prawo Brooksa nie jest argumentem przeciwko rekrutacji. Jest argumentem przeciwko rekrutacji pozbawionej diagnozy.

Powiększenie zespołu ma większą szansę zadziałać, gdy:

• zadania są rzeczywiście niezależne;
• wymagania i granice odpowiedzialności są stabilne;
• nowa osoba może otrzymać własny obszar pracy;
• zespół ma czas i kompetencje do wdrożenia;
• narzędzia, dokumentacja i środowisko nie blokują wejścia;
• istnieje sposób sprawdzenia, czy zwiększyła się przepustowość, a nie tylko liczba rozpoczętych zadań.

Ostrożność jest potrzebna, gdy projekt jest już w późnej fazie, a większość decyzji architektonicznych została podjęta. Wtedy nowe osoby mogą pomóc w testach, dokumentacji, migracji, poprawkach lub pracach przygotowawczych, ale niekoniecznie skrócą krytyczną ścieżkę prowadzącą do wydania. Ich użyteczność zależy od tego, czy dla tych zadań istnieją wyraźne granice i czy nie wymagają one ciągłej pomocy od przeciążonych ekspertów.

Nie warto też oceniać decyzji wyłącznie przez liczbę zamkniętych zadań. Po zwiększeniu zespołu należy patrzeć na czas przejścia pracy przez cały proces, liczbę blokad, czas oczekiwania na przegląd, częstotliwość błędów integracyjnych i udział pracy naprawczej. Większa liczba aktywności na tablicy może oznaczać większy ruch, ale niekoniecznie szybsze dostarczenie produktu.

Najważniejsze pytanie brzmi: czy nowa osoba usuwa konkretne wąskie gardło, czy tylko dołącza do kolejki przed tym samym wąskim gardłem?

Jeśli problemem jest brak niezależnej pracy, trzeba najpierw zmienić podział produktu, zakres albo architekturę. Jeśli problemem jest brak decyzji, potrzebny jest właściciel decyzji. Jeśli problemem jest wiedza ukryta w głowach kilku osób, rozwiązaniem będzie uporządkowanie dokumentacji i procesu wdrożenia. Jeśli blokuje nas integracja, kolejni programiści mogą tylko zwiększyć liczbę elementów, które trzeba później połączyć.

Prawo Brooksa działa więc nie jako zakaz skalowania zespołu deweloperskiego, lecz jako test jakości decyzji zarządczej. W opóźnionym projekcie, szczególnie w późnej fazie realizacji, dodatkowe osoby nie są automatycznie dodatkową prędkością. Najpierw trzeba sprawdzić, czy mogą pracować niezależnie, kto przekaże im kontekst i które elementy projektu faktycznie da się zrównoleglić.

Dobrze skalowana organizacja nie polega na tym, że do jednego zespołu stale dokłada się ludzi. Polega na takim podziale odpowiedzialności, by kolejne osoby i zespoły mogły dostarczać wartość bez tworzenia coraz większej kolejki uzgodnień. Dopiero wtedy wzrost zatrudnienia przestaje być reakcją na pożar, a staje się świadomym sposobem budowania zdolności firmy.