Zespół rośnie, velocity spada: diagnoza w pięciu krokach

Podwoiłeś zespół inżynierski, a produkt rozwija się wolniej niż rok temu. To nie anomalia, tylko najczęstszy wzorzec skalowania: bez zmiany systemu pracy każda kolejna osoba dokłada więcej narzutu koordynacji niż mocy wytwórczej. Przyczyny prawie zawsze leżą w jednym z pięciu miejsc: rozmyty ownership, za dużo pracy w toku, wolne decyzje, rosnący dług techniczny albo rytm spotkań, który zjada tydzień. Diagnozę da się zrobić w tydzień na danych, które już masz. Prowadziłem ten proces m.in. w Zety podczas wzrostu ze zbioru 18 osób do 185, przy 100M globalnego ruchu, i poniżej opisuję, od czego zaczynam.

Matematyka jest bezlitosna: liczba potencjalnych ścieżek komunikacji rośnie kwadratowo z liczbą osób. Zespół 6-osobowy ma 15 par komunikacyjnych, 20-osobowy ma 190. Jeśli struktura pracy się nie zmienia (jeden backlog, wszyscy wiedzą o wszystkim, decyzje u foundera), organizacja wydaje coraz większy procent czasu na synchronizację. Nowi ludzie nie są problemem. Problemem jest system zaprojektowany na rozmiar, którego już nie masz.

Rozmyty ownership: objawia się jako "to nie moje" albo trzy osoby robiące to samo, metryka do sprawdzenia to liczba obszarów bez jednego właściciela. Za duży WIP: wszystko jest w toku i nic nie wychodzi, metryka to liczba równoległych inicjatyw względem liczby zespołów. Wolne decyzje: zadania czekają na kogoś z góry, metryka to czas od pytania do decyzji. Dług techniczny: proste zmiany zajmują tygodnie i pojawiają się regresje, metryka to czas wdrożenia małej zmiany oraz liczba hotfixów. Przeciążony rytm: kalendarze są pełne, praca po godzinach, metryka to godziny spotkań na osobę tygodniowo.

Krok 1: policz przewidywalność. Weź plany z ostatnich 3 cykli i porównaj z tym, co realnie wyszło na produkcję. Wynik poniżej 60-70% oznacza, że planowanie jest fikcją i zespół to wie, co samo w sobie demotywuje.

Krok 2: zmierz przepływ jednej zmiany. Wybierz pięć niedawnych, małych zadań i odtwórz ich drogę: od decyzji "robimy" do produkcji. Policz, ile z tego czasu to praca, a ile czekanie (na review, na decyzję, na środowisko, na inny zespół). W spowolnionych organizacjach czekanie to zwykle 70-80% czasu przejścia. Naprawia się kolejki, nie ludzi.

Krok 3: zmapuj ownership. Lista obszarów produktu i systemu, przy każdym jedno nazwisko właściciela. Każdy obszar bez nazwiska albo z trzema nazwiskami to źródło tarcia. W rosnących organizacjach ta mapa niemal nigdy nie istnieje na piśmie i samo jej spisanie wywołuje najważniejsze rozmowy kwartału.

Krok 4: policz WIP. Ile inicjatyw jest formalnie "w trakcie"? Jeśli liczba przekracza liczbę zespołów dwukrotnie lub bardziej, macie problem priorytetyzacji przebrany za problem mocy przerobowych. Kończenie pobija zaczynanie: zamrożenie połowy inicjatyw zwykle przyspiesza całość.

Krok 5: audyt kalendarza. Suma godzin spotkań na inżyniera tygodniowo plus rozkład (czy zostają nieprzerwane bloki na pracę głęboką). Powyżej 10-12 godzin spotkań tygodniowo u inżyniera liniowego produkcja kodu spada nieproporcjonalnie, bo reszta czasu jest pocięta na kawałki zbyt krótkie na złożone zadania.

Napraw w tej kolejności: najpierw WIP (zamrożenie nadmiaru inicjatyw daje efekt w dwa tygodnie i nie wymaga niczyjej zgody poza founderem), potem ownership (mapa obszarów i właścicieli), potem rytm decyzji (kto decyduje o czym bez eskalacji), na końcu dług techniczny (bo jego spłata wymaga mocy, którą uwalniają pierwsze trzy kroki). Odwrotna kolejność, czyli start od wielkiego refactoringu, to najczęstszy sposób na pogłębienie problemu.

Ta sekwencja to rdzeń mojego sprintu operatorskiego: diagnoza na danych, potem przebudowa rytmu na żywym zespole. W InterviewMe taka przebudowa (7 autonomicznych zespołów, jasny ownership, kultura eksperymentów) poprzedziła wzrost konwersji o 208% i przychodu o 320%, szczegóły w case studies.

Czy spadek velocity przy wzroście zespołu jest nieunikniony? Przejściowy spadek przy każdej fali zatrudnień jest normalny (onboarding kosztuje czas seniorów). Trwały spadek nie jest i zawsze wskazuje na system: strukturę zespołów, decyzje, WIP albo dług. Organizacje, które skalują się dobrze, przebudowują sposób pracy przy każdym mniej więcej podwojeniu liczebności.

Od jakiej wielkości zespołu potrzebne są autonomiczne zespoły? Umownie od 8-12 inżynierów jeden wspólny backlog przestaje działać. Podział na 2-3 zespoły z własnym obszarem, właścicielem i celem zwykle daje więcej niż kolejne zatrudnienia. Kryterium podziału: minimalna liczba zależności między zespołami, nie symetria wielkości.

Czy velocity w story pointach to dobra metryka? Do porównywania zespołów między sobą albo do rozliczania ludzi: nie, bo natychmiast zostanie zoptymalizowana pod wynik. Do obserwowania trendu jednego zespołu w czasie: umiarkowanie. Lepsze są przewidywalność (plan vs wykonanie) i czas przejścia zmiany od decyzji do produkcji, bo obie mierzą system, a nie punkty.

Ile trwa odwrócenie trendu? Pierwsze efekty (zamrożenie WIP, odblokowanie decyzji) widać w 2-4 tygodnie. Trwała zmiana rytmu pracy i struktury to kwartał. Jeśli po 90 dniach świadomej przebudowy dane nie drgnęły, diagnoza była błędna i warto wrócić do kroku 1 z kimś z zewnątrz.

Policz przewidywalność ostatnich trzech cykli (krok 1). To godzina pracy i najszybszy test, czy problem jest w systemie. A jeśli chcesz przejść całą diagnozę z kimś, kto robił to od 18 do 185 osób, umów bezpłatny audyt: w 30 minut wskażę, gdzie tracisz velocity i co naprawić najpierw. Zakres opisuję na stronie optymalizacji KPI i growth.