Petr chcel byť pri rozhodovaní. Manažér mu ponúkol hodinu.

Petr Konečný je fiktívna postava. Jeho príbeh je ilustračný scenár mentoringu, nie skúsenosť skutočného klienta ani doložený výsledok mentoringu. Čísla, rozhovory a pracovné situácie sú súčasťou tohto fiktívneho príkladu.

Keď máš cieľ, ale nemáš si ho kde vyskúšať

Petr mal konečne rozvojovú roadmapu, ktorú naozaj používal. Nebol to ďalší dokument so zoznamom vecí, ktoré by sa raz mohlo hodiť naučiť. Každé ráno do nej na chvíľu nazrel, pozrel sa na svoje aktuálne zameranie a pripomenul si, čomu chce pri práci venovať pozornosť. Po nedávnom stretnutí s klientom navyše vedome zmenil poradie svojich priorít. Vysvetľovanie biznisového dopadu technických riešení bolo vtedy kvôli konkrétnemu termínu naliehavejšie, a keď sa stretnutie skončilo, naliehavosť opäť klesla. Petr sa napriek tomu rozhodol venovať tejto oblasti ďalej. Pri rovnakom pracovnom skóre 1,00 ako pri trade-offoch mu dávalo zmysel pokračovať práve tu.

Stále ho zaujímalo, či sa raz posunie zo seniorného vývojára k architektonickej zodpovednosti. Na prvých stretnutiach s Igorom však zistil, že takýto posun pravdepodobne nebude znamenať len zložitejšie technické úlohy a väčšie slovo pri výbere technológií. Bude sa musieť naučiť pripravovať rozhodnutia, do ktorých vstupujú náklady, termíny, produktové potreby a riziká. A predovšetkým bude musieť vedieť vysvetliť technické súvislosti ľuďom, ktorí za tieto veci zodpovedajú, bez toho, aby sami museli rozumieť implementácii.

Chápal, prečo je to dôležité. Mal dokonca niekoľko otázok, podľa ktorých by si mohol pripraviť vlastné vysvetlenie. Lenže keď sa pozrel na bežný pracovný týždeň, väčšina takýchto rozhovorov sa odohrávala niekde inde. Petr sa zúčastňoval technických diskusií, konzultoval riešenia s kolegami a občas dostal priestor niečo vysvetliť klientovi. Rozhodovanie o väčších investíciách alebo prioritách však spravidla riešil jeho projektový manažér spolu s ďalšími ľuďmi z vedenia.

Na ďalšom mentoringu preto Petr otvoril problém, ktorý ho na projekte trápil už dlho. Technický dlh podľa neho postupne rástol. Vývojári naň upozorňovali, ale k väčším zmenám sa dostali len zriedka. Vždy bolo niečo naliehavejšie, nejaká nová funkcionalita alebo termín, ktorý dostal prednosť. Petr mal čoraz silnejší pocit, že by sa o týchto veciach rozhodovalo inak, keby vedenie naozaj rozumelo tomu, koľko práce im súčasný stav pridáva.

"Ja si niekedy hovorím, či to náš manažér vôbec dokáže vedeniu poriadne vysvetliť," povie Igorovi. "On tam za nás rieši tie technické veci. Ale keď potom vidím, čo dostane prioritu, občas mám pocit, že im ten dopad technického dlhu jednoducho nedochádza."

"A vieš, ako im ho vysvetľuje?" spýta sa Igor.

"No, priamo na tých stretnutiach nie som."

"Takže nevieš."

Petr sa oprie v stoličke. "No, keď to povieš takto..."

"Skús mi povedať, čo skutočne vieš. Upozorňujete na technické problémy, ale niektoré investície sa opakovane odkladajú. To je výsledok, ktorý vidíš. Lenže z neho ešte nezistíš, či manažér niečo zle vysvetlil, či tomu vedenie nerozumelo, alebo či tomu rozumelo a rozhodlo sa uprednostniť niečo iné."

Petr chce namietať, ale nenachádza konkrétny príklad, ktorý by jeho pôvodný záver podporil. Pozná technickú cenu niektorých rozhodnutí. Vie, koľko zbytočnej práce podľa neho tímu pridávajú. Nevie však, aké možnosti a dôsledky sa pri rokovaniach s vedením skutočne preberajú. Doteraz mu to veľmi neprekážalo. Vlastne mu vyhovovalo predpokladať, že keby tam sedel on, dokázal by význam niektorých problémov vysvetliť lepšie.

"Ale ja sa k tomu rozhodovaniu práve chcem dostať," namietne. "Ak chcem raz robiť architekta, nechcem len čakať, kým niekto rozhodne, a potom nadávať, že to bolo zle."

"To je rozumný dôvod," odpovie Igor. "Len by som ho nestaval na predpoklade, že tvoj manažér niečo nezvláda. Čo keby si namiesto toho skúsil zistiť, či sa môžeš podieľať na príprave niektorého z tých rozhodnutí?"

Petr chvíľu premýšľa. S manažérom má pravidelné 1:1 a o svojom ďalšom rozvoji sa už niekoľkokrát rozprávali. Nemusí teda vymýšľať žiadnu zvláštnu cestu k vedeniu ani sa pokúšať získať zodpovednosť, ktorú zatiaľ nemá. Môže začať obyčajnou otázkou, či existuje priestor, kde by si potrebnú prácu dokázal vyskúšať.

Na meeting sa nedostal

Na nasledujúcom 1:1 Petr najprv vysvetlí, čomu sa chce venovať. Nezačne technickým dlhom ani kritikou rozhodovania na projekte. Opíše svoj súčasný rozvojový cieľ: vedieť pripraviť technický argument tak, aby podľa neho človek mimo vývoja dokázal posúdiť prínosy, náklady, obmedzenia a riziká určitého postupu. Zatiaľ sa najviac pohybuje v samotnej implementácii a chýba mu skúsenosť s tým, ako sa podobné podklady používajú pri skutočnom rozhodovaní.

"Ty sa s vedením o technických veciach rozprávaš pravidelne, nie?" spýta sa Petr svojho manažéra na ich 1:1.

"Hej. Približne raz za dva týždne máme stretnutie, kde toho preberáme viac. Občas tam riešime technické rozhodnutia, investície alebo riziká, ktoré potrebujeme vysvetliť aj mimo vývoja. Prečo?"

"Napadlo mi, či by som sa niekedy nemohol pripojiť. Nechcem tam hneď o niečom rozhodovať. Ale rád by som videl, ako tie diskusie prebiehajú, a časom sa do niektorej možno aj zapojil."

Manažér sa nad tým zamyslí, ale Petra nenechá dlho v neistote.

"Na tie pravidelné stretnutia by som ťa zatiaľ nebral. Riešime tam aj veci, ktoré sa tvojho projektu vôbec netýkajú, a nechcem ti pridávať ďalší meeting každé dva týždne. Už teraz máš dosť práce. Potrebujem, aby si sa stále venoval hlavne vývoju."

Petr je sklamaný. Nečakal, že sa zajtra stane súčasťou vedenia, ale predstavoval si, že by mohol aspoň počúvať. Práve tento typ diskusií predsa potrebuje spoznať. Na chvíľu mu napadne, že sa opakuje rovnaký problém ako pri technickom dlhu: aby mohol získať väčšiu zodpovednosť, potrebuje skúsenosti, ale bez väčšej zodpovednosti sa k nim nedostane.

Manažér však pokračuje skôr, než Petr začne vysvetľovať, prečo by mu ďalšie stretnutie vlastne neprekážalo.

"To ale neznamená, že na tom nemôžeš pracovať. Ak chceš skúsiť pripraviť podklad pre nejaké rozhodnutie, môžeme vybrať konkrétnu technickú tému. Koľko času by si potreboval na prvý pokus?"

Petr si skúša predstaviť, čo by mal vlastne odovzdať. Nechce pripravovať rozsiahlu analýzu každej dostupnej možnosti. Potrebuje vziať problém, ktorému technicky rozumie, a pokúsiť sa ho opísať človeku, ktorý má iné starosti než implementačné detaily.

"Na prvú verziu by som si vyhradil tak hodinu," odhadne. "A potom by som si to s tebou potreboval prejsť, či je to vôbec použiteľné. Možno pol hodiny?"

"To môžeme skúsiť. Vyberieme niečo, čo budem naozaj potrebovať vysvetliť ďalej. Ty pripravíš svoj pohľad, spolu sa naň pozrieme a ja rozhodnem, čo z toho použijem. Na stretnutie s vedením pôjdem zatiaľ sám. Dáva ti to zmysel?"

Petr prikývne. Nie je to presne to, čo chcel, ale nedostal len prísľub, že sa na jeho rozvoj niekedy pozrú. Dohodli sa na konkrétnej práci, ktorá sa má udiať počas pracovného času a ktorá môže manažérovi pomôcť s niečím, čo by aj tak musel riešiť. Zároveň je jasné, kde sa pokus končí. Petr pripraví technický vstup, dostane spätnú väzbu a manažér si ponechá zodpovednosť za výsledné posolstvo aj za rokovanie s vedením.

Keď to neskôr opisuje Igorovi, stále je na ňom trochu vidieť sklamanie.

"Chcel som sa dostať k tomu, ako sa reálne rozhoduje. Zatiaľ budem pripravovať podklady niekomu, kto tam potom pôjde namiesto mňa."

"A čo si sa vlastne chcel naučiť?" spýta sa Igor. "Sedieť na meetingu, alebo pripraviť informáciu, podľa ktorej môže niekto rozhodnúť?"

"To druhé. Ale samozrejme by som raz chcel vedieť aj viesť tú diskusiu."

"Tak by som ten prvý pokus úplne nezatracoval. Pripravíš niečo ku skutočnému rozhodnutiu a človek, ktorý za tú komunikáciu zodpovedá, ti povie, čo je na tom použiteľné a čo chýba. To už je celkom dobrá príležitosť zistiť, ako na tom si."

Petr sa nad tým zamyslí. Mohol sa ďalej snažiť presadiť svoju účasť na stretnutiach, ale zatiaľ by len vyjednával o väčšom množstve času bez toho, aby mal čo ukázať. Takto dostal príležitosť urobiť prvý konkrétny pokus. A ak pri ňom zistí, že mu niečo podstatné chýba, nebude to len všeobecný pocit, že potrebuje viac skúseností.

Keď sa chceš rozvíjať v niečom, čo dnes nepatrí do tvojej bežnej pracovnej zodpovednosti, nemusí byť najlepším prvým krokom žiadosť o novú rolu alebo prístup na všetky stretnutia, kde sa táto práca robí. Skús najprv zistiť, akú konkrétnu časť tejto zodpovednosti by si mohol prevziať v obmedzenom rozsahu. Ideálne tak, aby mal tvoj výstup zmysel aj pre človeka, ktorý ti tento priestor poskytne. Petr si nevyjednal účasť na rozhodovaní, ale získal skutočnú tému, čas na prípravu a spätnú väzbu od niekoho, kto s výsledkom pracuje.

Samozrejme, nie vždy sa podobnú príležitosť podarí nájsť. Vtedy môžeš vziať staršie rozhodnutie a spätne k nemu pripraviť podklad, prípadne si vyskúšať rozhovor so simulovaným netechnickým stakeholderom, napríklad pomocou AI. Na prvý tréning to môže byť užitočné. Len treba rozlišovať, čo tým skutočne overuješ. Simulácia ti môže pomôcť odhaliť slabé argumenty alebo otázky, na ktoré nevieš odpovedať. Nenahradí však reálny pracovný kontext, skutočné vzťahy, dôsledky rozhodnutia ani človeka, ktorý za ne zodpovedá.

Problém, ktorý dobre pozná. A preto ho chce konečne vyriešiť.

Manažér napokon vyberie tému, na ktorej Petr pracoval už mnohokrát. Ide o staršiu zdieľanú časť aplikácie, v ktorej sa vyhodnocujú cenové pravidlá, zľavy a niektoré zákaznícke výnimky. Pôvodne možno mala jej štruktúra dobrý zmysel, ale postupne do nej pribúdali nové produkty, špeciálne obchodné podmienky a ďalšie prípady, ktoré sa do pôvodného návrhu nehodili. Výsledkom nie je úplne pokazený komponent. Je to len časť systému, v ktorej je čoraz ťažšie zmeniť jednu vec a mať rozumnú istotu, že sa tým nepokazilo niečo iné.

Petr tento problém dobre pozná. Pravidlá sú navzájom previazané, niektoré zmeny ovplyvňujú zdanlivo nesúvisiace výpočty a automatické regresné testy nepokrývajú všetky dôležité kombinácie. Aj pri pomerne malej úprave musí vývojár najprv pochopiť niekoľko súvisiacich ciest a po implementácii venovať dosť času overovaniu. Keď sa to opakuje, nejde už len o nepríjemný kód. Tím kvôli nemu míňa kapacitu, ktorú by mohol využiť na inú prácu.

A práve teraz potrebuje tím túto časť aplikácie opäť meniť. Súčasnú úpravu by podľa Petrovho odhadu zvládli približne za štyri vývojárske dni a jeden ďalší deň testovania. Technicky nie je problém pokračovať tak ako doteraz. Petr si však myslí, že keď už do tejto časti systému znova zasahujú, mohol by byť vhodný čas urobiť obmedzený refaktoring: oddeliť najproblematickejšie pravidlá, znížiť ich vzájomnú previazanosť a doplniť testy, aby podobné zmeny nabudúce nestáli toľko času.

Je to presne ten typ problému, o ktorom už niekoľko rokov hovorí ako o technickom dlhu. Lenže tentoraz si nevystačí s vetou, že by sa to malo konečne opraviť. Má pripraviť podklad pre človeka, ktorý bude musieť rozhodnúť, či investíciu urobiť, a prípadne obhájiť jej prioritu pred ďalšími ľuďmi.

Na mentoringu sa preto ešte nakrátko vrátia k tomu, ako má prvý pokus uchopiť.

"Keď budeš chcieť vysvetliť, prečo do toho máme investovať čas, čo bude ten človek potrebovať vedieť?" spýta sa Igor.

"Koľko nás stojí súčasný stav. Koľko by stála úprava a čo by sme potom ušetrili. A samozrejme, aké riziká tým znížime, prípadne aké nové vytvoríme."

"A čo z toho už máš?"

"Zatiaľ hlavne to, že ma ten kód štve," prizná Petr.

Igor sa pousmeje. "To je dobrý začiatok pre tvoju motiváciu. Ale ako podklad pre investičné rozhodnutie to asi stačiť nebude."

"Vďaka, to som potreboval počuť."

"Tak skús zistiť, ktoré z tých nákladov dokážeš rozumne odhadnúť. Nemusíš teraz vyrobiť univerzálnu metodiku na technický dlh. Potrebujeme prvý konkrétny pokus na tomto prípade."

Petr začne históriou zmien. Prejde staršie úlohy za približne posledných osem mesiacov a nájde pätnásť významnejších zásahov, ktoré sa týkali problematickej časti aplikácie. Z dostupných údajov a vlastnej znalosti práce tímu odhadne, že jedna takáto zmena spotrebovala v priemere asi tri vývojárske dni a ďalší deň testovania alebo regresného overovania. Nie je to presné účtovanie každej minúty, ktorú tím nad kódom strávil, ale je to konkrétnejší základ než opakované tvrdenie, že práca na tejto časti aplikácie býva zbytočne drahá.

Keď sa na čísla pozrie v súhrne, zarazí ho, koľko času predstavujú. Pätnásť zmien po štyroch mandayoch znamená zhruba šesťdesiat mandayov za osem mesiacov. A stále ide len o vybrané významnejšie zmeny jednej časti aplikácie, nie o celkové náklady na vývoj produktu.

Potom sa s kolegami krátko porozpráva o tom, aký veľký zásah by dával zmysel. Nechcú prepisovať celú cenotvorbu ani z projektu urobiť dlhú architektonickú iniciatívu. Pracovná predstava je obmedzenejšia: dvom vývojárom by refaktoring zabral približne jeden dvojtýždňový sprint a navyše by bolo potrebné počítať s testovaním, review a overovaním. Celkový odhad vychádza približne na 23 mandayov. Do tejto práce by však už bola zahrnutá aj zmena, ktorú tím potrebuje dodať práve teraz.

Petr si na chvíľu napíše vedľa seba čísla 23 a 5. Ak by súčasnú zmenu urobili bez refaktoringu, stála by podľa odhadu päť mandayov. Nemá teda zmysel tvrdiť, že refaktoring predstavuje celých 23 mandayov navyše. V porovnaní s prácou, ktorú by tím aj tak musel urobiť, by išlo o dodatočných osemnásť.

Zostáva odhadnúť, čo by zmena mohla priniesť. Petr s kolegami predpokladajú, že po oddelení pravidiel a doplnení testov by podobná budúca úprava mohla zabrať približne jeden vývojársky deň a pol dňa testovania. Stále ide o pracovný odhad. Nikto zatiaľ refaktoring neurobil a nemôžu vedieť, či budú všetky budúce zmeny prebiehať rovnako. Pre rozhodovanie však dokážu postaviť vedľa seba súčasný stav a očakávaný stav po úprave.

Do svojho podkladu Petr nakoniec uvedie tieto vstupy. Pri výpočtoch používa skratku MD pre manday:

A pod ne výpočet, ktorý ho zaujíma najviac:

textDoterajšia náročnosť za 8 mesiacov:      15 × 4 = 60 MD

Dodatočná investícia do refaktoringu:    23 - 5 = 18 MD

Pri rovnakej frekvencii zmien po úprave: 15 × 1,5 = 22,5 MD
Očakávaná úspora za 8 mesiacov:         60 - 22,5 = 37,5 MD
Očakávaná úspora za mesiac:             37,5 / 8 ≈ 4,7 MD

Orientačná návratnosť investície:        18 / 4,7 ≈ 3,8 mesiaca

Petr sa na výsledok pozerá s celkom dobrým pocitom. Približne štyri mesiace do návratnosti dodatočnej investície mu pripadajú ako silný argument, najmä keď sa táto časť aplikácie mení tak často. Zároveň si však poznačí, že výpočet stojí na dvoch podstatných predpokladoch: budúce zmeny budú prichádzať približne rovnako často ako za predchádzajúcich osem mesiacov a odhadovaná úspora pri jednej zmene sa skutočne prejaví. Keby sa cenových pravidiel ďalšieho pol roka takmer nikto nedotkol alebo by refaktoring nezjednodušil prácu tak, ako tím predpokladá, návratnosť by vyzerala inak.

Popri úspore času očakávajú aj nižšie regresné riziko. Keď budú mať pravidlá lepšiu štruktúru a relevantné kombinácie pokryté testami, mala by byť menšia pravdepodobnosť, že zmena jedného prípadu nepozorovane pokazí iný. Petr tento prínos do návratnosti nezapočítava. Nemá podklady, podľa ktorých by mu dokázal priradiť rozumnú finančnú hodnotu, a nechce si číslo vymyslieť len preto, aby jeho argument vyzeral ešte lepšie.

Keď potom pripravuje stručné odporúčanie pre manažéra, prvýkrát si uvedomí, aký veľký rozdiel je medzi vetou "mali by sme ten kód konečne upratať" a vysvetlením, čo by firma mohla za investované úsilie získať. Nemusí nikoho učiť, ako sú cenové pravidlá implementované. Môže ukázať, koľko kapacity súčasný stav podľa dostupných odhadov spotrebúva, koľko by stála obmedzená zmena a za akých predpokladov by sa jej dodatočná cena mohla vrátiť.

Do poslednej časti napíše svoje odporúčanie: keď už tím musí do tejto časti systému znova zasiahnuť, podľa neho dáva zmysel urobiť obmedzený refaktoring práve teraz. Zároveň tým vyriešia súčasnú zmenu, do budúcna si zjednodušia ďalšie úpravy a znížia časť regresného rizika.

Petr vie, že ide o odhady. Tentoraz však dokáže ukázať, z čoho vychádzajú. A ak ich manažér spochybní, budú sa aspoň môcť rozprávať o konkrétnych predpokladoch namiesto toho, či je technický dlh vo všeobecnosti dobrý alebo zlý.

Šesť týždňov do odovzdania

Pred ďalším stretnutím vedenia si Petr s manažérom vyhradia dohodnutú polhodinu. Petr otvorí svoj podklad a začne vysvetľovať, odkiaľ vzal historickú frekvenciu zmien, čo započítal do odhadu refaktoringu a prečo od súčasnej investície odpočítava päť mandayov, ktoré by aj tak spotrebovala plánovaná úprava. Pripravil sa aj na otázky, či je pätnásť zmien dostatočne reprezentatívnych a či po refaktoringu naozaj klesne náročnosť ďalšej zmeny na jeden a pol mandaya.

Manažér si čísla prejde. Pri niektorých sa spýta na ich pôvod, ale väčšinu argumentácie nespochybní.

"Toto je už pre mňa výrazne použiteľnejšie," povie. "Vidím, koľko nás súčasný stav približne stojí, ako si dospel k investícii navyše a čo by sa nám podľa odhadu mohlo vrátiť. Takto sa o tom dá rozprávať."

Petr má radosť. Niežeby čakal pochvalu za tabuľku, ale konečne má pocit, že sa s manažérom nemusí prieť o samotnú existenciu technického problému. Podklad ponúka čísla, z ktorých môžu vychádzať, aj jasné odporúčanie. Už sa nadychuje, aby vysvetlil aj rozdiel v regresnom riziku, keď ho manažér zastaví.

"Lenže stále mám jednu otázku. Prečo by sme to mali robiť práve teraz?"

Petr sa zarazí. "No, pretože tam aj tak budeme robiť zmenu. A keď ten refaktoring neurobíme, budeme za ďalšie úpravy naďalej platiť zbytočne veľa."

"Tomu rozumiem. Nepýtam sa, či tá investícia niekedy dáva zmysel. Pýtam sa, či je dobré urobiť ju teraz, keď máme o šesť týždňov dôležité odovzdanie."

Petr sa pozrie na svoj odhad. Päť mandayov na súčasnú zmenu, dvadsaťtri na variant s refaktoringom. Rozdiel je osemnásť. Samozrejme, nie je to zanedbateľná práca, ale podľa plánu by tím mal zvládnuť obe možnosti. Nemá pocit, že navrhuje niečo, čo automaticky ohrozí release.

"Ja som sa na to pozeral," odpovie. "Podľa súčasných odhadov by sme ten termín mali stihnúť aj s refaktoringom. Nehovorím, že to bude úplne zadarmo, ale nie sme predsa až tak natlačení."

"Ak všetko pôjde podľa odhadov, možno áno," pripustí manažér. "Lenže ja nemôžem naplánovať prakticky celú zostávajúcu kapacitu a rátať s tým, že sa šesť týždňov nič ďalšie nestane."

Petr podobnú vetu počul už mnohokrát. Väčšinou vtedy, keď niekto vysvetľoval, prečo sa do plánu nezmestí technická práca, ktorú vývoj považoval za dôležitú. Tentoraz však manažér nezostane pri všeobecnej požiadavke na rezervu. Pripomenie, že do plánu vstupujú známe neprítomnosti, ale aj veci, ktoré dnes nikto nedokáže presne odhadnúť. Niekto môže ochorieť, môže sa objaviť produkčný problém, niektorá zo súčasných úloh sa môže ukázať ako zložitejšia alebo tím narazí na blocker, ktorý sa niekoľko dní nepodarí odstrániť. A občas príde ďalšia požiadavka, ktorej firma jednoducho musí dať prednosť.

"Toto všetko sa môže stať vždy," namietne Petr. "Keby sme kvôli tomu odkladali každú väčšiu zmenu, tak ten dlh nikdy nevyriešime."

"Súhlasím, že takto by to nešlo," odpovie manažér. "Ale to tiež neznamená, že máme rezervu minúť zakaždým, keď nejaká investícia vychádza ekonomicky dobre. Musím sa pozerať na to, čo sa stane, ak nám potom niečo nevyjde."

Petr sa vráti k plánu. Stále sa mu zdá, že by sa tam tých osemnásť mandayov navyše mohlo zmestiť. S podobnými termínmi predsa pracujú bežne. Už niekoľkokrát sa stalo, že odovzdanie pretiahli o pár dní, a výsledok nebol nijako dramatický. Bolo to nepríjemné, museli vysvetľovať meškanie, ale projekt pokračoval ďalej.

"Takto natesno sme už išli veľakrát," povie. "A niekedy sme termín aj trochu pretiahli. Väčšinou sa zas až tak veľa nestalo."

"To je pravda," prikývne manažér. "Ale neboli to všetko rovnaké termíny."

Petr zdvihne oči od dokumentu.

"Toto odovzdanie je naviazané na dôležitý záväzok voči jednému z našich významných klientov," pokračuje manažér. "Keby sme meškali, mohlo by to pre firmu znamenať podstatne väčší problém než pri niektorých minulých releasoch, s ktorými to teraz porovnávaš. Nehovorím, že tvoje čísla sú zlé. A nehovorím ani, že refaktoring nemáme urobiť. Len nechcem minúť skoro celú rezervu pred termínom, pri ktorom môže mať meškanie oveľa vážnejšie dôsledky."

Petr chvíľu mlčí. Ešte pred pár minútami čakal, že sa budú prieť o náročnosť refaktoringu alebo o to, koľko ďalších zmien skutočne príde. Podľa neho mal všetko podstatné spočítané. Lenže manažér jeho výpočet nespochybnil. Pridal k nemu iný problém, ktorý Petr vo svojom odporúčaní prakticky neriešil.

"Takže by si to radšej odložil?" spýta sa.

"Možno. Ale nechcem teraz dospieť k záveru len preto, že sa rozprávame o refaktoringu. Potrebujem posúdiť, koľko rezervy si pred týmto odovzdaním môžeme dovoliť využiť a čo riskujeme, ak ju nebudeme mať. Tvoj podklad mi pomáha pochopiť cenu tej technickej investície. To je dôležité. Len je to jedna časť rozhodnutia."

Petr už má na jazyku ďalší argument o budúcich úsporách. Uvedomí si však, že by manažérovi opakoval niečo, čo práve uznal. Pravdepodobne by dokázal spresniť odhad z 3,8 mesiaca na trochu iné číslo, ale stále by tým neodpovedal na otázku, prečo je rozumné vystaviť práve tento termín väčšiemu riziku.

Až teraz mu dochádza, že celý čas hovorili o trochu inom rozhodnutí. Petr sa snažil ukázať, že obmedzený refaktoring môže byť ekonomicky výhodná investícia. Manažér potreboval rozhodnúť, či ju má tím urobiť v nasledujúcich týždňoch, keď má zároveň splniť dôležitý záväzok. Sú to súvisiace otázky, ale kladná odpoveď na prvú automaticky nerieši tú druhú.

Keby si bol na Petrovom mieste, nebola by škoda zahodiť jeho výpočet len preto, že manažér neprijal odporúčanie urobiť refaktoring okamžite? Petr zistil niečo užitočné: dokázal preložiť dlhodobý technický problém do približnej spotreby kapacity, oddeliť bežnú prácu od dodatočnej investície a vytvoriť ekonomický argument, s ktorým druhá strana môže pracovať. To samo osebe má hodnotu.

Zároveň si skús všimnúť, na čo jeho podklad nestačil. Návratnosť investície hovorí niečo o tom, za akých predpokladov sa môže vyplatiť. Automaticky však nehovorí, kedy ju uskutočniť. Ak sa rozhoduje medzi dvoma legitímnymi potrebami, nestačí vedieť dobre opísať jednu z nich. Potrebuješ rozumieť aj obmedzeniam a dôsledkom tej druhej. A práve tu môže byť rozdiel medzi technicky správnym argumentom a podkladom, podľa ktorého sa dá urobiť konkrétne rozhodnutie.

Čo Petr vlastne pripravil

Po stretnutí sa Petr k svojmu podkladu vráti. Na prvý pohľad v ňom nenachádza žiadnu chybu. Pätnásť zmien za osem mesiacov zodpovedá tomu, čo našiel v starších úlohách. Odhady náročnosti vychádzajú z práce tímu. Súčasnú zmenu správne odpočítal od celkovej investície a pri budúcich úsporách nepredstieral istotu, ktorú nemá. Dokonca osobitne uviedol regresné riziko bez toho, aby mu vymýšľal finančnú hodnotu.

Napriek tomu z rozhovoru neodchádza s pocitom, že má hotovo. Čím dlhšie sa na dokument pozerá, tým jasnejšie vidí, ako veľmi ho pri príprave ovplyvnila vlastná skúsenosť s problematickou časťou kódu. Dobre vedel, prečo chce refaktoring urobiť. Niekoľko rokov sledoval, ako sa jednoduché zmeny komplikujú a koľko pozornosti si vyžaduje ich testovanie. Keď konečne dostal možnosť pripraviť argument pre vedenie, sústredil sa na to, aby túto cenu ukázal čo najpresvedčivejšie.

Do istej miery sa mu to podarilo. Manažér čísla neodmietol, ocenil ich použiteľnosť a dokázal z nich pochopiť, prečo Petr investíciu odporúča. Lenže Petr k odporúčaniu pridal ešte jeden záver, ktorý z tých čísel nevyplýval tak priamo, ako si myslel: že keď je investícia rozumná a podľa súčasných odhadov sa zmestí do plánu, mala by sa urobiť práve teraz.

Otvorí si časť, kde píše o návratnosti, a znova si prečíta vlastné predpoklady. Budúca frekvencia zmien, očakávaná náročnosť po refaktoringu, osemnásť mandayov dodatočnej práce. To všetko sú informácie o samotnej investícii. O význame najbližšieho odovzdania klientovi tam však nie je takmer nič. Rovnako v podklade nerieši, čo by pre plán znamenalo, keby niektorý odhad nevyšiel, alebo koľko rezervy si tím môže v tejto situácii dovoliť minúť.

Nejde pritom o to, že by mal automaticky dať manažérovi za pravdu. Možno by sa obmedzený refaktoring naozaj dal bezpečne zvládnuť aj pred odovzdaním. Možno by dávalo väčší zmysel počkať. A možno existuje menšia možnosť, ktorá by odstránila časť problému s menším dopadom na dostupnú kapacitu. Petr zatiaľ nemá dosť informácií, aby niektorý z týchto záverov obhájil. Pri príprave však postupoval, akoby ich mal.

Na začiatku sa chcel dostať bližšie k rozhodovaniu, pretože mal pocit, že ľudia mimo vývoja dostatočne nerozumejú technickým problémom. Teraz dostal prvú príležitosť pripraviť podklad pre takého človeka a zistil, že problém môže byť aj na jeho strane. Nie v tom, že by nedokázal vypočítať približnú cenu technického dlhu. Ani v tom, že by nedokázal navrhnúť zmysluplnú investíciu. Chýbala mu časť kontextu, ktorá rozhodovala o tom, či je správne túto investíciu urobiť práve teraz.

Petr si do poznámok zapíše, čo sa mu pri prvom pokuse podarilo, a vedľa toho otázky, na ktoré nedokázal odpovedať. Necháva si aj pôvodný podklad. Nechce ho spätne prepisovať tak, aby vyzeral lepšie, než v skutočnosti bol. Práve rozdiel medzi jeho odporúčaním a manažérovou reakciou mu ukazuje niečo, čo by pri ďalšom všeobecnom štúdiu komunikácie ľahko prehliadol.

Potom sa ešte raz zastaví pri poslednej vete svojho odporúčania. Napísal, že má zmysel urobiť refaktoring teraz. Dokáže vysvetliť, prečo by mohol dávať zmysel. S tým slovom teraz je to však zložitejšie.

A ak má nabudúce pripraviť podklad, ktorý skutočne pomôže rozhodnúť, bude musieť prísť na to, čo všetko potrebuje vedieť skôr, než ho znova napíše.