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.
Poznej svého Petra
Na Petrově projektu se už nějakou dobu hromadí technický dluh. Není to jeden velký průšvih, který by se dal ukázat na jediném incidentu. Spíš mnoho menších rozhodnutí, kvůli kterým je část aplikace čím dál složitější měnit. Vývojáři o tom opakovaně mluví, ale Petr má pocit, že se tématu ze strany managementu nedostává tolik pozornosti, kolik by si zasloužilo. Někteří kolegové už další snahu skoro vzdali. Petr zatím ne, i když ho začíná unavovat, že dokáže problém poměrně přesně popsat, ale jen obtížně ovlivňuje, co s ním firma udělá.
Přitom rozhodně není nezkušený vývojář, který by se poprvé setkal s komplikovanějším projektem. Má za sebou asi osm let profesionální praxe ve dvou firmách, z toho téměř pět let u současného zaměstnavatele. Za tu dobu prošel několika týmy, pracoval na dvou větších produktech a poznal dost lidí i mimo svůj aktuální tým. Kolegové za ním chodí konzultovat technické problémy a on sám dostává spíš větší úkoly, u kterých potřebuje rozumět několika částem systému najednou. Občas ho přizvou také k produktové diskusi, protože dokáže vysvětlit, co existující řešení technicky umožňuje a co už ne.
Programování ho pořád baví. Jen už jeho pracovní den dávno netvoří hlavně programování. Pokud chce několik hodin nerušeně něco implementovat, musí si na to vědomě vyhradit čas. Jinak se mu den snadno rozpadne mezi konzultace s kolegy, meetingy a řešení problémů, u kterých ostatní potřebují jeho znalost systému.
Petr začíná přemýšlet, jestli už není čas posunout se někam dál. Láká ho větší technická odpovědnost, možnost ovlivňovat dlouhodobé směřování systému a snad i trochu větší váha jeho argumentů, když se rozhoduje o věcech, jako je technický dluh. Napadá ho softwarová architektura. Kdyby byl architekt, možná by se nemusel pořád jen dívat, jak vznikají problémy, na které předem upozorňoval.
Jenže to poslední je zatím hlavně jeho představa. Petr vlastně neví, jakou rozhodovací pravomoc by architekt v jeho firmě měl. Neví ani, jestli by mu taková role skutečně pomohla řešit problémy, které ho dnes trápí. A jednu podstatnou otázku si zatím skoro nepoložil: co by se na jeho vlastní práci změnilo, kdyby se tím architektem opravdu stal?
Nejdřív zjistit, kam vlastně chce jít
Petr si uvědomuje, že chce dál profesně růst, ale není si jistý, kudy se z pozice seniorního vývojáře vydat. Rozhodne se proto své možnosti probrat s mentorem. S Igorem na prvních setkáních procházejí různé směry kariérního posunu. Architektura z toho vyjde jako směr, který Petra zajímá natolik, že stojí za to prozkoumat ho pořádně. Ne jako definitivní rozhodnutí o zbytku kariéry, ale jako pracovní hypotéza.
Igor mu ovšem nezačne sestavovat seznam technologií, které by se měl naučit, ani kurzů, které by měl absolvovat. Místo toho mu dá domácí úkol: připravit si vlastní pracovní představu softwarového architekta. Co ten člověk během běžného týdne dělá? Za co odpovídá? Jaké schopnosti potřebuje? V čem se jeho práce liší od práce seniorního vývojáře? A co Petrovi na té roli zatím není jasné?
Petr má hledat všude, kde mu to pomůže udělat si rozumný obrázek. Může číst pracovní nabídky, články, dívat se na přednášky, diskutovat s AI nebo mluvit s někým, kdo už tu práci dělá. U důležitých zjištění si má poznamenat, odkud je vzal. Ne proto, aby odevzdal akademickou rešerši, ale aby bylo při společné diskusi vidět, co je zkušenost konkrétního člověka, co tvrzení z pracovního inzerátu a co jen jeho vlastní předpoklad.
Igor si mezitím nezávisle připraví svůj model stejné role. Petr ho předem neuvidí. Při příštím setkání tak nepůjde o to, aby Petr správně opsal mentorův seznam, ale o porovnání dvou představ. Pokud se budou lišit, budou se mít o čem bavit.
Dvanáct bodů a několik nepříjemných překvapení
Petr se do úkolu pustí docela poctivě. Projde pracovní nabídky na architektonické pozice, přečte články o rozdílu mezi seniorem a architektem, podívá se na přednášku, diskutuje s AI a promluví si s bývalým kolegou, který dnes pracuje jako softwarový architekt. Postupně z toho poskládá dvanáct oblastí, které mu připadají důležité.
Část seznamu mu sedí skoro dokonale. Architekt by měl rozumět systému jako celku, navrhovat větší změny dřív, než se začne implementovat, orientovat se v technologiích a integracích, přemýšlet o dlouhodobé udržitelnosti. Přesně taková práce Petra láká. Už dnes ho na větších úkolech nejvíc baví chvíle, kdy musí rozmotat vztahy mezi několika komponentami a přijít na řešení, které bude dávat smysl jako celek.
Zajímavější jsou body, u kterých si začne psát otazníky. Architekt má mít vliv na výběr technologií a technický směr. Jenže znamená "mít vliv" také "mít právo rozhodnout"? Tři různé pracovní nabídky naznačují různý rozsah odpovědnosti. A pokud má architekt hlídat bezpečnost, proč má firma security experta? Má snad architekt rozumět do hloubky úplně všemu?
Pak přijde komunikace. Bývalý kolega mu popíše, že ho při přechodu k architektuře nepřekvapila ani tak větší technická složitost, jako množství času stráveného slaďováním lidí a týmů. Architekt musí vysvětlovat rozhodnutí, obhajovat kompromisy, naslouchat námitkám a někdy přesvědčovat lidi, kteří implementační detaily vůbec neřeší. Petr si při tom vzpomene na své současné dny, kdy se mu kvůli konzultacím skoro nepodaří dostat ke kódu. Jestli je tohle v architektuře ještě výraznější, nemusí to být tak skvělá změna, jak si původně představoval.
Nejvíc ho začne hlodat otázka, kolik vlastně architekt programuje. Některé zdroje popisují práci téměř bez běžné implementace, bývalý kolega občas vytvoří prototyp nebo si sám technicky ověří nápad. Petr by u kódu rád zůstal. Nevadilo by mu programovat méně než dnes, ale představa, že už prakticky vůbec nic nepostaví vlastníma rukama, se mu moc nelíbí.
Poslední překvapení je méně vznešené. Do seznamu se mu dostane také dokumentace architektonických rozhodnutí, jejich důvodů a souvislostí. Podle bývalého kolegy je to jedna z věcí, které architekt dělá častěji. Petrova první poznámka je stručná: "Fuj." Přesto ten bod ze seznamu nevyškrtne. Vlastně chápe, proč by mělo být možné po půl roce zjistit, proč se tým kdysi rozhodl právě takhle. Jen ho neláká představa, že by jednou místo kódu hlavně psal dokumentaci.
Na další setkání tedy přinese poměrně dobrý seznam. A také mnohem více pochybností, než měl před domácím úkolem.
Dva modely na jednom stole
Petr nejdřív Igorovi ukáže svou práci. Teprve potom Igor otevře vlastní model, který si připravil nezávisle. Na první pohled to vypadá povzbudivě: oba vnímají systémový pohled, architektonický návrh, technický dluh, dlouhodobou udržitelnost, komunikaci i kompromisy mezi variantami jako důležitou součást role.
"Takže jsem snad úplně mimo nebyl," poznamená Petr.
"Ne. Ale ani nebylo cílem trefit můj seznam. Zajímavější je, kde se ty seznamy rozcházejí."
A tam začne být rozhovor pro Petra podstatně méně pohodlný. Igorův model klade větší důraz na obhajování technických názorů, rozhodování v nejistotě, práci prostřednictvím ostatních lidí, facilitaci diskusí a překládání mezi technickým a byznysovým světem. Architekt podle něj nemusí být nejlepší programátor v místnosti. Často je důležitější, aby dokázal poskládat relevantní pohledy dohromady a pomoci ostatním udělat informované rozhodnutí.
Petr se vrátí k obavě, která se mu v poznámkách objevovala stále častěji. "Takže ještě víc komunikace a ještě míň programování? Už teď za mnou lidi chodí skoro celý den. Jestli tohle má být ještě výraznější, tak možná architektura vlastně není to, co hledám."
Igor ho nezačne uklidňovat tím, že i architekti někdy píšou kód. "Jo. To je dost pravděpodobné. Neřekl bych 'možná'. Pokud půjdeš tímhle směrem, je velmi realistické, že programování ubude a komunikace přibude."
Tohle Petr zrovna slyšet nechtěl. Přemýšlel o větším vlivu na technická rozhodnutí, ne o kariéře, ve které vymění svůj poslední souvislý čas na programování za další kalendář plný schůzek. Jenže Igor z toho zatím nevyvozuje, že Petr míří špatně. Zeptá se ho na něco jiného: "Co přesně tě vlastně baví na programování?"
Petr chvíli přemýšlí. "Když dostanu nějaký složitý problém a musím ho rozmotat. Přijít na to, jak to celé udělat. A pak vidět, že to opravdu funguje."
"A samotné psaní kódu? Syntaxe, implementace řádek po řádku? Je to právě tohle, o co nechceš přijít?"
"Asi ne úplně. Ale mám rád ten stav, kdy se do toho ponořím a několik hodin něco skutečně stavím."
Najednou se ukazuje, že věta "chci dál programovat" znamenala několik různých věcí. Petr má rád řešení složitých problémů, navrhování, soustředěnou práci i konkrétní výsledek, který po něm zůstane. A jistě, také programování. Jen není vůbec samozřejmé, že o všechny ty ostatní věci přijde, pokud bude méně psát kód. Některé může nacházet i v architektonické práci. Jiné mu mohou chybět výrazněji, než si dnes myslí.
Igor proto nezavírá ani jednu možnost. Pokud by Petr zjistil, že je pro něj nenahraditelná právě každodenní implementace, může dávat smysl prozkoumat jinou vyšší technickou roli, třeba některou podobu tech leada. Pokud ho ale nejvíc naplňuje rozmotávání problémů a návrh řešení, architektura může pořád stát za pokus. Rozhodnout to teď nejde. Petr si ji tedy nechává jako pracovní cíl, jen už ví, že si musí mnohem přesněji ověřit, co od ní čeká.
Tady bych tě na chvíli zastavil i já. Když říkáš, že tě na současné práci něco baví a nechceš o to při kariérním posunu přijít, co přesně tím myslíš? Samotnou činnost, nebo něco, co ti ta činnost umožňuje zažívat? U programování to může být vytváření kódu, soustředění, řešení problémů, navrhování nebo možnost vidět hmatatelný výsledek. To jsou příbuzné, ale různé potřeby.
Až budeš porovnávat další kariérní role, zkus se místo jejich názvů podívat na jejich běžný pracovní týden. Co bys pravděpodobně dělal více, co méně a čeho by ses musel vzdát? Tady ti žádný univerzální seznam kompetencí neodpoví. Důležitý je rozdíl mezi představou o roli a tím, jak by vypadala právě pro tebe.
Když máme security experta, proč to řeší architekt?
Petrův seznam přinesl další otázku, která se na první pohled zdá docela rozumná. U bezpečnosti se zarazí. "Ale vždyť na security máme ve firmě security experta. Tak jak to, že to má dělat architekt? Já rozhodně nechci být security expert."
Igor místo dalšího seznamu znalostí rozliší dvě věci: kdo má odbornou práci provést a kdo má v rozsahu své role zajistit, aby byla pro výslednou architekturu správně pokrytá. Security specialista může udělat analýzu, navrhnout opatření nebo upozornit na konkrétní hrozby. Architekt se nemusí stát bezpečnostním expertem, ale pokud za výslednou architekturu nese accountability, nemůže při návrhu přehlédnout oblast, která je pro celek zásadní.
"Nemusíš dělat práci security experta," vysvětluje Igor. "Ale pokud máš accountability za výslednou architekturu, musíš vědět, že security potřebuješ řešit, vědět koho přizvat, rozumět dostatečně tomu, co ti říká, a jeho vstup do návrhu skutečně dostat."
Petr si uvědomí, že si do pojmu architekt promítal představu člověka, který musí sám vědět nejvíc o všech důležitých technických oblastech. To by ale byl docela absurdní požadavek. Při návrhu většího systému přece mohou jednotlivým částem rozumět mnohem hlouběji lidé, kteří se na ně specializují. Architekt potřebuje poznat, kdy jejich znalosti potřebuje, porozumět důsledkům a zajistit, aby se jejich vstup neztratil při rozhodování o celku.
Platí to pro bezpečnost, ale podle konkrétního systému i pro provoz, databáze, infrastrukturu nebo další specializace. Petr si tak do své představy doplňuje důležitý rozdíl. Neznamená to ovšem, že každý člověk s titulem architekt automaticky nese stejnou accountability. Kde přesně hranice vede, musí později ověřit u konkrétní role a zaměstnavatele.
"Good enough". Dvě slova, která Petr moc nemusí
Když se při porovnávání modelů dostanou k rozhodování mezi variantami, Petr narazí na pojem "good enough". Igor ho používá ve smyslu vědomého kompromisu. Petr si pod tím ale okamžitě vybaví zkušenosti ze svého projektu. "Na 'good enough' jsem trochu alergický. U nás to často znamená, že to uděláme rychle, přidáme další bordel a někdy potom to opravíme. A to 'někdy' nikdy nepřijde."
Právě tady se rozhovor vrací k tomu, proč se Petr začal o architekturu vůbec zajímat. Chce, aby dlouhodobé technické problémy měly při rozhodování větší váhu. Igor jeho frustraci nezpochybňuje. Jen rozliší špatně pochopený kompromis od kompromisu, o kterém se dá rozhodnout vědomě.
"Good enough neznamená, že o problému nevíš. Naopak. Jako architekt bys měl umět říct: Tuhle variantu dokážeme dodat rychleji, ale bereme tím na sebe tato konkrétní rizika."
Petr dokáže snadno říct, že rychlejší varianta vytvoří technický dluh. Jenže co přesně ten dluh způsobí? Jaká změna bude později dražší? Co se může pokazit a jaký bude dopad? Jaká rizika jsou přijatelná kvůli současnému termínu a která by už přijatelná být neměla? To nejsou jen technické otázky. O některých důsledcích musí rozhodnout člověk, který odpovídá za produkt, termín nebo obchodní závazek.
"Ty nemusíš rozhodnout, že firma to riziko přijme," říká Igor. "Ale musíš zajistit, že člověk, který o tom rozhoduje, skutečně ví, co přijímá."
Petr si uvědomí, že vyšší technický vliv možná nevzniká jen tím, že člověk dostane titul a pravomoc říkat ostatním, co mají dělat. Někdy vzniká tím, že dokáže technický problém přeložit do konkrétních důsledků, podle kterých se firma vůbec může rozhodovat. Pokud někdo vědomě přijme riziko kvůli jinému cíli, nemusí to znamenat, že technickým argumentům nerozuměl. A pokud Petr nedokáže pojmenovat cenu kompromisu jinak než slovy "technický dluh", možná mu část podstatného argumentu zatím chybí.
Není to pro něj úplně pohodlné zjištění. Přišel s představou, že v architektonické roli bude mít konečně větší vliv na rozhodnutí, která ho dnes štvou. Teď zjišťuje, že část práce na tom vlivu může začít dělat už jako seniorní vývojář. A že ani jako architekt nemusí mít poslední slovo o tom, jaké byznysové riziko firma přijme.
Zkus si představit situaci, ve které jsi přesvědčený, že firma přehlíží technický problém. Co by o něm potřeboval vědět člověk, který nerozhoduje podle čistoty architektury, ale podle termínu, nákladů, zákaznických závazků a přijímaného rizika? A víš vůbec, kdo takové rozhodnutí může udělat?
Nejde o to vzdát se technického názoru nebo automaticky dát za pravdu managementu. Stejně tak nestačí předpokládat, že druhá strana problému nerozumí. Zkus oddělit samotný technický argument od rozhodnutí, pro které má být podkladem. Někdy zjistíš, že ho potřebuješ lépe vysvětlit. Jindy že skutečně narážíš na hranici své pravomoci. To jsou dvě různé situace a vyžadují různý další krok.
Fuj. Dokumentace.
Petrův domácí úkol obsahoval i jednu položku, kterou Igorův původní seznam tak výrazně nezdůrazňoval: dokumentaci důležitých architektonických rozhodnutí. Petr k ní měl stále stejnou spontánní reakci. "Fuj." Igor mu v tom neodporuje nějakým nadšeným proslovem o krásách dokumentace. Spíš vysvětlí, proč se na ni dnes dívá jinak než jen jako na administrativu.
Pokud se důležité rozhodnutí včetně svých důvodů udrží jen v hlavách několika lidí, začne být po čase obtížně použitelné. Nový kolega neví, proč některá omezení existují. Jiný tým se vrátí k variantě, která už se kdysi zavrhla, protože nezná důvod. A po půl roce někdo odstraní zdánlivě zbytečný kompromis, aniž by věděl, jaký problém původně řešil.
"Dnes může velkou část samotného zapisování a strukturování převzít AI, pokud si ten proces rozumně nastavíš," říká Igor. "Pro tebe je důležitější poznat, které rozhodnutí stojí za zachycení a jaký kontext u něj nesmí zmizet."
Petrovi se tím psaní dokumentace nestane oblíbenou aktivitou. Začne ale rozlišovat mezi nekonečným vytvářením dokumentů a odpovědností za to, aby se neztratilo důležité rozhodnutí. S jeho důvody, předpoklady a omezeními. A protože tento bod přinesl do rozhovoru právě Petr, doplní ho do společného pracovního modelu. Mentorův seznam není žádný answer key; i Petrův pohled ho může zpřesnit.
Jak pokračují, podobně zpřesní ještě několik oblastí, které Petr ve svém průzkumu tolik neřešil. Architekt nemusí řídit kapacitu celého týmu, ale měl by umět přispět k odhadu technické náročnosti různých variant. U některých změn se potřebuje dívat na výsledek celého feature nebo řešení, ne jen na jednotlivé řádky při code review. Musí umět zapojit specialisty, vést technické diskuse i v situaci, kdy sám preferuje jednu variantu, a chápat širší firemní kontext rozhodnutí. Čím více těchto témat projdou, tím méně Petr vnímá architekta jako člověka, který je prostě technicky o úroveň výš než seniorní vývojář.
Místo jedné definice má Petr pracovní model
Na konci setkání by šlo všechno zkrátit na několik hezkých slov: systémový pohled, komunikace, rozhodování, odpovědnost. Jenže s takovou definicí by Petr při dalším rozvoji zase velmi rychle narazil. Co si má vlastně představit pod "umět rozhodovat"? Jak pozná, že už "má systémový pohled"? A jak má porovnat současnou práci s rolí, jejíž požadavky zůstávají takhle obecné?
Petr s Igorem si proto nechají model podstatně konkrétnější. Je v něm 25 samostatných kompetencí a odpovědností, které později mohou posuzovat jednu po druhé. Například vidět důležité vazby napříč systémem; rozkládat velký problém ještě před implementací; porovnávat varianty včetně jejich nákladů, omezení a přijímaných rizik; přizvat správnou expertizu a integrovat ji do návrhu; umět technické důsledky vysvětlit člověku, který nese odpovědnost za obchodní rozhodnutí; vést diskusi a přitom naslouchat protinázorům; nebo zajistit, aby důležité rozhodnutí a jeho kontext nezmizely.
Tím ale Petr ještě nedostal odpověď na otázku, jestli se má stát architektem. Jeho seznam není univerzální definice. Ve skutečnosti zatím ani neví, jak by tuto roli jeho firma chtěla vymezit, kdo by v ní měl jaké rozhodovací pravomoci, kolik času by zabírala komunikace a jestli by mu skutečně dala možnost ovlivňovat věci, kvůli kterým o ní začal uvažovat. Všechny tyhle otázky si bude muset postupně ověřit v konkrétním prostředí.
Přesto se na konci setkání dívá na architekturu jinak než na začátku. Už to není jen vyšší technická role, ve které by mohl mít větší vliv. Je to možná práce, ve které stráví méně času psaním kódu, více času s lidmi a více energie přípravou rozhodnutí, za která ani nemusí mít konečnou odpovědnost. Některé části ho pořád lákají. Některé jsou mnohem méně příjemné, než očekával. A některé z jeho původních obav se ukázaly být složitější, než si myslel.
Nezískal jistotu, že vybral správný cíl. Získal něco, s čím se dá konečně pracovat: dostatečně konkrétní představu, kterou může porovnat se svou současnou realitou a podle nových informací dál měnit.
Kdyby sis z Petrova prvního kroku měl odnést jednu věc, nebyl by to seznam vlastností softwarového architekta. Ten může v jiné firmě vypadat jinak. Zajímavější je způsob, jakým vznikl: Petr se nejdřív pokusil svou cílovou roli popsat sám, mentor přinesl nezávislý pohled a oba hledali místa, kde se jejich představy rozcházejí. Ne proto, aby jeden vyhrál, ale aby Petr zjistil, které předpoklady stojí za ověření.
Možná si podobný pracovní model můžeš sestavit i pro roli, o které přemýšlíš. Nemusí být dokonalý a nemusíš v něm mít všechno správně. Potřebuješ ale něco konkrétnějšího než název pozice, abys mohl začít pokládat užitečné otázky: Co z toho dnes skutečně dělám? Kde mám zkušenost a kde jen představu? A co by pro mě znamenalo, kdyby se některý z těch předpokladů ukázal jako chybný?
Právě k tomu se Petr dostane dál. Když už dokáže alespoň pracovně popsat, kam chce jít, musí se podívat na mnohem méně pohodlnou část: kde proti tomuto cíli ve skutečnosti stojí dnes.