Petr chtěl být u rozhodování. Manažer mu nabídl hodinu.

Petr Konečný je fiktivní postava. Jeho příběh je ilustrační scénář mentoringu, ne zkušenost skutečného klienta ani doložený výsledek mentoringu. Čísla, rozhovory a pracovní situace jsou součástí tohoto fiktivního příkladu.

Když máš cíl, ale nemáš kde ho zkoušet

Petr měl konečně rozvojovou roadmapu, kterou skutečně používal. Nebyl to další dokument se seznamem věcí, které by se někdy hodilo naučit. Každé ráno se do ní na chvíli podíval, viděl svůj současný fokus a mohl si připomenout, čemu chce při práci věnovat pozornost. Po nedávné schůzce s klientem navíc vědomě změnil pořadí svých priorit. Naléhavost vysvětlování byznysového dopadu technických řešení se tehdy kvůli konkrétnímu termínu zvýšila, a když schůzka proběhla, zase klesla. Přesto se Petr rozhodl této oblasti dál věnovat. Při stejném pracovním skóre 1,00 jako u trade-offů mu dávalo smysl pokračovat právě tady.

Pořád ho zajímalo, jestli se jednou posune ze seniorního vývojáře k architektonické odpovědnosti. Při prvních setkáních s Igorem ale zjistil, že takový posun pravděpodobně nebude znamenat jen složitější technické úkoly a větší slovo při výběru technologií. Bude se muset naučit připravovat rozhodnutí, do kterých vstupují náklady, termíny, produktové potřeby a rizika. A především bude muset dokázat vysvětlit technické souvislosti lidem, kteří za tyto věci odpovídají, aniž by sami potřebovali rozumět implementaci.

Rozuměl tomu, proč je to důležité. Měl dokonce několik otázek, podle kterých by mohl své vlastní vysvětlení připravovat. Jenže když se podíval na běžný pracovní týden, většina takových rozhovorů probíhala někde jinde. Petr se účastnil technických diskusí, konzultoval řešení s kolegy a občas dostal prostor něco vysvětlit klientovi. Rozhodování o větších investicích nebo prioritách ale zpravidla řešil jeho projektový manažer s dalšími lidmi z vedení.

Na dalším mentoringu proto Petr otevřel problém, který ho na projektu trápil už dlouho. Technický dluh podle něj postupně rostl. Vývojáři na něj upozorňovali, ale k větším změnám se dostávali zřídka. Vždycky bylo něco naléhavějšího, nějaká nová funkcionalita nebo termín, který měl přednost. Petr měl čím dál silnější pocit, že by se o těch věcech rozhodovalo jinak, kdyby vedení skutečně rozumělo tomu, kolik práce jim současný stav přidělává.

"Já si někdy říkám, jestli to náš manažer dokáže vedení vůbec pořádně vysvětlit," řekne Igorovi. "On tam za nás ty technické věci řeší. Ale když pak vidím, co dostane prioritu, tak mám občas pocit, že jim ten dopad technického dluhu prostě nedochází."

"A víš, jak jim ho vysvětluje?" zeptá se Igor.

"No, přímo u těch schůzek nejsem."

"Takže nevíš."

Petr se opře do židle. "Tak když to řekneš takhle..."

"Zkus mi říct, co skutečně víš. Upozorňujete na technické problémy, ale některé investice se opakovaně odkládají. To je výsledek, který vidíš. Jenže z něj ještě nepoznáš, jestli manažer něco špatně vysvětlil, jestli tomu vedení nerozumělo, nebo jestli rozumělo a rozhodlo se dát přednost něčemu jinému."

Petr se chce ohradit, ale nenachází konkrétní příklad, který by jeho původní závěr podpořil. Zná technickou cenu některých rozhodnutí. Ví, kolik zbytečné práce podle něj týmu přidělávají. Neví však, jaké varianty a důsledky se při jednání s vedením skutečně probírají. Dosud mu to příliš nevadilo. Vlastně mu vyhovovalo předpokládat, že kdyby tam seděl on, dokázal by význam některých problémů vysvětlit lépe.

"Ale já se k tomu rozhodování právě chci dostat," namítne. "Pokud chci jednou dělat architekta, nechci jen čekat, až někdo rozhodne, a pak nadávat, že to bylo špatně."

"To je rozumný důvod," odpoví Igor. "Jen bych ho nepostavil na předpokladu, že tvůj manažer něco nezvládá. Co kdybys místo toho zkusil zjistit, jestli se můžeš na přípravě některého z těch rozhodnutí podílet?"

Petr chvíli přemýšlí. S manažerem má pravidelné 1:1 a o svém dalším rozvoji už spolu několikrát mluvili. Nemusí tedy vymýšlet žádnou zvláštní cestu k vedení ani se pokoušet získat odpovědnost, kterou zatím nemá. Může začít obyčejnou otázkou, jestli existuje prostor, kde by si potřebnou práci dokázal vyzkoušet.

Místo na meetingu nedostal

Na následujícím 1:1 Petr nejdřív vysvětlí, čemu se chce věnovat. Nezačne technickým dluhem ani kritikou rozhodování na projektu. Popíše svůj současný rozvojový cíl: umět připravit technický argument tak, aby podle něj člověk mimo vývoj dokázal posoudit přínosy, náklady, omezení a rizika určitého postupu. Zatím se nejvíc pohybuje v samotné implementaci a chybí mu zkušenost s tím, jak se podobné podklady používají při skutečném rozhodování.

"Ty se s vedením o technických věcech bavíš pravidelně, ne?" zeptá se Petr na 1:1 svého manažera.

"Jo. Zhruba jednou za dva týdny máme schůzku, kde se toho probírá víc. Občas tam řešíme technická rozhodnutí, investice nebo rizika, která potřebujeme vysvětlit i mimo vývoj. Proč?"

"Napadlo mě, jestli bych se někdy nemohl připojit. Nechci tam hned o něčem rozhodovat. Ale rád bych viděl, jak ty diskuse probíhají, a časem se do některé třeba zapojil."

Manažer se nad tím zamyslí, ale Petra příliš dlouho v nejistotě nenechá.

"Na ty pravidelné schůzky bych tě zatím nebral. Řešíme tam i věci, které se tvého projektu vůbec netýkají, a nechci ti přidávat další meeting každé dva týdny. Už teď máš dost práce. Potřebuju, aby ses pořád hlavně věnoval vývoji."

Petr je zklamaný. Nečekal, že se zítra stane součástí vedení, ale představoval si, že by mohl alespoň poslouchat. Zrovna tenhle typ diskusí přece potřebuje poznat. Na okamžik ho napadne, že se opakuje stejný problém jako u technického dluhu: aby mohl získat větší odpovědnost, potřebuje zkušenosti, ale bez větší odpovědnosti se k nim nedostane.

Manažer však pokračuje dřív, než Petr začne vysvětlovat, proč by mu další schůzka vlastně nevadila.

"To ale neznamená, že na tom nemůžeš pracovat. Jestli chceš zkusit připravit podklad pro nějaké rozhodnutí, můžeme vybrat konkrétní technické téma. Kolik času bys na první pokus potřeboval?"

Petr si zkusí představit, co by vlastně měl odevzdat. Nechce připravovat rozsáhlou analýzu každé dostupné varianty. Potřebuje vzít problém, kterému technicky rozumí, a pokusit se ho popsat pro člověka, který má jiné starosti než implementační detaily.

"Na první verzi bych si vzal tak hodinu," odhadne. "A pak bych s tebou potřeboval projít, jestli je to vůbec použitelné. Třeba půl hodiny?"

"To můžeme zkusit. Vybereme něco, co budu opravdu potřebovat vysvětlit dál. Ty připravíš svůj pohled, společně se na něj podíváme a já rozhodnu, co z toho použiju. Na schůzku s vedením půjdu zatím sám. Dává ti to smysl?"

Petr přikývne. Není to přesně to, co chtěl, ale nedostal jen příslib, že se na jeho rozvoj někdy podívají. Domluvili se na konkrétní práci, která se má stát v pracovní době a která může manažerovi pomoci s něčím, co by stejně musel řešit. Zároveň je jasné, kde pokus končí. Petr připraví technický vstup, dostane zpětnou vazbu a manažer si ponechá odpovědnost za výsledné sdělení i za jednání s vedením.

Když to později Igorovi popisuje, stále je na něm trochu vidět zklamání.

"Chtěl jsem se dostat k tomu, jak se reálně rozhoduje. Zatím budu dělat podklady někomu, kdo tam pak půjde místo mě."

"A co ses chtěl vlastně naučit?" zeptá se Igor. "Sedět na meetingu, nebo připravit informaci, podle které může někdo rozhodnout?"

"To druhé. Ale samozřejmě bych jednou chtěl umět i tu diskusi vést."

"Pak bych ten první pokus úplně nezatracoval. Připravíš něco ke skutečnému rozhodnutí a člověk, který za tu komunikaci odpovídá, ti řekne, co je na tom použitelné a co chybí. To už je docela dobrá příležitost zjistit, jak na tom jsi."

Petr se nad tím zamyslí. Mohl se dál snažit prosadit svou účast na schůzkách, ale zatím by jen vyjednával o větším množství času, aniž by měl co ukázat. Takhle dostal příležitost udělat první konkrétní pokus. A pokud při něm zjistí, že mu něco podstatného chybí, nebude to jen obecný pocit, že potřebuje více zkušeností.

Když se chceš rozvíjet v něčem, co dnes nepatří do tvé běžné pracovní odpovědnosti, nemusí být nejlepší první krok žádost o novou roli nebo přístup ke všem schůzkám, kde se ta práce děje. Zkus nejdřív zjistit, jakou konkrétní část té odpovědnosti bys mohl převzít v omezeném rozsahu. Ideálně tak, aby tvůj výstup měl smysl i pro člověka, který ti ten prostor poskytne. Petr nevyjednal účast na rozhodování, ale získal skutečné téma, čas na přípravu a zpětnou vazbu od někoho, kdo s výsledkem pracuje.

Samozřejmě ne vždy se podobná příležitost podaří najít. Pak můžeš vzít starší rozhodnutí a zpětně připravit podklad, případně si vyzkoušet rozhovor se simulovaným netechnickým stakeholderem, třeba pomocí AI. Pro první trénink to může být užitečné. Jen je potřeba rozlišovat, co tím skutečně ověřuješ. Simulace ti může pomoct odhalit slabé argumenty nebo otázky, na které neumíš odpovědět. Nenahradí ale reálný pracovní kontext, skutečné vztahy, důsledky rozhodnutí ani člověka, který za ně odpovídá.

Problém, který dobře zná. A proto ho chce konečně vyřešit.

Manažer nakonec vybere téma, na kterém Petr pracoval už mnohokrát. Jde o starší sdílenou část aplikace, ve které se vyhodnocují cenová pravidla, slevy a některé zákaznické výjimky. Původně možná dávala její struktura dobrý smysl, ale postupně do ní přibývaly nové produkty, speciální obchodní podmínky a další případy, které se nevešly do původního návrhu. Výsledkem není žádná úplně rozbitá komponenta. Jen část systému, ve které je čím dál obtížnější změnit jednu věc a mít rozumnou jistotu, že tím člověk nerozhodil něco jiného.

Petr ten problém zná dobře. Pravidla jsou navzájem provázaná, některé změny ovlivňují zdánlivě nesouvisející výpočty a automatické regresní testy nepokrývají všechny důležité kombinace. I když se má upravit poměrně malá věc, vývojář musí nejdřív pochopit několik souvisejících cest a po implementaci věnovat dost času ověřování. Když se to děje opakovaně, nejde už jen o nepříjemný kód. Tým kvůli němu spotřebovává kapacitu, kterou by mohl využít na jinou práci.

A právě teď potřebuje tým tuto část aplikace znovu měnit. Současnou úpravu by podle Petrova odhadu zvládli přibližně za čtyři vývojářské dny a jeden další den testování. Technicky není problém pokračovat stejně jako dosud. Petr si ale myslí, že když už do této části systému znovu vstupují, mohl by být vhodný okamžik udělat omezený refactoring: oddělit nejproblematičtější pravidla, zmenšit jejich vzájemné provázání a doplnit testy, aby podobné změny příště nestály tolik času.

Je to přesně ten typ problému, o kterém už několik let mluví jako o technickém dluhu. Jenže tentokrát si nemůže vystačit s větou, že by se to mělo konečně opravit. Má připravit podklad pro člověka, který bude muset rozhodnout, zda investici udělat, a případně obhájit její prioritu před dalšími lidmi.

Při mentoringu se proto ještě krátce vrátí k tomu, jak má první pokus uchopit.

"Když budeš chtít vysvětlit, proč do toho máme investovat čas, co bude ten člověk potřebovat vědět?" zeptá se Igor.

"Kolik nás stojí současný stav. Kolik by stála úprava a co by se nám potom ušetřilo. A samozřejmě jaká rizika tím snížíme, případně jaká nová vytvoříme."

"A co z toho už máš?"

"Zatím hlavně to, že mě ten kód štve," přizná Petr.

Igor se pousměje. "To je dobrý začátek pro tvoji motivaci. Ale jako podklad pro investiční rozhodnutí to asi stačit nebude."

"Díky, to jsem potřeboval slyšet."

"Tak zkus zjistit, co z těch nákladů dokážeš rozumně odhadnout. Nemusíš teď vyrobit univerzální metodiku na technický dluh. Potřebujeme první konkrétní pokus na tomhle případu."

Petr začne historií změn. Projde starší úkoly za posledních přibližně osm měsíců a najde patnáct významnějších zásahů, které se problematické části aplikace týkaly. S využitím dostupných údajů a vlastní znalosti práce týmu odhadne, že jedna taková změna v průměru spotřebovala asi tři vývojářské dny a další den testování nebo regresního ověřování. Není to přesné účetnictví všech minut, které tým nad kódem strávil, ale je to konkrétnější základ než opakované tvrzení, že práce na této části aplikace bývá zbytečně drahá.

Když se na čísla podívá pohromadě, zarazí ho, kolik času představují. Patnáct změn po čtyřech mandayích znamená zhruba šedesát mandayů během osmi měsíců. A to se pořád baví jen o vybraných významnějších změnách jedné části aplikace, ne o celkových nákladech na vývoj produktu.

Potom s kolegy krátce probere, jak velký zásah by dával smysl. Nechtějí přepisovat celou cenotvorbu ani z projektu udělat dlouhou architektonickou iniciativu. Pracovní představa je omezenější: dvěma vývojářům by refactoring zabral zhruba jeden dvoutýdenní sprint a k tomu by bylo potřeba počítat s testováním, review a ověřením. Celkový odhad vychází přibližně na 23 mandayů. Do této práce by ale už byla zahrnutá i změna, kterou tým potřebuje dodat právě teď.

Petr si na chvíli napíše vedle sebe čísla 23 a 5. Pokud by současnou změnu udělali bez refactoringu, stála by odhadem pět mandayů. Nemá tedy smysl tvrdit, že investice do refactoringu je celých 23 mandayů navíc. Ve srovnání s prací, kterou by tým musel udělat tak jako tak, by šlo o dodatečných osmnáct.

Zbývá odhadnout, co by změna mohla přinést. Petr s kolegy předpokládají, že po oddělení pravidel a doplnění testů by podobná budoucí úprava mohla zabrat přibližně jeden vývojářský den a půl dne testování. Pořád jde o pracovní odhad. Nikdo zatím refactoring neudělal a nemohou vědět, zda se všechny budoucí změny budou chovat stejně. Pro rozhodnutí ale dokážou postavit vedle sebe současný stav a očekávaný stav po úpravě.

V podkladu nakonec Petr uvede tyto vstupy. Pro výpočty používá zkratku MD pro manday:

A pod ně výpočet, který ho zajímá nejvíc:

textDosavadní náročnost za 8 měsíců:      15 × 4 = 60 MD

Dodatečná investice do refactoringu:  23 - 5 = 18 MD

Při stejné četnosti změn po úpravě:  15 × 1,5 = 22,5 MD
Očekávaná úspora za 8 měsíců:         60 - 22,5 = 37,5 MD
Očekávaná úspora za měsíc:            37,5 / 8 ≈ 4,7 MD

Orientační návratnost investice:      18 / 4,7 ≈ 3,8 měsíce

Petr se na výsledek dívá s docela dobrým pocitem. Přibližně čtyři měsíce do návratnosti dodatečné investice mu připadají jako silný argument, zvlášť když se část aplikace mění tak často. Současně si ale poznamená, že výpočet stojí na dvou podstatných předpokladech: budoucí změny budou přicházet přibližně stejně často jako v minulých osmi měsících a odhadovaná úspora na jedné změně se skutečně projeví. Pokud by se cenových pravidel dalšího půl roku skoro nikdo nedotkl nebo refactoring nezjednodušil práci tolik, jak tým předpokládá, návratnost by vypadala jinak.

Vedle úspory času očekávají také menší regresní riziko. Když budou mít pravidla lepší strukturu a relevantní kombinace pokryté testy, měla by být menší pravděpodobnost, že změna jednoho případu nepozorovaně poškodí jiný. Petr tenhle přínos do návratnosti nezapočítává. Nemá podklady, podle kterých by mu dokázal přiřadit rozumnou finanční hodnotu, a nechce si číslo vymyslet jen proto, aby mu argument vyšel ještě lépe.

Když pak připravuje stručné doporučení pro manažera, poprvé si uvědomí, jak velký rozdíl je mezi větou "měli bychom ten kód konečně uklidit" a vysvětlením, co by firma za investované úsilí mohla získat. Nemusí nikoho učit, jak jsou cenová pravidla implementovaná. Může ukázat, kolik kapacity současný stav podle dostupných odhadů spotřebovává, kolik by stála omezená změna a za jakých předpokladů by se její dodatečná cena mohla vrátit.

Do poslední části napíše své doporučení: když už tým musí do této části systému znovu zasahovat, dává podle něj smysl udělat omezený refactoring právě teď. Současnou změnu tím zároveň vyřeší, do budoucna si zjednoduší další úpravy a sníží část regresního rizika.

Petr ví, že jde o odhady. Tentokrát ale dokáže ukázat, z čeho vycházejí. A pokud je manažer zpochybní, bude se alespoň možné bavit o konkrétních předpokladech místo o tom, zda je technický dluh obecně dobrý, nebo špatný.

Šest týdnů do odevzdání

Před další schůzkou vedení si Petr s manažerem vyhradí domluvenou půlhodinu. Petr otevře svůj podklad a začne vysvětlovat, odkud vzal historickou četnost změn, co započítal do odhadu refactoringu a proč od současné investice odečítá pět mandayů, které by stejně spotřebovala plánovaná úprava. Připravoval se i na otázky, zda je patnáct změn dostatečně reprezentativních nebo jestli po refactoringu opravdu klesne náročnost další změny na jeden a půl mandaye.

Manažer si čísla projde. U některých se doptá na jejich původ, ale většinu argumentace nezpochybní.

"Tohle už je pro mě výrazně použitelnější," řekne. "Vidím, kolik nás současný stav přibližně stojí, jak jsi došel k investici navíc a co by se nám podle odhadu mohlo vrátit. Takhle se o tom dá bavit."

Petr má radost. Ne že by čekal pochvalu za tabulku, ale konečně má pocit, že se s manažerem nemusí přít o samotnou existenci technického problému. Podklad nabízí čísla, ze kterých lze vyjít, a jasné doporučení. Už se nadechuje, že vysvětlí ještě rozdíl v regresním riziku, když ho manažer zastaví.

"Jenže pořád mám jednu otázku. Proč bychom to měli dělat právě teď?"

Petr se zarazí. "No, protože tam stejně budeme dělat změnu. A když ten refactoring neuděláme, tak budeme za další úpravy dál platit zbytečně moc."

"Tomu rozumím. Já se neptám, jestli ta investice někdy dává smysl. Ptám se, jestli je dobré ji udělat teď, když máme za šest týdnů důležité odevzdání."

Petr se podívá na svůj odhad. Pět mandayů na současnou změnu, třiadvacet na variantu s refactoringem. Rozdíl je osmnáct. Samozřejmě to není zanedbatelná práce, ale podle plánu by tým měl obojí zvládnout. Nemá pocit, že by navrhoval něco, co automaticky ohrozí release.

"Já jsem se na to díval," odpoví. "Podle současných odhadů bychom se do toho termínu měli vejít i s refactoringem. Neříkám, že to bude úplně zadarmo, ale nejsme přece tak natěsno."

"Pokud všechno půjde podle odhadů, možná ano," připustí manažer. "Jenže já nemůžu naplánovat prakticky celou zbývající kapacitu a počítat s tím, že se šest týdnů nic dalšího nestane."

Petr podobnou větu slyšel už mnohokrát. Většinou ve chvíli, kdy někdo vysvětloval, proč se do plánu nevejde technická práce, kterou vývoj považoval za důležitou. Tentokrát ale manažer nezůstane u obecného požadavku na rezervu. Připomene, že do plánu vstupují známé absence, ale také věci, které dnes nikdo přesně neodhadne. Někdo může onemocnět, může se objevit produkční problém, jeden ze současných úkolů se může ukázat jako složitější nebo tým narazí na blocker, který několik dní nepůjde odstranit. A občas přijde další požadavek, kterému firma prostě musí dát přednost.

"Tohle všechno se může stát vždycky," namítne Petr. "Kdybychom kvůli tomu měli odkládat každou větší změnu, tak ten dluh nikdy nevyřešíme."

"Souhlasím, že takhle by to nešlo," odpoví manažer. "Ale taky to neznamená, že máme rezervu spotřebovat pokaždé, když nějaká investice vyjde ekonomicky dobře. Musím se dívat na to, co se stane, když nám potom něco nevyjde."

Petr se vrátí k plánu. Pořád mu připadá, že by se tam osmnáct mandayů navíc mohlo vejít. S podobnými termíny přece pracují běžně. Několikrát se už stalo, že odevzdání o pár dní přetáhli, a výsledek nebyl nijak dramatický. Bylo to nepříjemné, museli vysvětlovat zpoždění, ale projekt pokračoval dál.

"Takhle těsně jsme jeli už mockrát," řekne. "A někdy jsme termín i trochu přetáhli. Většinou se zase tolik nestalo."

"To je pravda," přikývne manažer. "Ale nebyly to všechny stejné termíny."

Petr zvedne oči od dokumentu.

"Tohle odevzdání je navázané na důležitý závazek vůči jednomu z našich významných klientů," pokračuje manažer. "Kdybychom se opozdili, může to pro firmu znamenat podstatně větší problém než u některých minulých releasů, se kterými to teď porovnáváš. Neříkám, že tvoje čísla jsou špatně. A neříkám ani, že refactoring nemáme udělat. Jen nechci spotřebovat skoro všechnu rezervu před termínem, u kterého může mít zpoždění mnohem větší důsledky."

Petr chvíli mlčí. Ještě před několika minutami čekal, že se budou přít o náročnost refactoringu nebo o to, kolik dalších změn skutečně přijde. Všechno podstatné měl podle svého názoru spočítané. Jenže manažer jeho výpočet nezpochybnil. Přidal k němu jiný problém, který Petr ve svém doporučení prakticky neřešil.

"Takže bys to radši odložil?" zeptá se.

"Možná. Ale nechci teď dělat závěr jen proto, že se bavíme o refactoringu. Potřebuju posoudit, kolik rezervy si před tímhle odevzdáním můžeme dovolit využít a co riskujeme, pokud ji nebudeme mít. Tvůj podklad mi pomáhá pochopit cenu té technické investice. To je důležité. Jen je to jedna část rozhodnutí."

Petr už má na jazyku další argument o budoucích úsporách. Uvědomí si však, že by manažerovi opakoval něco, co právě uznal. Nejspíš by dokázal zpřesnit odhad z 3,8 měsíce na trochu jiné číslo, ale tím by stále neodpověděl na otázku, proč je rozumné vystavit právě tento termín většímu riziku.

Až teď mu dochází, že oba dosud mluvili o trochu jiném rozhodnutí. Petr se snažil ukázat, že omezený refactoring může být ekonomicky výhodná investice. Manažer potřeboval rozhodnout, zda ji má tým provést v následujících týdnech, kdy má zároveň splnit důležitý závazek. Jsou to související otázky, ale kladná odpověď na první z nich automaticky neřeší tu druhou.

Kdybys byl na Petrově místě, nebyla by škoda jeho výpočet zahodit jen proto, že manažer nepřijal doporučení udělat refactoring okamžitě? Petr zjistil něco užitečného: dokázal přeložit dlouhodobý technický problém do přibližné spotřeby kapacity, oddělit běžnou práci od dodatečné investice a vytvořit ekonomický argument, se kterým druhá strana může pracovat. To samo o sobě má hodnotu.

Zároveň si zkus všimnout, na co jeho podklad nestačil. Návratnost investice říká něco o tom, za jakých předpokladů se může vyplatit. Neříká automaticky, kdy ji provést. Pokud se rozhoduje mezi dvěma legitimními potřebami, nestačí umět dobře popsat jednu z nich. Potřebuješ rozumět také omezením a důsledkům druhé. A právě tady může být rozdíl mezi technicky správným argumentem a podkladem, podle kterého lze udělat konkrétní rozhodnutí.

Co Petr vlastně připravil

Po schůzce se Petr ke svému podkladu vrátí. Na první pohled v něm žádnou chybu nenachází. Patnáct změn za osm měsíců odpovídá tomu, co našel ve starších úkolech. Odhady náročnosti mají svůj základ v práci týmu. Současnou změnu správně odečetl od celkové investice a u budoucích úspor nepředstíral jistotu, kterou nemá. Dokonce zvlášť uvedl regresní riziko, aniž by mu vymýšlel finanční hodnotu.

Přitom z rozhovoru neodchází s pocitem, že má hotovo. Čím déle se na dokument dívá, tím zřetelněji vidí, jak silně ho při přípravě ovlivnila vlastní zkušenost s problematickou částí kódu. Dobře věděl, proč chce refactoring udělat. Několik let sledoval, jak se jednoduché změny komplikují a kolik pozornosti vyžaduje jejich testování. Když konečně získal možnost připravit argument pro vedení, soustředil se na to, aby tuto cenu dokázal ukázat co nejpřesvědčivěji.

To se mu do určité míry podařilo. Manažer čísla nezamítl, ocenil jejich použitelnost a dokázal z nich pochopit, proč Petr investici doporučuje. Jenže Petr si k doporučení přidal ještě jeden závěr, který z těch čísel nevycházel tak přímo, jak si myslel: že když je investice rozumná a podle současných odhadů se vejde do plánu, měla by se udělat právě teď.

Otevře si místo, kde píše o návratnosti, a znovu si přečte vlastní předpoklady. Budoucí četnost změn, očekávaná náročnost po refactoringu, osmnáct mandayů dodatečné práce. Všechno jsou to informace o samotné investici. O významu nejbližšího klientského odevzdání tam ale není téměř nic. Stejně tak v podkladu neřeší, co by pro plán znamenalo, kdyby se některý odhad nepovedl, nebo jakou rezervu si tým může v této situaci dovolit spotřebovat.

Nejde přitom o to, že by měl automaticky dát manažerovi za pravdu. Možná by omezený refactoring opravdu šlo bezpečně zvládnout i před odevzdáním. Možná by dávalo větší smysl počkat. A možná existuje menší varianta, která by část problému odstranila s menším dopadem na dostupnou kapacitu. Petr zatím nemá dost informací, aby některý z těch závěrů obhájil. Při přípravě ale pracoval, jako kdyby je měl.

Na začátku chtěl proniknout k rozhodování, protože měl pocit, že lidé mimo vývoj dostatečně nerozumějí technickým problémům. Teď dostal první příležitost připravit pro takového člověka podklad a zjistil, že problém může být i na jeho straně. Ne v tom, že by nedokázal spočítat přibližnou cenu technického dluhu. Ani v tom, že by nedokázal navrhnout smysluplnou investici. Chyběla mu část kontextu, který rozhodoval o tom, zda je správné tuto investici udělat právě teď.

Petr si do poznámek zapíše, co se mu při prvním pokusu povedlo, a vedle toho otázky, na které nedokázal odpovědět. Nechává si také původní podklad. Nechce ho zpětně přepisovat tak, aby vypadal lépe, než ve skutečnosti byl. Právě rozdíl mezi jeho doporučením a manažerovou reakcí mu ukazuje něco, co by při dalším obecném studiu komunikace snadno přehlédl.

Potom se ještě jednou zastaví u poslední věty svého doporučení. Napsal, že refactoring dává smysl udělat teď. Dokáže vysvětlit, proč by mohl dávat smysl. S tím slovem teď je to ale složitější.

A pokud má příště připravit podklad, který skutečně pomůže rozhodnout, bude muset přijít na to, co všechno potřebuje vědět dřív, než ho znovu napíše.