Všetci sú zaneprázdnení a nič sa nedodáva

Jedna riaditeľka vývoja, s ktorou som spolupracoval, otvorila na štvrťročnom prehľade dashboard s vyťažením zdrojov. Všetkých šesť tímov vyťažených medzi 93 a 97 percentami. Samá zelená. Predložila to ako prevádzkový dôkaz: organizácia beží naplno, žiadne plytvanie, všetci pracujú.

Dvadsať minút nato sa viceprezident pre produkt spýtal, prečo je feature odhadnutá na tri týždne už jedenásty týždeň „v procese“. Riaditeľka nahliadla do poznámok. „Tím je plne vyťažený. Pracujú na tom.“

Tím bol plne vyťažený. To bol ten problém.

Pattern, ktorý nikto nepomenuje

Každá softvérová organizácia má svoju verziu tohto stretnutia. Nástenka je plná. Každý má úlohu. Kapacita sprintu je rozdelená na 100 percent. A predsa: featury sa odkladajú. Termíny sa posúvajú. „Dvojtýždňové story“ trvajú šesť týždňov. Diagnóza je vždy lokálna: zlé odhady, nejasné požiadavky, priveľa stretnutí, primálo seniorných vývojárov.

Nikto sa nepozrie na číslo vyťaženia a nepovie: to je tá príčina.

Nie nedostatok ľudí. Nie zlé riadenie. Preťaženie. Organizácia považuje plné vyťaženie za znak zdravia. Je to presne naopak: systém, ktorý beží na 95 % s premenlivou prácou, má matematicky zaručené, že bude produkovať dlhé fronty. Dôkaz existuje od roku 1961. Skoro nikto v softvéri si ho neprečítal.

Matematika, ktorú nikto nepreveruje

Ako dlho práca čaká vo fronte, závisí od troch vecí: aká premenlivá je práca, ako veľmi je systém vyťažený a ako dlho trvá jedna jednotka práce. Prvé dve sa navzájom násobia. Pri miernom vyťažení spôsobuje premenlivosť len drobné výkyvy. Pri vysokom vyťažení tá istá premenlivosť spôsobuje katastrofu. Vzťah nie je lineárny. Je exponenciálny.

John Kingman to dokázal v roku 1961 pre akýkoľvek systém s obmedzenou kapacitou a premenlivým dopytom. Stačí samotný faktor vyťaženia. Pri 50 % sa čas čakania rovná času práce: zvládnuteľné. Pri 80 % sa zoštvornásobí. Pri 90 % je deväťnásobkom času práce. Pri 95 % devätnásťnásobkom. Pri 99 % deväťdesiatdeväťnásobkom.

Pri 50 % systém dýcha. Pri 90 % lapá po dychu. Pri 95 % je fakticky rozbitý. Prechod z „v poriadku“ do „všetko mešká“ nie je postupný. Je to zráz.

A softvér je ten najhorší prípad. Premenlivosť zosilňuje prirážku za vyťaženie. Čím premenlivejšia práca, tým strmší zráz. Vývoj softvéru padne podľa ktorejkoľvek priemyselnej klasifikácie do pásma strednej až vysokej premenlivosti. „Päťbodová story“ trvá dva dni alebo tri týždne. Opravy chýb sa pohybujú od piatich minút po päť týždňov.

Vývojár začína týždeň s čistým plánom. Do stredy mu incident v produkcii zhltol deň, žiadosť o súčinnosť od iného tímu pohltila celé doobedie a požiadavky na hlavnú featuru sa zmenili. Plán neprežil stret so systémom. To nie je zlyhanie plánovania. To je premenlivosť.

Don Reinertsen pred svojimi kurzami vývoja produktov robí prieskum medzi manažérmi. Sami uvádzajú 98,5 % vyťaženia. Pri takej záťaži a strednej premenlivosti čaká dvojtýždňová úloha 98 týždňov, kým sa jej vôbec niekto dotkne.

Dva roky. Za dva týždne práce. Nie rétorika. Aritmetika.

Jedna feature, dve štruktúry

Vezmime jednu featuru. Dva týždne vývojovej práce.

V cross-funkčnom tíme, ktorý beží na 80 %, matematika predpovedá osem týždňov čakania plus dva týždne práce: spolu desať týždňov. Aktívna práca je iba 20 % priebežného času. Zvyšok je front. Ten pomer nie je nezvyčajný. Väčšina tímov, ktoré ho merajú, sa pohybuje medzi 5 a 15 percentami.

Teraz pošlime tú istú featuru postupne cez tri komponentové tímy: backend, API, frontend. Podiel každého tímu zaberie zhruba týždeň reálnej práce. Každý tím je vlastný front. Každý beží na 90 %, lebo manažéri tlačia na vyššie čísla.

Každá fáza: deväť týždňov čakania, jeden týždeň práce. Tri fázy: tridsať týždňov.

Tá istá feature. Tí istí ľudia. Tie isté zručnosti. Trojnásobný priebežný čas. Jediný rozdiel: ako veľmi je systém vyťažený a cez koľko frontov práca prechádza. Každá organizačná hranica pridáva front. Každý front pridáva nezávislý čas čakania. Fronty sa násobia.

Aj výroba si tým musela prejsť. Quick Response Manufacturing predpisuje 80 až 85 % vyťaženia. Firmám, ktoré sa toho predpisu držali, klesli priebežné časy o 80 % a zdvojnásobili sa im tržby. Výroba má nižšiu premenlivosť než softvér. Softvér beží horúcejšie.

A tak začnú určovať priority

Keď všetko mešká, niekto navrhne lepšie určovanie priorít. Tá logika znie správne: ak nemôžeme stihnúť všetko, urobme aspoň dôležité veci ako prvé.

Lenže určovanie priorít v systéme s 19-násobnými časmi čakania nie je prideľovanie zdrojov. Je to politický súboj. Feature, ktorá sa posunie na začiatok frontu, nie je tá s najvyššou hodnotou pre zákazníka. Je to tá, za ktorou stojí človek s najväčšou organizačnou váhou: najhlasnejší hlas, najvyšší titul, najväčší rozpočet. Feature toho vedúceho predbehne celý rad. Ten za ním čaká ďalší mesiac. Jeho sponzor eskaluje. Teraz súťažia o ten istý preťažený front dvaja vedúci.

Potom príde reportovanie pokroku. Týždenné statusy. Semaforové dashboardy. Prezentácie ukazujúce, že feature je „v procese“ a „podľa plánu“. Report o pokroku neexistuje na to, aby informoval. Existuje na to, aby upokojil: aby povedal sponzorovi „pracujeme na tom“, takže ten ďalší týždeň prestane eskalovať. Report kupuje čas. Dodávku nekúpi.

Slučka sa uzatvára. Vysoké vyťaženie produkuje fronty. Fronty produkujú politické určovanie priorít. Určovanie priorít produkuje eskaláciu. Eskalácia produkuje reporty o pokroku. A reporty o pokroku produkujú práve dosť zdania pohybu na to, aby nikto nespochybnil číslo vyťaženia, ktoré celý ten cyklus naštartovalo. Na dashboarde je stále zelená.

Prečo to každá organizácia aj tak robí

Pasca vyťaženia nestojí na neznalosti. Stojí na štruktúre stimulov.

Nákladové účtovníctvo považuje nečinných ľudí za plytvanie. Tím na 70 % vyťažení vyzerá v každom reporte, ktorý sa dostane na financie, ako 30 % premárneného rozpočtu. Manažérov hodnotia podľa toho, či sú všetci zaneprázdnení, nikdy nie podľa toho, či práca prúdi. „Slack“ (voľná kapacita) znie ako lenivosť. Navrhnúť 80 % vyťaženie v organizácii, ktorá meria efektívnosť využitia zdrojov, je ako pýtať si povolenie premrhať pätinu rozpočtu.

Tá asymetria siaha hlbšie. Nikto nemeria náklady na čakanie. Každý meria náklady na nečinné ruky. Neviditeľný náklad: feature, ktorú zákazník potreboval v januári, dorazí v apríli. Stratené tržby, narušená dôvera, konkurent, ktorý dodal skôr. Obrovský náklad, lenže rozptýlený naprieč projektmi, štvrťrokmi a vzťahmi, ktoré si nikto nespojí. Viditeľný náklad: manažér prejde okolo vývojára, ktorý premýšľa namiesto toho, aby písal. „Potrebuješ nejakú prácu?“ Malý náklad, zato sústredený na jednom dashboarde, na jednom stretnutí, v hodnotení jedného manažéra. Malý viditeľný náklad vyhráva zakaždým.

Manažérka, ktorá vykáže 95 % vyťaženie, chráni svoj rozpočet. Manažérka, ktorá vykáže 75 % vyťaženie, chráni svoju dodávku. Organizácia tú prvú odmeňuje a tú druhú spochybňuje.

Ten dashboard

Štvrťročný dashboard riaditeľky vývoja. Šesť tímov, samá zelená. 93 až 97 % vyťaženia.

Čísla sa nezmenili. Zmenilo sa to, čo znamenajú. 95 % vyťaženie nie je úspech. Je to predpoveď: budúci štvrťrok sa niekto v tej miestnosti opäť spýta, prečo trojtýždňová feature trvala jedenásť týždňov. A dashboard bude stále zelený.

Dve otázky skôr, než sa to stretnutie odohrá.

Aké je vyťaženie vášho tímu? Ak to neviete, nikto neriadi tú páku, ktorá určuje váš priebežný čas.

Aký je pomer času čakania k času práce pri vašich posledných piatich dokončených featurách? Ak je odpoveď nad 5:1, číslo vyťaženia na tom dashboarde vysvetľuje prečo.