„Letos jsme vydali víc funkcí než loni. Tržby jsem neviděl.“ Tohle odpověděl Head of Product, když Tomáš, VP Engineering, slíbil vedení trojnásobný výkon. Business case pro platformní tým je žádost, která takovou odpověď přežije: jeden kvartál kapacity roadmapy a doložený plán, jak se v penězích vrátí do tří kvartálů.
Tomáš (ve skutečnosti se jmenuje jinak) vede tech oddělení v B2B SaaS firmě. Jeho platformní týmy tráví 60 % času udržováním produkce, 2 % otevíráním svých komponent ostatním týmům a 38 % stavěním funkcí. Produktové týmy se bez nich nepohnou, takže každá iniciativa napříč týmy čeká v něčí frontě.
Jeho deck byl dobrý. Závislosti nakreslené jako špagety, autonomní týmy, cíl 3×. Každé číslo v něm bylo v procentech.
Jeden slide chyběl a řekl jsem mu to. V celém decku nebyl ani jeden dolar. Developer Coefficient od Stripe zjistil, že vývojáři stráví 17,3 hodiny ze 41,1hodinového týdne údržbou, špatným kódem a technickým dluhem. Tvoje vedení ten účet už platí, tak mu ukaž fakturu.
Vedení schvaluje datum návratnosti investice
Zeptej se ChatGPT, jak prosadit peníze na platformní tým, a poradí ti, ať to „přestaneš prodávat jako zlepšení v engineeringu a začneš to prodávat jako byznysovou investici“. Pravda, jenže to nestačí. Investice bez data je přání.
Tak to datum řekni. „Dej mi polovinu Q1. Do konce roku ti ji vrátím a od té doby pojedeme rychleji.“ Neškrábeš na dveře kvůli času na platformu. Jsi VP, který prodává investici.
Procento svádí k vyjednávání o procentu. Doba návratnosti investice svádí k rozhodnutí a to rozhodnutí patří lidem v místnosti. Přesně tam ho chceš mít.
Účet je dost velký, aby to unesl. CIO v průzkumu McKinsey přiznali, že 10 až 20 % technologického rozpočtu určeného na nové produkty skončí u tech debtu.
Tomáš měl štěstí. Jeho CEO zažil víkend před výjezdem vedení vlastní moment „vlak nám ujíždí“ a byl připravený roadmapu rozbít. Jenže mandát nevznikne z jedné hodiny mluvení a slide s návratností je to, s čím se budeš vracet pořád dokola. V Mews a ve firmách, kterým od té doby radím, jsem viděl, že ten boj trvá půl roku až rok, než to lidem dojde: neprodáváš pomalejší roadmapu, zrychluješ firmu.
Změř, kam kapacita teče, než si o ni řekneš
Datum návratnosti neprodáš na odhadu dnešního stavu. První slide ukazuje, kam čas teče teď, a čísla musí přijít od týmů, ne od tebe.
Pět kategorií: plánovaná, nebo neplánovaná práce
Rozděl čas každého týmu na práci na roadmapě, investici do platformy, reaktivní práci na produkci (incidenty, on-call, hotfixy), eskalace od zákazníků a pomoc jiným týmům. První dvě kategorie jsou plánované, zbylé tři většinou ne. Neplánovaný podíl je tvoje hlavní číslo: říká, kolik místa na roadmapu tvoje týmy doopravdy mají.
Žádné výkazy hodin
Každý team lead rozdělí člověkodny svého týmu do pěti kategorií. Zabere to patnáct minut a přesnost ±10 % stačí. Dva týdny to jeď jako pilot, pak přepni na klouzavých šest týdnů, protože jeden velký incident dva týdny úplně rozhodí.
Zapiš, kdo o práci požádal
Ke každé kategorii napiš, která divize o práci požádala. Z kapacity se tím stane rozpočet, který můžeš rozdělit: „Tvoje divize má tenhle kvartál 400 člověkodnů, co do nich půjde, rozhoduješ ty.“ Nový požadavek je pak výměna a spor o priority se přesune k lidem, kterým priority patří.
Převeď dny na peníze
Člověkodny krát plná cena jednoho dne, tedy mzda, odvody a režie. To je číslo, které CFO čte. Jestli jsi pro vedení ještě nikdy nenaceňoval technické rozhodnutí, menší verzi téhle úvahy jsem popsal v článku komunikace s vedením.
Takhle vypadalo Tomášovo měření a cíl. Jsou to čísla jedné skutečné firmy, anonymizovaná. Cíl pro produktové týmy je cíl, ne měření.
| Typ týmu | Práce | Dnes | Cíl |
|---|---|---|---|
| Platformní týmy | Udržování produkce v chodu | 60 % | 30 % |
| Platformní týmy | Otevírání komponent ostatním týmům | 2 % | 50 % |
| Platformní týmy | Funkce pro zákazníky | 38 % | 20 % |
| Produktové týmy | Udržování produkce v chodu | 35 % | 10 % |
| Produktové týmy | Změny v platformě (formou příspěvků do jejího kódu) | 3 % | 10 % |
| Produktové týmy | Funkce pro zákazníky | 62 % | 80 % |
Podívej se na poslední řádek. Produktové týmy už teď dávají do funkcí 62 % času.
Brzdí je těch 35 %, kdy se ohlížejí za produkcí, a fronta, ve které stojí na platformu. Víc kapacity na funkce je vedlejší efekt toho, že tohle odstraníš. Jestli chceš, aby se ti na čas tvých týmů někdo podíval zvenku, než tenhle slide postavíš, k tomu je audit produktivity engineering týmů.
Pro srovnání mimo jednu firmu: pravidlo Martyho Cagana ze SVPG dává engineeringu 20 % kapacity hned na začátku, a víc, když je systém ve špatném stavu.
Tvůj platformní tým má stavět funkce až nakonec
Tomášovo pořadí priorit pro platformní týmy: nejdřív produkce, potom otevírání komponent, funkce až nakonec. 30 % na produkci je cílový podíl, ne strop. Když produkce hoří, vyhrává produkce.
Proč funkce až nakonec? Deset autonomních týmů, které všechny potřebují stejných pět lidí ve sdíleném jádru, nejsou deset paralelních proudů. Pár týdnů jedou rychle a pak zase čekají na review, odpovědi a závislosti.
Fronta se jen přesunula. Výzkum DORA tomu říká „downstream disorder“, tedy nepořádek v dalších fázích: co se získá rychlejším psaním kódu, spolknou úzká hrdla v testování, bezpečnostním review a dál.
10 % vlastnit, 90 % otevřít
Malá sada komponent zůstává vlastněná od začátku do konce: autentizace, autorizace, ochrana soukromí, věci, u kterých chceš být opatrný. V Tomášově plánu je to asi 10 % změn. Zbylých 90 % bude „vlastněných, ale otevřených“. Vlastník je oddělí od zbytku, zdokumentuje, sepíše záměry a limity, přidá testy a postaví bezpečné cesty, aby kterýkoli tým mohl přispět, aniž by rozbil jádro.
Příspěvky tečou oběma směry
Produktové týmy mění platformu, když to potřebují. Platformní týmy mění produktový kód, když to potřebuje produkce, třeba když něco spadne nebo výkonově nestíhá. Obě strany musí unést, že jim v kódu sedí někdo jiný. Roky silného vlastnictví obalily v Tomášově firmě každou komponentu byrokracií a on chce 90 % z ní pryč.
Nestav do šuplíku
Žádná schopnost „protože se za tři roky může hodit“. Stav, co tým potřebuje teď. Platforma jde tam, kam jdou produktové týmy, a neutíká jim napřed.
Platformu měř podle toho, jak rychle běží ostatní
Platformní týmy se měří tím, o kolik rychleji dodávají produktové týmy, ne tím, co samy postavily. Tak v praxi vypadá platformní tým podle Team Topologies: interní produkt, který existuje proto, aby zrychlil stream-aligned týmy, tedy ty, které dodávají přímo zákazníkům. O samotné roli jsem psal v článku platform engineer.
Opačný názor si zaslouží férové slyšení. Report DORA za rok 2024 zjistil, že dedikovaný platformní tým zvedá produktivitu týmů o 6 %, ale u těch, kdo platformu používají, klesla průchodnost o 8 %. Špatně udělaná platforma tě zpomalí. Právě proto ji měříš rychlostí ostatních týmů a nejdřív ji dokážeš na jednom úkolu.
Převeď procenta na peníze: slide jeden za tři
Tohle je slide, který Tomáš neměl. Tvoří ho tři čísla.
Kolik ten kvartál stojí
Člověkodny přesunuté z roadmapy krát plná cena dne. To je tvoje investice v penězích.
Kdy se vrátí
Výstup roadmapy, který v investičním kvartálu ztratíš, proti tomu, co po něm získáš, kvartál po kvartálu, dokud průběžný zůstatek nepřejde do plusu. Počítej s tím, že týmy asi na dva měsíce zpomalí, nebo se skoro zastaví, zatímco si osvojují nové nástroje a nový způsob práce. Řekni to na slidu nahlas: zpomalíme, abychom pak jeli rychleji.
Zrychlení si nevymýšlej. Vezmi ho z pilotu (o něm další sekce). Co ukáže benchmarkový úkol při prvním měření, to je tvoje číslo pro Q2, a dál, než pilot dokázal, neextrapoluješ.
Kolik to vynese
Tvůj CPO by měl vědět, kolik tržeb každý kvartál děláte a kolik z nich se připisuje nové funkcionalitě. To je tvoje cena za kvartál roadmapy. Výsledek dej na slide jako hypotézu, ale číslo tam dej. Teprve pak se lidi přestanou přít, jestli to vůbec dovolit.
Takhle to vypadá s čísly vymyšlenými pro tenhle článek (ilustrativní, ne Tomášova). Výstup je v „dnešních kvartálech“, kde 1,0 je kvartál jako ten současný, a z nové funkcionality pochází 3 mil. USD tržeb za kvartál.
| Kvartál | Výstup roadmapy | Průběžný zůstatek | Tržby navíc proti dnešku, pokud adopce vydrží |
|---|---|---|---|
| Q1, investice | 0,5 | −0,5 | −1,5 mil. USD |
| Q2 | 1,2 | −0,3 | +0,6 mil. USD |
| Q3 | 1,4 | +0,1, bod zvratu | +1,2 mil. USD |
| Q4 | 1,6 | +0,7 | +1,8 mil. USD |
Jeden kvartál dáš, tři ti ho vrátí: na konci Q4 jsi 0,7 kvartálu napřed, zhruba 2,1 mil. USD. Když druhý rok udrží rychlost z Q4, je to 0,6 kvartálu výstupu navíc každý kvartál, zhruba 7,2 mil. USD ročně.
Přečti si záhlaví posledního sloupce ještě jednou. „Pokud adopce vydrží“ je námitka Head of Product napsaná na tvém vlastním slidu. Kvůli ní existuje další sekce.
Práce na spolehlivosti a bezpečnosti dostane číslo v tržbách taky. ValueSum od Jadea Rubicka boduje dodanou položku tak, že 100 bodů znamená přidat 100 % ARR za jeden rok, vynásobeno pravděpodobností úspěchu. Jeho příklad se spolehlivostí, krok za krokem:
| Krok | Body |
|---|---|
| Třetině zákazníků kvůli téhle nestabilitě hrozí, že odejdou | 33 |
| Jsou to spíš velcí zákazníci, takže jde zhruba o 45 % tržeb | 45 |
| Skutečné riziko odchodu na zákazníka je asi 20 %: 45 × 20 % | 9 |
| Poškozená pověst to zdvojnásobí: 9 × 2 | 18 |
Rubick ti dává i argument pro stálý podíl na platformu místo boje o každý projekt: „určité procento každé tech organizace by se mělo věnovat věcem, které organizaci časem zefektivní“, protože taková práce „obvykle přijde zkrátka“, když optimalizuješ jen na dodanou hodnotu.
„Dodali jsme víc a tržby se nehnuly“ je správná námitka
Head of Product měl pravdu. To, že zrychlíme stroj, neznamená, že tou rychlostí budeme dodávat správné věci. Report Pendo o adopci funkcí zjistil, že 80 % funkcí v průměrném softwarovém produktu se používá zřídka nebo vůbec.
Business case proto potřebuje druhého vlastníka. Řekl jsem Tomášovi, jak jsme to dělali v Mews, kde jsem jako VP Engineering vybudoval tech z 8 na 80 týmů. Moje KPI, podle kterého mě znali: každý kvartál jsem dodal aspoň 80 % roadmapy. Kdybych nedodal, mohli mě vyhodit.
Sledoval jsem to jako podíl na roadmapě: kolik procent času mých týmů jde na roadmapu a kolik mimo ni. Dva týmy, které z jakéhokoli důvodu pracují mimo roadmapu, ohrozí celý kvartál. Svoje manažery jsem učil pravidlo, podle kterého jsem žil: když mi nepřineseš roadmapu, mám problém i já.
Můj produktový protějšek měl jiné KPI. „Díky, Mariane, žes mi postavil rychlý stroj. Jenže já do něj musím házet věci.“ Jeho prací bylo krmit mou roadmapu věcmi, na kterých záleží, a měřilo se to adopcí produktu. Nastavili jsme to schválně tak, abychom fungovali jako dvojčata.
Rychlejší stroj sám nic neprodá. Někdo musí vlastnit to, co do něj jde.
Každá iniciativa byla zamčená v kvartálu a měla v Jiře vlastní pole se známkou adopce. Přiznám se, známkovali jsme ručně, žádnou automatickou metriku jsme neměli:
| Známka | Co znamená | Počítá se do 65 %? |
|---|---|---|
| Ultra vysoká | Vydělává nám hodně peněz | Ano |
| Vysoká | Podle očekávání | Ano |
| Neutrální | Vydělá, co stála: lidi, licence, infrastrukturu | Ne |
| Katastrofa | Nevydělá ani na svoje náklady | Ne |
| K vyhodnocení | Na známku je brzo, povoleno nejvýš na jeden kvartál | Ne |
K dobrému produktovému rozhodnutí patří i načasování, takže nic nezůstane bez známky déle než kvartál.
Já měl 80 % dodané roadmapy. Šéf produktu vedle mě měl 65 % adopce produktu, tedy známku vysoká nebo ultra vysoká. Čekání se nepočítá, protože čekání peníze nevydělává.
A upřímně, řvali jsme na sebe. „Držím pro tebe rychlou roadmapu a ty do ní házíš šmejd? Pak jsou moji lidi nešťastní a někdo odejde.“
Občas jsem řekl, že nějaká věc do roadmapy nepatří. Občas chtěl on něco označit za úspěch a já řekl, že úspěch to asi není. Jenže to už jsou diskuse, které mají smysl: o hodnotě.
Rubick dochází ke stejnému závěru z druhé strany. Doporučuje každou funkci znovu obodovat tři nebo šest měsíců po dodání a nechat si předpovězené i zpětné skóre. Z jeho práce bych převzal ještě dvě pravidla: hodnotu bodují šéfové produktu nebo divizí, ne tech, a skóre nepoužíváš k hodnocení jednotlivců ani týmů.
Tomášovi se zatím nepodařilo prosadit KPI adopce nahoře, takže jeho verze dvojčat sedí o úroveň níž. Každá autonomní oblast dostane Product Managera a Engineering Managera, kteří spolu vlastní jeden byznysový výsledek. Pár by měl existovat na každé úrovni: tým, director, VP, CTO a CPO. Jestli jsi Engineering Director a stavíš tohle pod úrovní VP, tvůj produktový protějšek je tvoje dvojče.
Dokaž to na jednom úkolu, než si řekneš o celou organizaci
Tomáš sám napsal malou změnu v kódu, svoji první za dva roky. Měla trvat tři hodiny. Review, pipeliny a informace, které nemohl najít, totiž jak změna dopadne na zákazníky, z ní udělaly den vývoje. Schvalovací brány pak protáhly nasazení na týden.
Z toho úkolu se stal benchmark:
| Benchmarkový úkol | Dnes | Konec pilotu | Dlouhodobě |
|---|---|---|---|
| Vývoj | 1 den | ~4 hodiny | 2 hodiny |
| Nasazení | 1 týden | pár dní | 2 hodiny |
Pro pilot si dal jeden cíl. Do prvního měření se zlepší 60 % míst, kde to na cestě toho úkolu drhne. Každé je malé, tady hodina, tam půl hodiny, jinde patnáct minut.
Pokud tvoje týmy pracují s AI agenty, patří do seznamu toho, co drhne, i to, co agent neumí: uvidět pomalý endpoint dřív než zákazník, znát historii produktu, spustit si vývojovou instanci, sledovat nasazení.
Na pilot vyber klidný tým
Tomáš začal s týmem, který měl lehkou roadmapu, aby pilot nezabil plán. Referenci potřebuješ dřív než transformaci.
Půjč mu SWAT na nástroje
Malá skupina pro nástroje postaví, co si pilotní tým nepostaví sám: feature flagy, rychlejší pipeliny, cokoli si seznam řekne. Po pilotu se ze SWATu stane normální tým s víc lidmi.
Oblastí udělej tolik, kolik máš lídrů
Tomáš zkrátil seznam kandidátních oblastí pro autonomní týmy z 18 na 5. Každá oblast potřebuje silného technického a silného produktového lídra a pět takových párů má. Stávající lídři vlastní méně oblastí, zato širších, a žádná nová vrstva vedení nevzniká.
Business case na šest slidů: vzor a co bych přidal
S takovým deckem bych chtěl, aby Tomáš přišel. Každý slide odpovídá na jednu otázku, kterou se někdo z vedení stejně zeptá.
| Slide | Otázka, na kterou odpovídá | Co na něm je |
|---|---|---|
| 1. Kolik stojí dnešek | Kam jdou naše peníze na vývoj? | Rozdělení kapacity, neplánovaný podíl, v penězích, podle divize, která práci zadala |
| 2. Proč jsme pomalí | Proč nás víc lidí nezrychlí? | Sdílené komponenty, na které čeká každý tým |
| 3. Dohoda o kapacitě | Na co budou týmy místo toho dávat čas? | Cílové rozdělení podle typu týmu, pravidlo 90/10, report každý sprint |
| 4. Výměna | Čeho se vzdáme a kdy se nám to vrátí? | Cena kvartálu, průběžný zůstatek, tržby, pokud adopce vydrží |
| 5. Lakmusový test | Jak to poznáme, než vsadíme celou organizaci? | Benchmarkový úkol, pilotní tým, datum prvního měření |
| 6. Kdo vlastní výsledek | Kdo zařídí, aby rychlejší stroj vydělával? | KPI za delivery, KPI za adopci, vlastníci jménem, škála známek |
Osnovu, tabulku kapacity a tabulku návratnosti jsem dal do kitu zdarma: stáhni si kit pro business case platformy (zip, 16 kB, zatím anglicky: Markdown, Word a tři tabulky v CSV, bez e-mailu).
Přines návrh, ne jen fotku stavu. Samotný snímek svádí k otázce „proč tolik na support?“ a pak rozhodne někdo jiný. Data ať sbírají tvoji directoři. Tvoje práce je vyložit je a navrhnout jednu změnu.
Dohodu porovnávej s realitou každý sprint. Každý kvartál jsem měl svých 100 % rozdělených do tří dohodnutých přihrádek, produkt, tech a všechno ostatní, a každý sprint jsem je kontroloval. Když rozdíl roste, správné rozhodnutí je někdy paradoxní: na dva sprinty technickou práci zastavit a dělat produktovou, aby se rovnováha vrátila.
A ta těžká část přijde až po „ano“. Ne každý tu změnu udělá. Jedni nepřevezmou vlastnictví, druzí neumí pracovat v páru, protože mají velké ego. Pár z nich bude muset odejít.
Tomáš odešel se souhlasem spustit pilot. První měření ho teprve čeká, takže jeho benchmarková čísla ti zatím ukázat nemůžu. Až budou, doplním je sem. Co řekne tvoje vedení, až si řekneš o jeden kvartál a slíbíš tři zpátky? Jestli chceš ten slide postavit se mnou, než ho odprezentuješ, k tomu je můj mentoring pro CTO.
