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 rozhodnutí jsou součástí tohoto fiktivního příkladu.
Když už si Petr myslel, že ví, kam jde
Petr měl ze své rozvojové roadmapy docela dobrý pocit. Ne proto, že by se mu podařilo odškrtnout všechny úkoly nebo že by se za posledních několik týdnů nějak zásadně změnila jeho pracovní role. Pořád byl seniorní vývojář, pořád řešil běžnou práci na projektu a pořád ho občas štvalo, kolik technických problémů vzniká kvůli rozhodnutím, která nedokáže přímo ovlivnit. Jen už měl mnohem konkrétnější představu o tom, co vlastně chce rozvíjet a proč.
Při prvních setkáních s Igorem si zkoušel sestavit pracovní model softwarového architekta. Tehdy si myslel, že architektura znamená hlavně větší vliv na technické směřování systému. Postupně ale zjistil, že s takovou rolí může souviset mnohem více práce s lidmi, kompromisy, rozhodováním v nejistotě a odpovědností za důsledky, které nejdou vyjádřit jen kvalitou kódu. Z původní představy nakonec vznikl poměrně konkrétní model pětadvaceti kompetencí a odpovědností. Nebyla to univerzální definice architekta, ale pro Petrovo další přemýšlení představovala použitelný pracovní základ.
Potom začal porovnávat tento model s tím, co skutečně dělá a umí. Vybral několik důležitých rozdílů, sestavil z nich priority a postupně je překládal do konkrétních úkolů. Dokonce se mu podařilo získat prostor pro dva pokusy na skutečných technických rozhodnutích. Při prvním přehlédl důležitý klientský a termínový kontext. Při druhém se na chybějící informace zeptal dřív, než dokončil doporučení.
Druhý podklad manažer označil za použitelný. Přidal ovšem další otázku: podle čeho by tým poznal, že se má ke zvolenému technickému řešení v budoucnu vrátit? Petr zatím neměl podklady pro konkrétní hranici, při které by stálo za to rozhodnutí přehodnotit. Nechtěl si ji vymýšlet, a tak si ji nechal jako otevřenou otázku.
Bylo to příjemně jiné než jeho původní způsob uvažování. Dřív měl tendenci vnímat podobnou připomínku jako nedostatek svého technického návrhu, který musí co nejrychleji odstranit. Teď už dokázal přijmout, že rozumné doporučení může obsahovat i přesně pojmenovanou nejistotu. Neznamenalo to, že se z něj stal hotový architekt nebo že jeho schopnosti někdo objektivně změřil jako lepší. Bylo ale možné porovnat, jak připravoval první a druhý podklad a co při nich udělal jinak.
Na své roadmapě dál nechával jako aktuální fokus vysvětlování byznysového přínosu a dopadu technických řešení. Měl pro to konkrétní důvod a několik dalších věcí, které chtěl při práci zkoušet. Ostatní rozvojové oblasti zatím zůstávaly na později.
A právě ve chvíli, kdy měl pocit, že jeho plán konečně dává smysl, přišla informace, která se netýkala žádného z jeho příštích úkolů.
Architekt, který nezná zákazníkův systém
Po nějaké době se na pravidelném 1:1 manažer vrátí k Petrově dlouhodobému směřování.
"Mluvil jsem o tom i s vedením," začne. "U nás vlastně nemáme samostatnou roli softwarového architekta přesně v podobě, jakou sis původně zkoušel popsat. Ale dává nám smysl přemýšlet o tom, jestli bychom takovou odpovědnost nemohli postupně vymezit kolem toho, co firma skutečně potřebuje."
Petr zpozorní. O větší technické odpovědnosti už spolu mluvili několikrát, ale zatím šlo hlavně o to, na čem může pracovat v současné roli. Tohle zní trochu jinak.
"Takže by se u nás mohla vytvořit architektonická pozice?" zeptá se.
"Možná. Ale zatím bych tomu tak neříkal. Nemáme rozhodnuté, jestli z toho vznikne samostatná role, jaké by měla pravomoci ani kdo by ji případně zastával. Spíš jsme se bavili o tom, kde nám podobná technická odpovědnost dnes chybí nebo kde by nám mohla pomoct."
Petr trochu zklamaně přikývne. Na okamžik si už stihl představit, že se jeho kariérní plán posunul o podstatný kus dopředu. Manažer mu ale žádné povýšení nenabízí. Přináší pouze novou informaci o tom, jak o technických odpovědnostech firma přemýšlí.
Jedním z témat, která při rozhovoru s vedením vznikla, je spolupráce s významnějšími zákazníky. Někteří mají vlastní technické týmy, vlastní systémy a poměrně složité prostředí, do kterého se produkty Petrovy firmy musí nějak začlenit. Dnes se podobné situace řeší podle toho, kdo má zrovna potřebné informace a kdo je k danému zákazníkovi nebo projektu nejblíž. Někdy je to člověk z vývoje, jindy někdo z produktu nebo manažer. Pokud by ale firma chtěla takovou spolupráci technicky zastřešovat systematičtěji, mohl by dávat smysl člověk, který dokáže fungovat jako jeden z technických partnerů zákazníka.
"To by ale znamenalo znát i jejich systémy," namítne Petr. "A to přece často vůbec nepůjde. My někdy nemáme pořádné informace ani o všech částech vlastního produktu, natož o tom, co si zákazník provozuje někde u sebe."
"Právě," odpoví manažer. "Nemůžeš počítat s tím, že ti dají celý zdroják a několik týdnů na jeho prostudování. Spíš dostaneš nějakou dokumentaci, popis prostředí a omezený čas s lidmi, kteří jednotlivým částem rozumějí. A pak budete potřebovat rozhodnout, jak mají vaše systémy spolupracovat, kde jsou hranice odpovědnosti a jaká omezení musíte respektovat."
Petr si představí podobnou situaci. Na stole má integrační rozhodnutí, ale nezná přesnou implementaci druhé strany. Neví, jak mají zákazníkovy systémy rozdělené odpovědnosti, kde uchovávají důležitá data nebo jak řeší některé provozní problémy. Nemůže si otevřít jejich repozitář, projít služby jednu po druhé a vytvořit si obrázek stejným způsobem, jakým to dělá ve vlastní firmě.
"A co když bez těch detailů nedokážu říct, jestli to bude fungovat?"
"Pak budeš muset poznat, které detaily opravdu potřebuješ. Některé si vyžádáš od jejich lidí. Některé možná nebudou relevantní. A pokud ti bude chybět něco zásadního, tak prostě nebudeš moct udělat bezpečný závěr. Ale nemůžeme stavět každé společné rozhodnutí na tom, že jeden člověk nastuduje celý jejich systém do posledního detailu."
Petr se nad tím zamyslí. Ve vlastní firmě má jednu velkou výhodu, kterou už skoro nevnímá. Je tam téměř pět let. Zná historii produktů, pamatuje si některá starší rozhodnutí, ví, na koho se obrátit, a často dokáže odhadnout, kde se problém pravděpodobně nachází, ještě než se do něj pořádně podívá. Když potřebuje něco ověřit, většinou má možnost otevřít kód nebo se zeptat kolegy.
U zákazníkova prostředí by mu velká část těchto opěrných bodů chyběla. A přitom by po něm firma mohla chtít, aby pomohl připravit technické rozhodnutí s důsledky pro obě strany.
"Já jsem si pod architekturou pořád představoval hlavně odpovědnost za naše systémy," přizná nakonec. "Rozumět jim jako celku, navrhovat větší změny, hlídat dlouhodobý směr. Tohle je trochu jiná práce."
"Není to úplně jiná disciplína," odpoví manažer. "Ale je to jiný kontext. A jestli budeme někdy architektonickou odpovědnost u nás vymezovat, měli bychom vycházet z toho, co skutečně potřebujeme. Ne jen z obecné představy, jak má vypadat softwarový architekt."
Petr se cestou od schůzky nevrací k otázce, jestli se má naučit nějakou další technologii. Přemýšlí o něčem nepříjemnějším. Už několik týdnů si pečlivě skládá plán, jak se přiblížit cílové roli. Jenže skutečná podoba té role v jeho firmě může být konkrétnější a v některých ohledech jiná, než si na začátku představoval.
A pokud je jiný cíl, možná nebude stačit jen pokračovat podle dosavadního seznamu.
Pětadvacet bodů, které nemusí skončit v koši
Na dalším setkání Petr Igorovi popíše, co se dozvěděl. Tentokrát nepřinese nový technický problém ani podklad, který chce společně projít. Otevře původní pracovní model architekta a vedle něj svou aktuální roadmapu.
"Takže teď vlastně nevím, jestli jsme si celou dobu nenastavili špatný cíl," řekne. "Když jsme dělali ten seznam kompetencí, představoval jsem si hlavně architekta pro naše produkty. A teď se ukazuje, že firma možná bude potřebovat člověka, který se dokáže rychle zorientovat v systémech zákazníků."
"Co přesně je na tom původním modelu špatně?" zeptá se Igor.
Petr začne procházet seznam. Systémové uvažování, návrh řešení, technické kompromisy, práce s nejistotou, komunikace s různými lidmi, facilitace diskusí, zohlednění byznysového kontextu. Nic z toho najednou nepřestalo dávat smysl. Dokonce by se většina těchto schopností hodila i při spolupráci se zákaznickým technickým týmem.
"Špatně asi nic," připustí. "Jen jsme některé věci popsali moc obecně."
"Například?"
Petr se zastaví u systémového uvažování. Když tuto oblast posuzovali poprvé, vyšlo mu, že už dokáže poměrně dobře chápat širší souvislosti v prostředí, které zná. Problém měl spíš s neznámými částmi systému. Tehdy si uvědomil, že systémový pohled není totéž jako hluboká expertiza na každou použitou technologii. Jeho původní odhad 2/5 proto po rozhovoru zpřesnili přibližně na 3/5 proti pracovnímu cíli 4/5.
Teď má ale před sebou situaci, která tomuto rozdílu dává mnohem konkrétnější podobu. Nejde jen o to, jestli se vyzná v komponentě, kterou běžně nepoužívá. Může potřebovat pracovat s celým relevantním úsekem cizího prostředí, u kterého nemá přístup ke kódu, nezná historii rozhodnutí a nemůže se spolehnout ani na to, že si všechny potřebné informace zjistí sám.
"Takže bych se měl naučit rychle pochopit cizí systém," navrhne Petr.
"To pořád zní docela široce. Co znamená pochopit ho?"
"No, vědět, z čeho se skládá, jaké používá technologie, jaké tam mají služby, databáze, integrace..."
"A k čemu to chceš vědět?"
"Abych s nimi dokázal navrhnout řešení."
"Jaké řešení?"
Petr se zarazí. V jeho hlavě už se začal tvořit seznam věcí, které by musel nastudovat při každém novém zákazníkovi. Jenže Igorova otázka ho vrací k něčemu, co už jednou řešili: ne všechny informace o systému mají stejnou hodnotu pro každé rozhodnutí.
"Dobře," začne znovu. "Kdybychom se třeba měli rozhodnout, jak mezi naším produktem a jejich systémem předávat data, potřeboval bych vědět, které části spolu komunikují, kdo za co odpovídá, jaká jsou omezení a co se má stát, když něco selže."
"A potřebuješ kvůli tomu znát implementaci každé jejich služby?"
"Asi ne. Ale někdy může být konkrétní implementační detail důležitý."
"Jasně. Pak potřebuješ zjistit právě ten detail. Nebo se k němu dostat přes člověka, který ho zná. Jen bych se nejdřív ptal, pro jaké rozhodnutí ho potřebuješ."
Petr se vrátí ke své původní formulaci. Systémové uvažování si dřív spojoval hlavně se schopností vidět důležité vazby a dopady změn napříč řešením. To zůstává důležité. Jenže v jeho aktuálně zvažované cílové roli přibývá schopnost vytvořit tento obraz rychle, z omezených informací a jen do takové hloubky, kterou konkrétní rozhodnutí skutečně vyžaduje.
"Takže mám vlastně poznat, co všechno nevím?" zeptá se Petr.
"To by byl docela nekonečný úkol," odpoví Igor. "Spíš potřebuješ poznat, co pro dané rozhodnutí vědět musíš. Co už je potvrzené, co si jen myslíš, na co se máš zeptat a které detaily teď nemají podstatný vliv."
Petr si začne představovat přípravu na rozhovor se zákaznickým technickým týmem. Místo snahy sestavit úplnou technickou dokumentaci jejich prostředí by si nejdřív vymezil rozhodnutí, které společně řeší. Potom hlavní systémy a hranice mezi nimi, důležité vazby, známá technická nebo provozní omezení a místa, kde jeho model stojí na předpokladech. Teprve podle toho by připravil otázky. Některé by potřeboval položit hned, protože bez odpovědi nelze rozumně pokračovat. Jiné by možná vůbec nemusel řešit.
Neznamená to, že je hlubší technické porozumění zbytečné. Pokud konkrétní rozhodnutí závisí na chování databáze, integračního rozhraní nebo některé části infrastruktury, musí se k potřebnému detailu dostat. Rozdíl je v tom, že se nepokouší získat všechny detaily předem. Hloubku poznání odvozuje od rozhodnutí, nikoli od toho, kolik dokumentace nebo kódu má ještě k dispozici.
"Přesně tohle bych chtěl umět," řekne Petr po chvíli. "Podívat se na prostředí, které vůbec neznám, a nepropadnout hned pocitu, že si musím nastudovat celý jeho stack."
"Pak už máš konkrétnější popis schopnosti než před chvílí. Jen bych zatím nepředpokládal, že ji neumíš vůbec. Některé části už používáš. Potřebuješ zjistit, co z nich dokážeš přenést do neznámého prostředí a kde se ti začne ztrácet půda pod nohama."
Petr tedy nepřepisuje celý model architekta. Vrátí se k jedné jeho části a zpřesní ji podle nové informace z firmy. Z původního obecnějšího systémového pohledu vzniká konkrétnější požadavek:
V omezeném čase si vytvořit dostatečný pracovní model relevantní části neznámého nebo externího technického prostředí, rozpoznat důležité hranice, vazby, omezení, předpoklady a neznámé a zjistit jen takovou úroveň detailu, která je potřebná pro konkrétní architektonické rozhodnutí.
Petr si formulaci přečte ještě jednou. Je delší než původní položka. Zároveň si ale mnohem snáz představí situaci, ve které by ji mohl použít, a otázky, podle kterých by poznal, kde má mezery.
Když se připravuješ na roli s větší technickou odpovědností, můžeš snadno dojít k závěru, že potřebuješ znát víc technologií a víc systémů. Někdy to bude pravda. Ale zkus rozlišit dvě věci: rozšířit své technické znalosti a umět udělat technické rozhodnutí v prostředí, které nikdy nebudeš znát celé.
V tom druhém případě není cílem odstranit všechny neznámé. Potřebuješ zjistit, které z nich mohou změnit rozhodnutí, které informace dokážeš ověřit a kde už musíš přizvat člověka s hlubší znalostí. Stejně důležité je poznat, kdy máš podkladů dost a kdy bys jen nahrazoval chybějící jistotu vlastní představou. To je práce, která může být pro architekta podstatná i v situaci, kdy většinu implementačních detailů vůbec nevidí.
Priorita, která se změnila bez jediného nového úkolu v práci
Petr má chuť přesunout právě zpřesněné systémové uvažování rovnou mezi své aktuální priority. Konečně totiž vidí konkrétní situaci, ve které by se mu mohlo hodit. Jenže když otevře roadmapu, všimne si, že tuto oblast už v ní má. Je pouze v části POZDĚJI, s pracovní Prioritou přibližně 0,33.
Při původním hodnocení to dávalo smysl. Petr už v určitých situacích systémový pohled používal, takže proti pracovnímu cíli 4/5 vycházel přibližně z odhadu 3/5. Pro danou oblast zvolil Hodnotu 1, protože šlo o rozšíření již používané schopnosti. Snaha zůstala 3, protože rozvoj takto široké kompetence nebude úkol na jedno odpoledne. A Naléhavost byla 0. Neměl žádný konkrétní požadavek zaměstnavatele ani termín, který by mu říkal, proč se této schopnosti věnovat dříve než jiným.
Teď se na tu nulu dívá jinak.
"Takže bych tomu měl zvýšit Hodnotu?" zeptá se Igora.
"Proč zrovna Hodnotu?"
"No, najednou se ukazuje, že to pro tu roli může být mnohem důležitější, než jsme si mysleli."
"A změnila se samotná schopnost? Nebo se objevil konkrétnější důvod, proč ji můžeš potřebovat v prostředí, kde pracuješ?"
Petr se vrátí k tomu, jak původní priority sestavovali. Hodnota vyjadřovala význam rozvoje dané oblasti vzhledem k jeho aktuální úrovni a cíli. Snaha přibližně říkala, kolik kapacity si vyžádá. Naléhavost zachycovala konkrétní vnější důvod, proč se něčemu věnovat právě teď, například termín nebo potřebu zaměstnavatele.
Nová informace od manažera neznamená, že Petr během jednoho rozhovoru získal nové schopnosti. Neprokazuje ani, že se jeho původní odhad musí okamžitě změnit. A firma zatím nepotvrdila žádnou novou pozici ani konkrétní pracovní úkol, který by Petr měl převzít.
Přesto už systémové uvažování v neznámém prostředí není jen obecná schopnost, která by se jednou mohla hodit nějakému architektovi. Vedení jeho firmy právě zvažuje technickou odpovědnost, pro kterou by mohla být podstatná. To je konkrétnější důvod než původní obecná představa.
Petr se proto rozhodne použít stejný pracovní mechanismus, kterým dříve reagoval na blížící se klientskou schůzku. Hodnotu a Snahu zatím ponechá beze změny. K Naléhavosti přidá 0,5, protože se objevil relevantní požadavek zaměstnavatele, byť zatím ve fázi zvažování.
Výpočet zůstává jednoduchý:
textPriorita = Naléhavost + (Hodnota / Snaha)
PŮVODNÍ STAV
Hodnota: 1
Snaha: 3
Naléhavost: 0
Priorita: 0 + (1 / 3) ≈ 0,33
PO NOVÉ INFORMACI Z FIRMY
Hodnota: 1
Snaha: 3
Naléhavost: 0,5
Priorita: 0,5 + (1 / 3) ≈ 0,83Petr se na výsledek podívá. Na první pohled je to docela výrazná změna. Priorita, kterou ještě nedávno téměř přehlížel na konci seznamu, má nyní přibližně 0,83. Není to ale číslo, které by samo rozhodlo o jeho příštím pracovním týdnu.
"Takže to mám přesunout do TEĎ?" zeptá se.
"Podívej se, co už v TEĎ máš," odpoví Igor.
Petr otevře aktuální fokus: vysvětlování byznysového přínosu a dopadu technických řešení, Priorita 1,00. Je to oblast, na které se vědomě rozhodl pokračovat po klientské schůzce. Získal v ní prostor ke dvěma konkrétním pokusům a z toho druhého si odnesl další otevřenou otázku. Nemá důvod ji jen tak zahodit.
"Nechci teď rozjíždět dvě velké věci najednou," řekne. "A navíc zatím ani nevím, jestli se k nějaké takové zákaznické diskusi dostanu."
"Tak proč bys musel automaticky přepnout?"
"Nemusel. Jen už mi nedává smysl nechat tu oblast úplně stranou."
Právě v tom se Petrův pohled na prioritizaci za poslední dobu změnil. Číslo mu nemá říkat, co musí udělat, bez ohledu na ostatní okolnosti. Má mu pomoct zviditelnit důvody rozhodnutí. Systémové uvažování v neznámém prostředí je nyní relevantnější než před několika týdny, ale to ještě neznamená, že se stalo jedinou správnou současnou prioritou.
Petr tedy ponechá vysvětlování byznysového dopadu jako svůj aktivní rozvojový fokus. U systémového uvažování ale aktualizuje prioritu, zpřesní cílovou schopnost a rozhodne se připravit konkrétní krok pro případ, že se vhodná pracovní příležitost objeví.
Všimni si rozdílu mezi změnou důležitosti rozvojové oblasti a rozhodnutím, že na ní musíš začít pracovat okamžitě. Nová informace ti může změnit představu o tom, co budeš v cílové roli potřebovat. Tím se změní i důvody, podle kterých posuzuješ jednotlivé mezery. Nemusíš ale automaticky opustit všechno, čemu ses věnoval dosud.
Pokud máš roadmapu postavenou na konkrétních předpokladech, můžeš změnit právě ten, kterého se nová informace týká. Tady Petr nepřehodnotil celý život ani nepřepočítal všechny kompetence od začátku. Zpřesnil jeden požadavek cílové role a upravil jeho Naléhavost podle toho, co se dozvěděl od zaměstnavatele. Jestli se tím změní také jeho současný fokus, zůstává samostatným rozhodnutím.
Úkol pro situaci, která ještě nenastala
Petr se vrátí k roadmapě. U nově zpřesněné oblasti má nyní konkrétnější popis a vyšší prioritu, ale pořád ještě nemá nic, co by mohl v běžné práci skutečně udělat. Napsat si "naučit se rychle orientovat v zákaznických systémech" by mu příliš nepomohlo. Je to jen jinak formulovaná kompetence.
"Takže si mám najít nějakou cizí aplikaci a zkusit si ji zmapovat?" zeptá se.
"To by mohl být jeden typ cvičení," odpoví Igor. "Ale co bys na tom vlastně chtěl zkoušet?"
"Vytvořit si rychle obrázek systému z dokumentace a dostupných informací."
"A pro jaké rozhodnutí?"
Petr se znovu zarazí. Už podruhé během stejného setkání se přistihl, že chce začít sbíráním informací dřív, než si vyjasní, k čemu je bude potřebovat.
"Takže bych měl mít nejdřív konkrétní situaci," řekne. "Třeba když budeme se zákazníkem řešit integraci nebo změnu na rozhraní našich systémů."
"To už je bližší tomu, co ti popisoval manažer. A co bys pro takovou diskusi připravil?"
Petr začne vyjmenovávat věci, které ho napadly při rozhovoru o novém modelu role. Nejdřív by potřeboval vědět, jaké rozhodnutí se má udělat a jaká část zákazníkova prostředí je pro něj relevantní. Potom by si z dostupných podkladů nakreslil jednoduchý model hlavních systémů, jejich hranic a důležitých vazeb. Oddělil by fakta, která má potvrzená, od vlastních předpokladů. Zapsal by omezení a otázky, bez kterých se zatím nedá udělat rozumný závěr.
"A po té diskusi?" zeptá se Igor.
"Upravil bych model podle toho, co se potvrdilo. A nechal bych tam věci, které pořád nevíme."
"Dokázal bys pak říct, jestli ten model stačí pro rozhodnutí, které jste řešili?"
"To bych právě chtěl zkusit zjistit."
Petr si uvědomí, že má konečně něco podobného jako při prvním rozkladu práce s trade-offy. Tehdy si vybral známé technické rozhodnutí a měl popsat alespoň dvě varianty včetně nákladů, omezení a rizik. Tentokrát nemá připravovat doporučení pro konkrétní technologii. Má si vyzkoušet, jak z neúplných informací vytvořit pracovní obraz cizího prostředí, který pomůže rozhodování.
Rozdíl je v tom, že zatím žádnou vhodnou zákaznickou diskusi domluvenou nemá. Manažer mu neřekl, že bude nové technické partnerství zastřešovat, ani mu neslíbil účast na konkrétním jednání. Nemá tedy smysl tvářit se, že úkol začne plnit hned zítra.
Do roadmapy si ale může připravit přesnou podobu kroku pro případ, že se taková příležitost objeví:
textSMĚR
SW architekt / vyšší technická odpovědnost
v kontextu skutečných potřeb firmy
TEĎ
Byznysový přínos a dopad technického řešení
Priorita: 1,00
POZDĚJI
Systémové uvažování v neznámém externím prostředí
Priorita: přibližně 0,83
(původně 0,33)
PŘIPRAVENÝ DALŠÍ KROK
[ ] Pokud se objeví vhodná technická diskuse se zákazníkem,
předem vytvořit jednoduchý pracovní model relevantní
části jeho prostředí pro konkrétní rozhodnutí.
Zachytit:
- hlavní systémy a hranice odpovědnosti;
- důležité vazby a závislosti;
- známá technická a provozní omezení;
- potvrzená fakta;
- vlastní předpoklady;
- podstatné otevřené otázky.
U každé oblasti poznamenat, proč je informace
potřebná pro dané rozhodnutí. Nesnažit se
zmapovat celý systém ani všechny implementační detaily.
Po diskusi model aktualizovat:
- co se potvrdilo nebo změnilo;
- které důležité informace stále chybí;
- zda je model dostatečný pro řešené rozhodnutí.Petr se na zápis chvíli dívá. Ve skutečnosti ještě nic z toho neprovedl. Neví, jestli dostane vhodnou příležitost ani jaké podklady by při ní měl k dispozici. Přesto už dokáže poměrně přesně říct, co by při takové situaci chtěl vyzkoušet a podle čeho by bylo možné jeho postup později posoudit.
"A kdyby se ta příležitost neobjevila?" zeptá se.
"Pak budeš vědět, že ji zatím nemáš," odpoví Igor. "Můžeme hledat jiný způsob, jak si některé části vyzkoušet. Ale nedělal bych teď z hypotetického cvičení důkaz, že umíš pracovat se skutečným zákazníkem."
Petr přikývne. Vzpomene si, jak dříve chtěl chodit na schůzky vedení a nakonec získal menší, ale reálnou příležitost připravit technický podklad. Možná se něco podobného podaří i tentokrát. Možná ne. Zatím má alespoň konkrétní pracovní otázku, se kterou může za manažerem přijít, pokud se vhodné téma otevře.
A hlavně si všimne ještě jedné věci. Tenhle úkol nevznikl proto, že by při posledním technickém doporučení udělal další chybu. Vznikl proto, že se dozvěděl něco nového o podobě práce, ke které se chce postupně přiblížit.
Návrat, který neznamená začít od začátku
Když Petr později prochází své poznámky, poprvé vidí celou dosavadní cestu trochu jinak. Na začátku chtěl hlavně větší vliv na technická rozhodnutí. Připadal si dost zkušený na to, aby u některých věcí nemusel jen čekat, co rozhodnou ostatní. Architektura mu proto připadala jako logický další krok.
Jenže už při vytváření prvního modelu zjistil, že samotný titul mu nedá automaticky poslední slovo při každém technickém rozhodnutí. Musel začít rozlišovat, za co architekt skutečně odpovídá, jaké informace potřebují ostatní lidé a kde končí technické doporučení a začíná přijetí byznysového rizika. Potom si uvědomil, že některé schopnosti používá méně, než si myslel. Vybral priority, vytvořil roadmapu a začal s konkrétní praxí.
V průběhu se jeho plán několikrát změnil. Blížící se klientská schůzka mu dočasně zvýšila Naléhavost vysvětlování byznysového dopadu. Když termín pominul, Naléhavost se vrátila na původní hodnotu, ale Petr se rozhodl u dané oblasti pokračovat. To byla změna současné priority podle okolností a jeho vlastního rozhodnutí.
Později při prvním skutečném podkladu pro manažera zjistil, že přehlédl důležitý klientský závazek. Při mentoringu si uvědomil, že informaci, kterou neměl, se předem ani nepokusil získat. Změnil tedy další konkrétní krok ve své roadmapě. Při druhém pokusu se na podstatný kontext zeptal ještě před doporučením. To byla změna způsobu práce na základě zpětné vazby a nového pochopení problému.
Teď se ale stalo něco jiného.
Petr neřeší, že mu v posledním pokusu chyběla další otázka. Neřeší ani to, že se objevil naléhavější termín, kvůli kterému má na týden přepnout fokus. Dostává informaci, která zpřesňuje samotnou představu cílové role. Najednou se potřebuje vrátit až k tomu, co si o architektonické odpovědnosti původně myslel.
Původní model role nebyl špatný. Petr ho sestavil podle dostupných informací a v další práci mu skutečně pomohl. Jen tehdy ještě nevěděl, jakou podobu by mohla vyšší technická odpovědnost dostat právě v jeho firmě. Teď má od manažera konkrétnější, i když stále nezávaznou informaci o jednom směru, který vedení zvažuje.
A ta informace se postupně propíše do dalších částí jeho plánu. Zpřesní jeden požadavek cílové role. Díky tomu lépe pochopí svou rozvojovou mezeru. Znovu posoudí její prioritu podle aktuální potřeby zaměstnavatele. Upraví roadmapu a připraví konkrétní krok, kterým může novou schopnost při vhodné příležitosti zkoušet.
Petr přitom nemusí zahodit svou dosavadní práci. Pořád má stejné zkušenosti, stejná dvě technická doporučení, stejnou otevřenou otázku ohledně budoucího triggeru pro přehodnocení technologického rozhodnutí a stejný aktuální rozvojový fokus. Jen už se nedívá na svůj plán jako na cestu k jednou provždy pevně definovanému cíli.
Na konci dalšího setkání si ještě jednou otevře model architekta a vedle něj roadmapu.
"Víš, co je na tom zvláštní?" řekne Igorovi. "Když jsme ten model sestavili poprvé, měl jsem pocit, že teď konečně vím, co mám dělat. A čím víc se k té práci přibližuju, tím víc zjišťuju, že ta role může vypadat trochu jinak."
"To je docela užitečná informace, ne?"
"Jo. Jen mi chvíli trvalo přijít na to, že to nemusí znamenat, že jsme předtím udělali něco špatně."
Petr si vzpomene, jak dlouho se původně snažil přijít na správnou definici architekta. Jak porovnával pracovní nabídky, články a zkušenost bývalého kolegy. Jak se při prvním rozhovoru s Igorem zarazil u představy, že bude méně programovat. A jak nakonec přijal, že potřebuje pracovní model, se kterým může začít, ne definitivní popis každého možného architektonického místa.
Teď ho právě takový model dovedl k otázkám, které by si bez něj nejspíš nepoložil. A umožnil mu novou informaci zapracovat, místo aby musel začínat znovu.
"Takže ten Framework není návod, kterým projdu od začátku do konce a mám hotovo," řekne Petr.
"Nebyl ani předtím," odpoví Igor. "Jen jsi zatím neměl důvod vracet se takhle daleko."
Petr se pousměje. Před časem by ho podobná odpověď možná trochu štvala. Chtěl jasný plán, podle kterého se může postupně dostat k větší technické odpovědnosti. Teď už ale chápe, proč takový plán musí umět reagovat na nové informace. Kdyby se jeho původní představa role nikdy nemohla změnit, mohl by se v ní dál poctivě rozvíjet, i když by přestávala odpovídat práci, kterou chce ve skutečnosti dělat.
Zatím se z Petra nestal architekt. Firma o nové roli nerozhodla a Petr ještě nemá zkušenost s přípravou technického modelu cizího zákaznického prostředí pro společné rozhodnutí. Jeho roadmapa tedy neobsahuje žádný nový dosažený kariérní výsledek.
Obsahuje ale přesnější představu o možné cílové odpovědnosti, konkrétnější rozvojovou mezeru, aktualizovanou prioritu a připravený krok pro situaci, ve které se tato schopnost může opravdu projevit.
A Petr už ví, že pokud takovou příležitost dostane, nebude jeho prvním úkolem zjistit všechno o zákazníkově systému. Nejdřív bude potřebovat pochopit, o čem se vlastně rozhoduje a jaké informace jsou k tomu opravdu důležité.
Možná se pak ukáže, že jeho pracovní model potřebuje další úpravu. Možná zjistí, že některé části zvládá lépe, než čekal, a jiné vůbec. A možná přinese příští rozhovor s manažerem informaci, která jeho představu architektonické odpovědnosti znovu změní.
Tentokrát už ale Petr nebude považovat samotnou změnu plánu za problém. Důležitější pro něj bude, jestli dokáže vysvětlit, která nová informace ho ke změně vedla a co kvůli ní udělá jinak.