Petr si myslel, že mu chybí přístup k informacím. Pak zjistil, že se na ně nezeptal.

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. Popsané pracovní situace, rozhovory a doporučení jsou součástí tohoto fiktivního příkladu.

Informace, kterou neměl

Petr si po rozhovoru s manažerem nechal svůj původní podklad otevřený ještě dlouho. Poprvé dostal příležitost připravit technické doporučení pro skutečné rozhodnutí, i když zatím neměl odpovědnost za jeho finální podobu. Šlo o omezený refactoring provázaných cenových, slevových a zákaznických pravidel. Prošel historii změn, s kolegy odhadl náročnost úpravy a spočítal, že ve srovnání s běžným dokončením aktuálního úkolu by refactoring znamenal asi osmnáct mandayů práce navíc. Při zachování dosavadní četnosti změn a při splnění dalších předpokladů mu vycházela orientační návratnost za necelé čtyři měsíce.

Manažer jeho čísla neodmítl. Naopak řekl, že s takovým podkladem už se dá pracovat. Jenže pak se zeptal, proč by firma měla investici udělat právě teď, když má tým za šest týdnů důležité odevzdání. Petr odpověděl, že podle odhadů by se obojí mělo stihnout. Manažer mu připomněl, že plán nemůže spotřebovat téměř všechnu dostupnou kapacitu a spoléhat na to, že do odevzdání nevznikne žádná komplikace. Navíc šlo o termín spojený s podstatným závazkem vůči významnému klientovi, ne jen o další datum v projektovém plánu.

Petr odcházel s nepříjemným zjištěním. Předložil argument, proč se refactoring může dlouhodobě vyplatit, ale připravil ho jako odpověď na otázku, zda se technická investice vyplatí vůbec. Manažer přitom potřeboval rozhodnout, jestli ji tým má udělat v nejbližších týdnech a jaké riziko tím přijme. To nebyla stejná otázka. O finálním rozhodnutí o refactoringu navíc zatím nic uzavřeného nepadlo.

Při dalším mentoringu Petr Igorovi popíše, co z rozhovoru pochopil. Tentokrát se nepokouší svůj výpočet obhajovat znovu. Ví, že sečetl naplánovanou práci, ale nedíval se dostatečně na nejistotu odhadů, možné produkční problémy, absence nebo jiné nečekané požadavky. Také si uvědomil, že různé deadliny nemusí mít stejné důsledky jen proto, že v minulosti firma některé termíny překročila a projekt pokračoval dál.

"Tohle jsem si zpětně dokázal přebrat," řekne. "Můj odhad kapacity nebyl vyloženě nesmysl, jen jsem z toho, že se práce na papíře vejde do plánu, udělal skoro jistotu. A ten termín jsem bral jako ostatní."

"A co ti na tom pořád nesedí?" zeptá se Igor.

"Ten závazek vůči klientovi. To byla asi nejdůležitější informace z celého rozhovoru, ale já ji předem neměl. Nebyl jsem na těch schůzkách s vedením a z historie commitů ani z tasků nic takového nezjistím. Jak mám připravit dobré doporučení, když nemám přístup ke kontextu, podle kterého se pak rozhoduje?"

Igor chvíli nechá otázku viset. Petr čeká radu, jak by se mohl dostat na více management meetingů, případně jak má s podobnými omezeními jako vývojář pracovat. Místo toho dostane jinou otázku.

"Jak víš, že ses k té informaci nemohl dostat?"

"Protože na ty schůzky nechodím," odpoví Petr, tentokrát už trochu podrážděně.

"To vysvětluje, proč jsi ji neslyšel přímo tam. Ale zkoušel ses před přípravou zeptat, jak důležitý ten termín je? Nebo co se stane, když ho nestihnete?"

Petr se nadechne, ale odpověď nemá. Prošel čísla, historii změn i technická rizika. Připravil se na to, že mu někdo bude rozporovat odhad pracnosti nebo četnost budoucích úprav. Nenapadlo ho ale ověřit, jestli okolnosti, které nevidí v technickém zadání, nemohou změnit celé doporučení.

"Ne," přizná nakonec. "To jsem se nezeptal. Myslel jsem, že kdyby bylo něco tak zásadního, manažer mi to řekne sám."

"Možná by ti to řekl, kdybys mu vysvětlil, k čemu tu informaci potřebuješ," odpoví Igor. "A možná by ti nemohl říct všechno. Jenže to jsou dvě různé situace. Jedna je, že nějakou informaci nemáš. Druhá, že ji nemůžeš získat. Ty jsi zatím neověřil ani tu první možnost."

Petr se zamyslí nad tím, jak obvykle pracuje. Když se probírá nová funkcionalita, zákazník nebo širší plán produktu, soustředí se hlavně na to, co bude muset tým implementovat. Obchodní důvod, očekávání zákazníka nebo souvislost s jinými závazky vnímá spíš jako úvod, ze kterého si vezme jen to, co potřebuje pro technický návrh. Někdy je to dost. Ale jestli chce připravovat doporučení pro lidi, kteří rozhodují také o prioritách, rozpočtu nebo riziku, nemůže si předem určit, že tyhle informace jsou jen nepodstatný kontext kolem skutečné práce.

"Takže mám začít chodit na produktové meetingy a číst všechno, co firma pošle?" zeptá se.

"To by byla pěkná cesta, jak si naplnit kalendář a přitom pořád nevědět, co potřebuješ," odpoví Igor. "Nejde o to znát každou věc, kterou řeší vedení. Jde o to vědět, pro jaké rozhodnutí podklad připravuješ a co může změnit váhu tvých argumentů. Někdy ten kontext uslyšíš při představování roadmapy, někdy v běžné komunikaci. A někdy se prostě zeptáš manažera. Třeba co ten termín pro firmu znamená a jaký závazek za ním stojí."

"A když mi to neřekne?"

"Pak alespoň víš, že tu informaci nemáš, a můžeš to v doporučení říct. To je pořád lepší než se rozhodovat podle předpokladu, o kterém ani nevíš, že sis ho udělal."

Petr si znovu vybaví původní podklad. Nikde v něm výslovně netvrdil, že důležitý klientský závazek neexistuje. Jen ho při výpočtu a formulování závěru úplně vynechal. V podstatě tedy s jeho nepřítomností počítal, aniž by to tak pojmenoval. Teď už vidí, že jeho problém není jen v tom, jak přesně přeložit technickou náročnost do mandayů a rizik. Potřebuje také zjistit, které informace jsou pro právě probíhající rozhodnutí důležité a které z nich mu chybí.

Když připravuješ technické doporučení a nemáš celý byznysový nebo produktový kontext, neznamená to automaticky, že musíš získat přístup ke všem poradám vedení. Zkus začít u samotného rozhodnutí. Co se má rozhodnout, proč teď, jaký termín nebo závazek do toho vstupuje a co se stane, když se některý předpoklad nesplní? Část odpovědí už možná máš, některé si můžeš vyžádat a jiné opravdu dostupné nebudou. Právě ty poslední ale můžeš v podkladu označit jako nejistotu. Je rozdíl mezi "tohle nevím" a "tohle jsem si vůbec neuvědomil, že potřebuju vědět".

Ne nový cíl. Jiný další krok.

Petr má chuť otevřít celou rozvojovou roadmapu a přepsat ji. Vždyť právě zjistil, že se díval na technické rozhodnutí z neúplného úhlu. Pak se ale vrátí ke svému současnému fokusu. Pořád pracuje na vysvětlování byznysového přínosu a dopadu technických řešení. Tenhle rozvojový cíl si před časem vybral vědomě a po skončení jedné naléhavé klientské schůzky se u něj rozhodl zůstat, i když jeho pracovní Priorita klesla zpátky na 1,00 a znovu se srovnala s trade-offy.

"Takže mám přehodnotit priority?" zeptá se.

"Změnilo se něco na tom, kterou schopnost teď chceš rozvíjet?" vrátí mu Igor otázku.

"Ne. Spíš jsem zjistil, co v ní zatím dělám špatně."

"Tak proč měnit cíl? Zkus říct, co konkrétně uděláš příště jinak."

Petr chvíli hledá formulaci. Napsat si "víc chápat byznys" by bylo snadné, ale nepomohlo by mu to při přípravě příštího doporučení. Potřebuje krok, který dokáže v reálné práci udělat nebo neudělat, ne další obecné přání. Nakonec se vrátí k přesné situaci z prvního pokusu: měl technická fakta, ale ještě před dokončením argumentace nezjistil, pro jaké rozhodnutí je vlastně používá a jaký kontext mu chybí.

Do roadmapy si pod dosavadní fokus přidá:

textTEĎ
Vysvětlování byznysového přínosu
a dopadu technického řešení
Priorita: 1,00

DALŠÍ KROK
[ ] Před dalším doporučením si aktivně zjistit kontext rozhodnutí
    a označit důležité informace, které mi chybí.

Neznamená to, že má při každém úkolu rozeslat všem stakeholderům dotazník. Před dalším doporučením si má ujasnit, kdo a o čem rozhoduje, co má být výsledkem, jaká omezení a důsledky mohou rozhodnutí změnit a zda některá z těchto informací nejsou jen jeho neověřeným předpokladem. Technické porovnání variant, nákladů a rizik tím neztrácí význam. Jen už nemá být prvním ani jediným zdrojem odpovědi.

Petr si nový řádek přečte ještě jednou. Tentokrát nepotřeboval nový vzorec, novou tabulku priorit ani další širokou kompetenci k nastudování. Z prvního pokusu si odnesl konkrétnější otázku a s Igorovou pomocí ji přenesl do jednoho úkolu, který může při další vhodné příležitosti vyzkoušet. Jestli tím skutečně změní svůj způsob práce, zatím neví. To se nepozná při mentoringu nad dobře napsanou poznámkou.

Šest týdnů a další technické rozhodnutí

Přibližně o šest týdnů později se tým dostane k další části produktové roadmapy. Dřívější termín už je za nimi, ale z toho není potřeba vyvozovat, jak dopadlo rozhodnutí o refactoringu nebo jak proběhlo odevzdání. Petr má před sebou jiný pracovní problém. Ráno před meetingem, kde se má představovat další plánovaná funkcionalita, si jako obvykle krátce otevře roadmapu. U svého současného fokusu uvidí i nový úkol: před doporučením zjistit kontext rozhodnutí a přiznat si materiální neznámé.

Ještě neví, jestli z meetingu vznikne něco, k čemu bude připravovat technický podklad. Rozhodne se ale zkusit jednu věc jinak než dřív. Až se bude mluvit o zákaznících a produktu, nebude čekat jen na část, ve které někdo začne popisovat implementaci. Bude poslouchat i důvod, proč se daná věc vlastně dělá.

Tým dostane představenou funkci pro hromadný import cenových a slevových pravidel. Jeden významný zákazník potřebuje nahrát větší množství vlastních pravidel najednou, místo aby je zadával ručně. Pro první verzi se čeká jen několik větších importů denně. Zákazník nepotřebuje okamžité zpracování, ale potřebuje vědět, jestli import proběhl správně, dohledat jeho stav a rozumně se zotavit z chyby. Do budoucna by podobnou možnost mohli využít i další zákazníci, jen zatím není jasné, v jakém rozsahu a kdy.

Petr si tentokrát nezapíše pouze to, že se má implementovat import. Poznamená si také, pro koho je první verze určená, jaký objem je teď očekávaný a co pro zákazníka znamená dobrý výsledek. Když se později začnou probírat technické varianty, má se k čemu vrátit.

Samotný import bude vhodné zpracovávat asynchronně. Tým má dvě rozumné možnosti. Může použít mechanismus úloh na pozadí, který už aplikace využívá jinde. Je známý, tým ho umí provozovat, dokáže evidovat stav zpracování a řešit opakování i zotavení po chybě. Podle dosavadních předpokladů by měl očekávaný objem zvládnout bez větších nových infrastrukturních nároků. Druhou možností je obecnější event-driven řešení. To by poskytlo lepší základ, pokud by se z importu časem stal výrazně větší integrační mechanismus. Jenže by přineslo novou infrastrukturu, další implementační práci a provozní složitost už teď, kdy takový objem potvrzený není.

Petr má připravit pro manažera doporučení, podobně jako minule. Jeho první instinkt je pustit se do porovnání technických vlastností obou variant. To samozřejmě potřebuje udělat. Tentokrát si ale všimne, že v zadání zůstala jedna informace, bez které může správné porovnání vést ke špatnému závěru: Je rozšíření na další zákazníky reálný závazek v dohledné době, nebo zatím jen možnost?

Připraví si vedle sebe hlavní rozdíly, které zatím dokáže obhájit:

Tabulka sama o sobě nestačí. Pokud má firma na širší rollout konkrétní plán, mohou být vyšší počáteční náklady dobře odůvodněné. Pokud jde jen o hypotetickou budoucnost, mohl by tým platit za složitost, kterou teď nepotřebuje. Petr nechce znovu udělat doporučení založené na tom, že chybějící informace tiše nahradí vlastní představou.

Proto se manažera zeptá, jestli se s dalšími zákazníky a výrazně větším objemem už skutečně počítá, nebo jestli jde zatím jen o jednu z možných dalších cest. Tentokrát se dozví odpověď ještě před dokončením podkladu. Širší využití je reálná možnost, ale firma teď nemá potvrzený konkrétní rollout ani objem, kvůli kterému by první verzi potřebovala budovat jako vysokokapacitní integrační platformu.

Petr tím nedostal technické řešení hotové. Nezjistil ani přesný objem budoucích importů. Získal ale důležitý rozdíl mezi současným závazkem a možnou budoucností. Teď dokáže vysvětlit, proč se při aktuálním rozhodnutí mají určité technické vlastnosti a náklady vážit jinak, než kdyby už byl větší rollout potvrzený.

Doporučení, které počítá i s možností změny

Petr se k podkladu vrátí a své srovnání doplní o kontext první verze. Nevynechá technické argumenty. Stále potřebuje řešit provozní spolehlivost, zotavení z chyby, náročnost implementace, budoucí škálování a cenu případné změny. Ale už nehodnotí všechny tyto vlastnosti, jako by měly v každé firmě a každém okamžiku stejnou váhu.

V doporučení manažerovi napíše, že pro první verzi dává smysl použít stávající mechanismus úloh na pozadí. Při několika očekávaných importech denně by měl stačit, tým s ním má zkušenost a nemusí kvůli této funkci přidávat novou infrastrukturu. Pro aktuálního zákazníka je důležitější dohledatelnost importů, bezpečné opakování a zotavení po chybě než příprava na vysoké objemy, které ještě nejsou potvrzené.

Event-driven variantu nezavrhuje jako technicky špatnou. Vidí její výhody pro větší počet integrací a výrazně vyšší provozní zátěž. Jen pro dnešní zadání by znamenala více práce a složitosti kvůli možnosti, která zatím není konkrétním plánem. Petr zároveň pojmenuje cenu svého doporučení: pokud objem nebo šíře použití zásadně poroste, část zpracování bude možná potřeba změnit a firma zaplatí část práce znovu. Proto navrhuje samotné zpracování oddělit od zbytku funkce tak, aby případná budoucí změna nebyla zbytečně provázaná s celým importem.

Když podklad manažerovi předává, nevysvětluje mu pouze, která technologie mu vyšla lépe. Vysvětluje, za jakých současných předpokladů doporučení platí a co by muselo začít vypadat jinak, aby stálo za nové posouzení. Nemá v ruce žádnou univerzálně nejlepší architekturu. Má doporučení pro konkrétní situaci, včetně rizika, které je s jednodušším řešením ochotný navrhnout k přijetí.

Manažer si ho projde a tentokrát reaguje jinak než při debatě o refactoringu.

"Tenhle podklad je pro mě použitelný," řekne. "Je jasné, proč pro první verzi doporučuješ jednodušší variantu, co bychom si přidali tou složitější a jaké riziko si necháváme do budoucna. A neargumentuješ jen tím, že event-driven by byl technicky zajímavější."

Petr si uvědomí, že tentokrát se manažer nemusí nejdřív ptát, jaké rozhodnutí vlastně řeší. Podklad vychází z potřeby prvního zákazníka a z toho, co je o možném rozšíření zatím potvrzené. To samozřejmě neznamená, že jeho doporučení musí být bez výhrad přijato.

"Jednu věc bych ale ještě doplnil," pokračuje manažer. "Dokážeme říct konkrétněji, kdy bychom to rozhodnutí měli znovu otevřít? Jestli při určitém počtu zákazníků, objemu importů, nebo třeba ve chvíli, kdy přibude další typ integrace?"

Petr se podívá na poslední odstavec. Napsal, že by se k volbě vrátil při výrazně větším objemu nebo širším použití. Jenže slovo "výrazně" zatím ničím konkrétním nepodložil. Nechce proto z hlavy vymyslet hranici, která by působila přesně a přitom by neodpovídala žádným ověřeným požadavkům ani provozním datům.

"To zatím přesně nevím," přizná. "Vím, které změny by pro to byly relevantní. Ale nemám ještě podklad pro konkrétní trigger."

Manažer přikývne. Otázka zůstává otevřená. Z jeho reakce nelze vyvozovat, kterou variantu firma nakonec implementuje, jak bude fungovat ani zda se někdy opravdu rozšíří na další zákazníky. Petr však dostal zpětnou vazbu k něčemu, co skutečně připravil, a další otázku, kterou jeho současný podklad ještě neřeší.

Když při technickém rozhodnutí vybereš variantu, která dává smysl pro dnešní situaci, neznamená to, že musí zůstat správná za všech okolností. Někdy je rozumné přijmout riziko budoucí úpravy místo toho, abys dnes platil za složitost, kterou zatím nepotřebuješ. Důležité je ten trade-off pojmenovat a nepředstírat, že budoucnost znáš přesně. A pokud říkáš "vrátíme se k tomu, až se podmínky změní", stojí za to se zeptat, jakou změnu budeš ve skutečnosti sledovat. Petr tuhle hranici zatím nemá. Právě tím ale vzniká použitelná další otázka, ne důvod tvářit se, že druhý pokus byl k ničemu.

Co se při druhém pokusu skutečně změnilo

Když si Petr porovná oba podklady, rozdíl už není jen v tom, že řešil dva jiné technické problémy. Při refactoringu vyšel z historie změn, sestavil ekonomický argument a teprve v rozhovoru s manažerem zjistil, že pro rozhodnutí chybí důležitý termínový a klientský kontext. O šest týdnů později si naopak připomněl nový krok v roadmapě ještě před meetingem o produktu, zachytil, co je důležité pro první verzi, a u připravovaného doporučení poznal další mezeru. Na možný rollout se tentokrát aktivně zeptal dřív, než učinil závěr.

V obou případech se přitom opíral o technické uvažování. Napoprvé uměl přibližně spočítat investici a její možnou návratnost, ale neřešil dostatečně okolnosti rozhodnutí. Podruhé porovnal dvě reálné technické varianty, jejich náklady, provozní důsledky a přijatá rizika, a přidal k tomu ověřený současný kontext. Nevynechal technickou práci. Změnil pořadí otázek, které si kladl, a to, jak zacházel s informacemi, které ještě neměl.

Z druhého pokusu je zatím vidět konkrétní změna Petrova chování, ne prokázaná nová úroveň jeho schopností. Manažer označil jeden podklad za použitelný, ale neřekl tím, že z Petra je hotový architekt, ani nepotvrdil správnost zvolené technologie nebo její budoucí výsledek. Položil další otázku, na kterou Petr ještě nezná odpověď. To, co se změnilo v jeho přístupu, je možné porovnat. Jestli mu tento přístup dlouhodobě pomůže a co firma skutečně udělá, zatím neví.

Petr na začátku této části své cesty čekal, že potřebuje získat lepší přístup k rozhodování. Po prvním pokusu zjistil, že někdy potřebuje udělat něco mnohem prostšího: poznat, na co se má zeptat, a nebát se v podkladu označit důležitou nejistotu. Z mentoringu se ten poznatek dostal do jeho roadmapy a z roadmapy do další skutečné pracovní situace. Nová reakce manažera zároveň ukázala, že tím učení nemusí končit. K jedné přesnější otázce se může přidat další.

Dosud se Petr vracel hlavně k tomu, jak udělat jinak svůj další krok. Pořád přitom vycházel z pracovní představy architektonické odpovědnosti, kterou si s Igorem sestavil na začátku. Ta zatím zůstávala stejná. Jenže co když nové informace z prostředí, ve kterém chce jednou takovou odpovědnost převzít, změní i jeho původní představu o cíli? Pak už nebude stačit upravit jeden úkol v roadmapě.