Petr si myslel, že nemá prístup k informáciám. Potom zistil, že sa na ne nespýtal.

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. Opísané pracovné situácie, rozhovory a odporúčania sú súčasťou tohto fiktívneho príkladu.

Informácia, ktorú nemal

Petr nechal po rozhovore s manažérom svoj pôvodný podklad ešte dlho otvorený. Prvýkrát dostal príležitosť pripraviť technické odporúčanie pre skutočné rozhodnutie, hoci zatiaľ neniesol zodpovednosť za jeho finálnu podobu. Išlo o obmedzený refaktoring previazaných cenových, zľavových a zákazníckych pravidiel. Prešiel históriu zmien, s kolegami odhadol náročnosť úpravy a vypočítal, že v porovnaní s bežným dokončením aktuálnej úlohy by refaktoring znamenal približne osemnásť mandayov práce navyše. Pri zachovaní doterajšej frekvencie zmien a splnení ďalších predpokladov mu vychádzala orientačná návratnosť za necelé štyri mesiace.

Manažér jeho čísla neodmietol. Naopak, povedal, že s takým podkladom sa už dá pracovať. Lenže potom sa spýtal, prečo by firma mala túto investíciu urobiť práve teraz, keď má tím o šesť týždňov dôležité odovzdanie. Petr odpovedal, že podľa odhadov by sa malo stihnúť oboje. Manažér mu pripomenul, že plán nemôže spotrebovať takmer všetku dostupnú kapacitu a spoliehať sa na to, že do odovzdania nevznikne žiadna komplikácia. Navyše išlo o termín spojený s podstatným záväzkom voči významnému klientovi, nielen o ďalší dátum v projektovom pláne.

Petr odchádzal s nepríjemným zistením. Predložil argument, prečo sa refaktoring môže z dlhodobého hľadiska vyplatiť, ale pripravil ho ako odpoveď na otázku, či sa technická investícia vôbec oplatí. Manažér pritom potreboval rozhodnúť, či ju má tím urobiť v najbližších týždňoch a aké riziko tým prijme. To nebola tá istá otázka. O konečnom rozhodnutí o refaktoringu navyše zatiaľ nič definitívne nepadlo.

Na ďalšom mentoringu Petr Igorovi opíše, čo z rozhovoru pochopil. Tentoraz sa nepokúša znovu obhajovať svoj výpočet. Vie, že spočítal naplánovanú prácu, ale dostatočne nezohľadnil neistotu odhadov, možné produkčné problémy, neprítomnosť ľudí alebo iné nečakané požiadavky. Uvedomil si tiež, že rôzne deadliny nemusia mať rovnaké dôsledky len preto, že v minulosti firma niektoré termíny prekročila a projekt pokračoval ďalej.

"Toto som si spätne dokázal rozobrať," povie. "Môj odhad kapacity nebol úplný nezmysel, len som z toho, že sa práca na papieri zmestí do plánu, urobil takmer istotu. A ten termín som bral ako ostatné."

"A čo ti na tom stále nesedí?" spýta sa Igor.

"Ten záväzok voči klientovi. To bola asi najdôležitejšia informácia z celého rozhovoru, ale ja som ju vopred nemal. Nebol som na tých stretnutiach s vedením a z histórie commitov ani z taskov nič také nezistím. Ako mám pripraviť dobré odporúčanie, keď nemám prístup ku kontextu, podľa ktorého sa potom rozhoduje?"

Igor nechá otázku chvíľu visieť vo vzduchu. Petr čaká radu, ako by sa mohol dostať na viac manažérskych meetingov, prípadne ako má s podobnými obmedzeniami ako vývojár pracovať. Namiesto toho dostane inú otázku.

"Ako vieš, že si sa k tej informácii nemohol dostať?"

"Pretože na tie stretnutia nechodím," odpovie Petr, tentoraz už trochu podráždene.

"To vysvetľuje, prečo si ju nepočul priamo tam. Ale skúšal si sa pred prípravou spýtať, aký dôležitý ten termín je? Alebo čo sa stane, ak ho nestihnete?"

Petr sa nadýchne, ale odpoveď nemá. Prešiel čísla, históriu zmien aj technické riziká. Pripravil sa na to, že mu niekto bude spochybňovať odhad pracnosti alebo frekvenciu budúcich úprav. Nenapadlo mu však overiť, či okolnosti, ktoré nevidí v technickom zadaní, nemôžu zmeniť celé odporúčanie.

"Nie," napokon prizná. "Na to som sa nespýtal. Myslel som si, že keby bolo niečo také zásadné, manažér by mi to povedal sám."

"Možno by ti to povedal, keby si mu vysvetlil, na čo tú informáciu potrebuješ," odpovie Igor. "A možno by ti nemohol povedať všetko. Lenže to sú dve rozdielne situácie. Jedna je, že nejakú informáciu nemáš. Druhá, že ju nemôžeš získať. Ty si si zatiaľ neoveril ani tú prvú možnosť."

Petr sa zamyslí nad tým, ako zvyčajne pracuje. Keď sa preberá nová funkcionalita, zákazník alebo širší plán produktu, sústredí sa najmä na to, čo bude musieť tím implementovať. Obchodný dôvod, očakávania zákazníka alebo súvislosť s inými záväzkami vníma skôr ako úvod, z ktorého si vezme len to, čo potrebuje pre technický návrh. Niekedy to stačí. Ale ak chce pripravovať odporúčania pre ľudí, ktorí rozhodujú aj o prioritách, rozpočte alebo riziku, nemôže si vopred určiť, že sú tieto informácie len nepodstatným kontextom okolo skutočnej práce.

"Takže mám začať chodiť na produktové meetingy a čítať všetko, čo firma pošle?" spýta sa.

"To by bola pekná cesta, ako si zaplniť kalendár a pritom stále nevedieť, čo potrebuješ," odpovie Igor. "Nejde o to poznať každú vec, ktorú rieši vedenie. Ide o to vedieť, pre aké rozhodnutie podklad pripravuješ a čo môže zmeniť váhu tvojich argumentov. Niekedy ten kontext počuješ pri predstavovaní roadmapy, inokedy v bežnej komunikácii. A niekedy sa jednoducho spýtaš manažéra. Napríklad čo ten termín pre firmu znamená a aký záväzok za ním stojí."

"A keď mi to nepovie?"

"Potom aspoň vieš, že tú informáciu nemáš, a môžeš to v odporúčaní uviesť. To je stále lepšie, ako sa rozhodovať podľa predpokladu, o ktorom ani nevieš, že si si ho vytvoril."

Petr si znovu vybaví pôvodný podklad. Nikde v ňom výslovne netvrdil, že dôležitý záväzok voči klientovi neexistuje. Len ho pri výpočte a formulovaní záveru úplne vynechal. V podstate teda počítal s jeho neprítomnosťou bez toho, aby to tak pomenoval. Teraz už vidí, že jeho problém nie je len v tom, ako presne preložiť technickú náročnosť do mandayov a rizík. Potrebuje tiež zistiť, ktoré informácie sú pre práve prebiehajúce rozhodnutie dôležité a ktoré z nich mu chýbajú.

Keď pripravuješ technické odporúčanie a nemáš celý biznisový alebo produktový kontext, neznamená to automaticky, že musíš získať prístup ku všetkým poradám vedenia. Skús začať pri samotnom rozhodnutí. O čom sa má rozhodnúť, prečo práve teraz, aký termín alebo záväzok do toho vstupuje a čo sa stane, ak sa niektorý predpoklad nesplní? Časť odpovedí už možno máš, o niektoré môžeš požiadať a iné naozaj nebudú dostupné. Práve tie posledné však môžeš v podklade označiť ako neistotu. Je rozdiel medzi "toto neviem" a "vôbec som si neuvedomil, že toto potrebujem vedieť".

Nie nový cieľ. Iný ďalší krok.

Petr má chuť otvoriť celú rozvojovú roadmapu a prepísať ju. Veď práve zistil, že sa na technické rozhodnutie pozeral z neúplného uhla. Potom sa však vráti k svojmu súčasnému fokusu. Stále pracuje na vysvetľovaní biznisového prínosu a dopadu technických riešení. Tento rozvojový cieľ si pred časom vybral vedome a po skončení jedného naliehavého stretnutia s klientom sa rozhodol pri ňom zostať, aj keď jeho pracovná Priorita klesla späť na 1,00 a znovu sa vyrovnala trade-offom.

"Takže mám prehodnotiť priority?" spýta sa.

"Zmenilo sa niečo na tom, ktorú schopnosť chceš teraz rozvíjať?" vráti mu Igor otázku.

"Nie. Skôr som zistil, čo v nej zatiaľ robím zle."

"Tak prečo meniť cieľ? Skús povedať, čo konkrétne nabudúce urobíš inak."

Petr chvíľu hľadá formuláciu. Napísať si "lepšie chápať biznis" by bolo jednoduché, ale pri príprave ďalšieho odporúčania by mu to nepomohlo. Potrebuje krok, ktorý v reálnej práci dokáže urobiť alebo neurobiť, nie ďalšie všeobecné želanie. Napokon sa vráti k presnej situácii z prvého pokusu: mal technické fakty, ale ešte pred dokončením argumentácie nezistil, pre aké rozhodnutie ich vlastne používa a aký kontext mu chýba.

Do roadmapy si pod doterajší fokus pridá:

textTERAZ
Vysvetľovanie biznisového prínosu
a dopadu technického riešenia
Priorita: 1,00

ĎALŠÍ KROK
[ ] Pred ďalším odporúčaním si aktívne zistiť kontext rozhodnutia
    a označiť dôležité informácie, ktoré mi chýbajú.

Neznamená to, že má pri každej úlohe rozoslať všetkým stakeholderom dotazník. Pred ďalším odporúčaním si má ujasniť, kto a o čom rozhoduje, čo má byť výsledkom, aké obmedzenia a dôsledky môžu rozhodnutie zmeniť a či niektoré z týchto informácií nie sú len jeho neoverenými predpokladmi. Technické porovnanie variantov, nákladov a rizík tým nestráca význam. Len už nemá byť prvým ani jediným zdrojom odpovede.

Petr si nový riadok prečíta ešte raz. Tentoraz nepotreboval nový vzorec, novú tabuľku priorít ani ďalšiu širokú kompetenciu, ktorú by si mal naštudovať. Z prvého pokusu si odniesol konkrétnejšiu otázku a s Igorovou pomocou ju preniesol do jednej úlohy, ktorú môže pri ďalšej vhodnej príležitosti vyskúšať. Či tým skutočne zmení svoj spôsob práce, zatiaľ nevie. To sa nedá zistiť pri mentoringu nad dobre napísanou poznámkou.

Šesť týždňov a ďalšie technické rozhodnutie

Približne o šesť týždňov neskôr sa tím dostane k ďalšej časti produktovej roadmapy. Skorší termín už majú za sebou, ale z toho netreba vyvodzovať, ako dopadlo rozhodnutie o refaktoringu alebo ako prebehlo odovzdanie. Petr má pred sebou iný pracovný problém. Ráno pred meetingom, na ktorom sa má predstaviť ďalšia plánovaná funkcionalita, si ako zvyčajne na chvíľu otvorí roadmapu. Pri svojom aktuálnom fokuse uvidí aj novú úlohu: pred odporúčaním zistiť kontext rozhodnutia a priznať si dôležité neznáme.

Ešte nevie, či z meetingu vznikne niečo, k čomu bude pripravovať technický podklad. Rozhodne sa však skúsiť jednu vec inak než predtým. Keď sa bude hovoriť o zákazníkoch a produkte, nebude čakať len na časť, v ktorej niekto začne opisovať implementáciu. Bude počúvať aj dôvod, prečo sa daná vec vlastne robí.

Tímu predstavia funkciu na hromadný import cenových a zľavových pravidiel. Jeden významný zákazník potrebuje nahrať väčšie množstvo vlastných pravidiel naraz namiesto toho, aby ich zadával ručne. V prvej verzii sa očakáva len niekoľko väčších importov denne. Zákazník nepotrebuje okamžité spracovanie, ale potrebuje vedieť, či import prebehol správne, vedieť si dohľadať jeho stav a rozumne sa zotaviť z chyby. V budúcnosti by podobnú možnosť mohli využívať aj ďalší zákazníci, len zatiaľ nie je jasné, v akom rozsahu a kedy.

Petr si tentoraz nezapíše iba to, že sa má implementovať import. Poznačí si tiež, pre koho je prvá verzia určená, aký objem sa teraz očakáva a čo pre zákazníka znamená dobrý výsledok. Keď sa neskôr začnú preberať technické varianty, má sa k čomu vrátiť.

Samotný import bude vhodné spracovávať asynchrónne. Tím má dve rozumné možnosti. Môže použiť mechanizmus úloh na pozadí, ktorý už aplikácia využíva inde. Je známy, tím ho vie prevádzkovať, dokáže evidovať stav spracovania a riešiť opakovanie aj zotavenie po chybe. Podľa doterajších predpokladov by mal očakávaný objem zvládnuť bez väčších nových nárokov na infraštruktúru. Druhou možnosťou je všeobecnejšie event-driven riešenie. To by poskytlo lepší základ, ak by sa z importu časom stal výrazne väčší integračný mechanizmus. Lenže už teraz by prinieslo novú infraštruktúru, ďalšiu implementačnú prácu a prevádzkovú zložitosť, hoci taký objem zatiaľ nie je potvrdený.

Petr má podobne ako minule pripraviť odporúčanie pre manažéra. Jeho prvým inštinktom je pustiť sa do porovnávania technických vlastností oboch variantov. To, samozrejme, potrebuje urobiť. Tentoraz si však všimne, že v zadaní zostala jedna informácia, bez ktorej môže aj správne porovnanie viesť k nesprávnemu záveru: Je rozšírenie na ďalších zákazníkov reálnym záväzkom v dohľadnom čase alebo zatiaľ len možnosťou?

Vedľa seba si pripraví hlavné rozdiely, ktoré zatiaľ dokáže obhájiť:

Samotná tabuľka nestačí. Ak má firma konkrétny plán širšieho rolloutu, vyššie počiatočné náklady môžu byť dobre odôvodnené. Ak ide len o hypotetickú budúcnosť, tím by mohol platiť za zložitosť, ktorú teraz nepotrebuje. Petr nechce znova pripraviť odporúčanie založené na tom, že chýbajúce informácie potichu nahradí vlastnou predstavou.

Preto sa manažéra spýta, či sa s ďalšími zákazníkmi a výrazne vyšším objemom už naozaj počíta, alebo či ide zatiaľ len o jednu z možných ciest. Tentoraz dostane odpoveď ešte pred dokončením podkladu. Širšie využitie je reálna možnosť, ale firma teraz nemá potvrdený konkrétny rollout ani objem, pre ktorý by musela prvú verziu budovať ako vysokokapacitnú integračnú platformu.

Petr tým nedostal hotové technické riešenie. Nezistil ani presný objem budúcich importov. Získal však dôležité rozlíšenie medzi súčasným záväzkom a možnou budúcnosťou. Teraz dokáže vysvetliť, prečo majú mať pri aktuálnom rozhodnutí určité technické vlastnosti a náklady inú váhu, než keby už bol väčší rollout potvrdený.

Odporúčanie, ktoré počíta aj s možnosťou zmeny

Petr sa vráti k podkladu a doplní svoje porovnanie o kontext prvej verzie. Technické argumenty nevynechá. Stále potrebuje riešiť prevádzkovú spoľahlivosť, zotavenie po chybe, náročnosť implementácie, budúce škálovanie a cenu prípadnej zmeny. Už však nehodnotí všetky tieto vlastnosti, akoby mali v každej firme a v každom okamihu rovnakú váhu.

V odporúčaní manažérovi napíše, že pre prvú verziu dáva zmysel použiť existujúci mechanizmus úloh na pozadí. Pri niekoľkých očakávaných importoch denne by mal stačiť, tím s ním má skúsenosti a kvôli tejto funkcii nemusí pridávať novú infraštruktúru. Pre aktuálneho zákazníka je dôležitejšia dohľadateľnosť importov, bezpečné opakovanie a zotavenie po chybe než príprava na vysoké objemy, ktoré ešte nie sú potvrdené.

Event-driven variant neodmieta ako technicky nesprávny. Vidí jeho výhody pre väčší počet integrácií a výrazne vyššiu prevádzkovú záťaž. Len pre dnešné zadanie by znamenal viac práce a zložitosti kvôli možnosti, ktorá zatiaľ nie je konkrétnym plánom. Petr zároveň pomenuje cenu svojho odporúčania: ak objem alebo šírka využitia zásadne porastie, časť spracovania bude možno potrebné zmeniť a firma za časť práce zaplatí znova. Preto navrhuje oddeliť samotné spracovanie od zvyšku funkcie, aby prípadná budúca zmena nebola zbytočne previazaná s celým importom.

Keď podklad odovzdáva manažérovi, nevysvetľuje mu len to, ktorá technológia mu vyšla lepšie. Vysvetľuje, za akých súčasných predpokladov odporúčanie platí a čo by sa muselo začať vyvíjať inak, aby stálo za opätovné posúdenie. Nemá v rukách žiadnu univerzálne najlepšiu architektúru. Má odporúčanie pre konkrétnu situáciu vrátane rizika, ktoré je pri jednoduchšom riešení ochotný navrhnúť prijať.

Manažér si podklad prejde a tentoraz zareaguje inak než pri debate o refaktoringu.

"Tento podklad je pre mňa použiteľný," povie. "Je jasné, prečo pre prvú verziu odporúčaš jednoduchší variant, čo by sme získali tým zložitejším a aké riziko si nechávame do budúcna. A neargumentuješ len tým, že event-driven by bol technicky zaujímavejší."

Petr si uvedomí, že tentoraz sa manažér nemusí najprv pýtať, aké rozhodnutie vlastne rieši. Podklad vychádza z potreby prvého zákazníka a z toho, čo je o možnom rozšírení zatiaľ potvrdené. To, samozrejme, neznamená, že jeho odporúčanie musí byť bez výhrad prijaté.

"Jednu vec by som však ešte doplnil," pokračuje manažér. "Dokážeme konkrétnejšie povedať, kedy by sme toto rozhodnutie mali znovu otvoriť? Či pri určitom počte zákazníkov, objeme importov alebo napríklad vo chvíli, keď pribudne ďalší typ integrácie?"

Petr sa pozrie na posledný odsek. Napísal, že by sa k voľbe vrátil pri výrazne vyššom objeme alebo širšom použití. Lenže slovo "výrazne" zatiaľ ničím konkrétnym nepodložil. Nechce preto z hlavy vymyslieť hranicu, ktorá by pôsobila presne, ale nezodpovedala by žiadnym overeným požiadavkám ani prevádzkovým dátam.

"To zatiaľ presne neviem," prizná. "Viem, ktoré zmeny by boli relevantné. Ale ešte nemám podklad na konkrétny trigger."

Manažér prikývne. Otázka zostáva otvorená. Z jeho reakcie nemožno vyvodzovať, ktorý variant firma nakoniec implementuje, ako bude fungovať ani či sa niekedy naozaj rozšíri na ďalších zákazníkov. Petr však dostal spätnú väzbu k niečomu, čo skutočne pripravil, a ďalšiu otázku, ktorú jeho súčasný podklad ešte nerieši.

Keď pri technickom rozhodnutí vyberieš variant, ktorý dáva zmysel v dnešnej situácii, neznamená to, že musí zostať správny za každých okolností. Niekedy je rozumné prijať riziko budúcej úpravy namiesto toho, aby si dnes platil za zložitosť, ktorú zatiaľ nepotrebuješ. Dôležité je tento trade-off pomenovať a nepredstierať, že budúcnosť poznáš presne. A ak hovoríš "vrátime sa k tomu, keď sa podmienky zmenia", stojí za to sa spýtať, akú zmenu budeš v skutočnosti sledovať. Petr túto hranicu zatiaľ nemá. Práve tým však vzniká použiteľná ďalšia otázka, nie dôvod tváriť sa, že druhý pokus bol nanič.

Čo sa pri druhom pokuse skutočne zmenilo

Keď si Petr porovná oba podklady, rozdiel už nie je len v tom, že riešil dva odlišné technické problémy. Pri refaktoringu vychádzal z histórie zmien, zostavil ekonomický argument a až v rozhovore s manažérom zistil, že pre rozhodnutie chýba dôležitý časový a klientsky kontext. O šesť týždňov neskôr si naopak pripomenul nový krok v roadmape ešte pred meetingom o produkte, zachytil, čo je dôležité pre prvú verziu, a pri pripravovanom odporúčaní spoznal ďalšiu medzeru. Na možný rollout sa tentoraz aktívne spýtal skôr, než dospel k záveru.

V oboch prípadoch sa pritom opieral o technické uvažovanie. Prvýkrát vedel približne vypočítať investíciu a jej možnú návratnosť, ale dostatočne neriešil okolnosti rozhodnutia. Druhýkrát porovnal dva reálne technické varianty, ich náklady, prevádzkové dôsledky a prijaté riziká, a pridal k tomu overený súčasný kontext. Technickú prácu nevynechal. Zmenil poradie otázok, ktoré si kládol, aj to, ako zaobchádzal s informáciami, ktoré ešte nemal.

Z druhého pokusu je zatiaľ viditeľná konkrétna zmena Petrovho správania, nie preukázaná nová úroveň jeho schopností. Manažér označil jeden podklad za použiteľný, ale tým nepovedal, že z Petra je hotový architekt, ani nepotvrdil správnosť zvolenej technológie alebo jej budúci výsledok. Položil ďalšiu otázku, na ktorú Petr ešte nepozná odpoveď. To, čo sa zmenilo v jeho prístupe, sa dá porovnať. Či mu tento prístup pomôže dlhodobo a čo firma skutočne urobí, zatiaľ nevie.

Petr na začiatku tejto časti svojej cesty očakával, že potrebuje získať lepší prístup k rozhodovaniu. Po prvom pokuse zistil, že niekedy potrebuje urobiť niečo omnoho jednoduchšie: rozpoznať, na čo sa má spýtať, a nebáť sa v podklade označiť dôležitú neistotu. Z mentoringu sa tento poznatok dostal do jeho roadmapy a z roadmapy do ďalšej skutočnej pracovnej situácie. Nová reakcia manažéra zároveň ukázala, že tým sa učenie nemusí skončiť. K jednej presnejšej otázke sa môže pridať ďalšia.

Doteraz sa Petr vracal najmä k tomu, ako urobiť inak svoj ďalší krok. Stále pritom vychádzal z pracovnej predstavy architektonickej zodpovednosti, ktorú si s Igorom zostavil na začiatku. Tá zatiaľ zostávala rovnaká. Lenže čo ak nové informácie z prostredia, v ktorom chce raz takú zodpovednosť prevziať, zmenia aj jeho pôvodnú predstavu o cieli? Potom už nebude stačiť upraviť jednu úlohu v roadmape.