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ť.

A ten násobok sa dá vyčísliť. Dva tímy, obidva na 90 % vyťaženia, rovnako veľké, rovnako schopné. Prvý berie položky tak, ako prídu: od pol dňa po tri týždne. Druhý tú istú prácu krája na kusy, z ktorých ani jeden netrvá dlhšie než pár dní. Druhý tím sedí presne na tom čísle, ktoré Kingman dáva pre 90 %: deväťnásobok času práce strávi vo fronte. Prvý je na vyše dvadsaťnásobku. Rovnaké vyťaženie, rovnakí ľudia, dvaapolkrát dlhší front.

Rozptyl veľkostí položiek teda nie je samostatná sťažnosť vedľa preťaženia. Je to druhý člen tej istej rovnice. Tím, ktorý si stráži kapacitu a pritom berie ľubovoľne veľké kusy, si polovicu tej ochrany zase rozdal.

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.

Lenže tá prvá veta platí len tak, ako sa to číslo číta, nie ako to naozaj je. Manažérka na 95 % nechráni rozpočet. Chráni počet ľudí. Sú to dve rôzne veci a nákladové účtovníctvo ich zlepuje do jednej. Minie sa rovnako: tie isté mzdy, ten istý mesiac, či je vyťaženie 95 alebo 75. Rozdiel je v tom, čo za tie peniaze organizácia dostane. Pri 95 % kupujú tie mzdy prevažne front. Náklad na jednu dodanú funkčnosť je vyšší, nie nižší. Vyťaženie chráni rozpočtovú položku a míňa rozpočet.

Kto tú páku drží

Prvý ťah, po ktorom čitateľ tohto textu siahne, býva prerozdelenie kapacity. Šesťdesiat percent na produktovú prácu, dvadsať na zlepšovanie, dvadsať na rezervu. Súčet je sto. To nie je rezerva. To je ten istý plný tanier rozdelený na tri kôpky. Frontu je jedno, ako je práca pomenovaná. Záleží mu na tom, koľko jej je v systéme naraz.

Znížiť vyťaženie je pritom ťah, ktorý sa zdola urobiť nedá. To číslo drží ten, kto rozhoduje, koľko práce sa naraz pustí dnu: v jednom tíme product owner, na úrovni oddelenia riaditeľ vývoja, vyššie ten, kto schvaľuje portfólio. Ak túto vetu čítate a tú páku nedržíte, odporúčanie „znížte vyťaženie“ je adresované niekomu inému.

Zostáva vám druhá páka, ktorá vedie k tomu istému číslu inou cestou. Priebežný čas sa rovná množstvu rozrobenej práce delenému priepustnosťou. Držte strop na počte súbežne rozrobených položiek pod tým, čo tím naozaj zvládne, a vyťaženie klesne samo. Vyťaženie totiž nie je páka, je to výsledok. Financie pri tom nikdy neuvidia číslo pod stovkou, lebo sa nič také nevykazuje. Vykazuje sa strop na rozpracovanej práci, a to je prevádzkové rozhodnutie, nie rozpočtové.

Druhá vec, ktorá nepotrebuje povolenie, je veľkosť položiek. Prepočet vyššie hovorí, koľko stojí rozptyl: zúžiť ho na polovicu kúpi zhruba to isté, čo desať bodov vyťaženia. Rozdiel je, že o desiatich bodoch rozhoduje niekto nad vami a o tom, aký veľký kus si tím vezme, rozhoduje tím.

Na celoorganizačnej úrovni existuje jediný ťah a nie je to reorganizácia. Je to zmena v tom, čo sa počíta. Kým jediným meradlom zostane čas nečinnosti, vyťaženie vyhrá zakaždým, lebo náklad na čakanie nie je v žiadnom výkaze. Postavte vedľa neho druhé číslo: pomer času čakania k času práce, alebo priebežný čas od zadania po dodanie. Nie ako náhradu, ako protiváhu. Manažér, ktorý dnes vykáže 75 %, nemá čím argumentovať. Ten istý manažér, ktorý vedľa sedemdesiatich piatich ukáže pomer 2:1 tam, kde ho susedné oddelenie má 9:1, argumentovať čím má.

Ani jeden z tých ťahov nie je zadarmo. Strop na rozpracovanej práci znamená, že niekomu poviete nie, alebo aspoň nie teraz. Menšie kusy znamenajú, že sa rozreže aj to, čo sa rozrezať nechce. Matematika je na tom celom tá ľahšia časť. Ťažšia je tá veta, ktorú kvôli nej treba niekomu povedať.

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 číslo nikto nezbiera, to je odpoveď sama: príliv práce do tímu nikto nepočíta a preťaženie sa nabalí nepozorovane, cez incidenty, výpomoc iným tímom a stretnutia.

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.