Petrova cesta k architektonické odpovědnosti

Petr uvažoval o architektuře, protože chtěl více ovlivňovat dlouhodobá technická rozhodnutí, zejména kolem technického dluhu. Při zkoumání role ale zjistil, že vliv nemusí znamenat poslední slovo. Může spočívat ve schopnosti vysvětlit náklady, rizika a důsledky technických variant lidem, kteří o nich rozhodují.

Zároveň mu došlo, že v takové roli může výrazně ubýt vlastního programování. Začal proto rozlišovat, jestli ho baví hlavně psaní kódu, nebo řešení složitých problémů. To druhé může nacházet i v jiné podobě práce.

Architekturu si proto zatím nechává jako možný směr. Než začne plánovat postup k nové roli, potřebuje si ověřit, jak bude její každodenní práce vypadat a jestli o ni skutečně stojí.

Petr s mentorem prošel několik schopností důležitých pro jeho představu role architekta. U práce s technickými kompromisy odhadl svou současnou úroveň přibližně na 2 z 5, zatímco pracovní cíl byl 4 z 5. Rozdíl ukázal, že je tu prostor k rozvoji, ale sám o sobě ještě neříkal, co přesně Petr potřebuje zvládnout jinak.

Petr například dokázal rozpoznat technický dluh. Když ale mentor použil situaci, ve které by čistší řešení trvalo šest týdnů, zatímco firma potřebuje výsledek za tři, Petr popisoval hlavně technické nevýhody rychlejší varianty. Pro člověka, který má rozhodnout, však nestačí vědět, že vznikne technický dluh. Potřebuje znát dostupné varianty, jejich přínosy, omezení a konkrétní rizika, která by danou volbou přijal.

Tady se ukázalo, v čem Petrova rozvojová mezera skutečně spočívá. Nešlo jen o obecné "zlepšit práci s kompromisy", ale o schopnost připravit rozhodnutí tak, aby byly přínosy a přijímaná rizika jednotlivých variant srozumitelné. Tato mezera existovala už před hodnocením, ale teprve její konkrétní pojmenování ukázalo, na čem může Petr skutečně pracovat.

Ne všechny důležité rozvojové oblasti má smysl řešit současně. Petr proto svých pět rozvojových cílů porovnal podle očekávané hodnoty, potřebné snahy a aktuální naléhavosti. Čísla mu měla zpřehlednit předpoklady, ne rozhodnout za něj.

Práce s technickými variantami, trade-offy a přijímaným rizikem mu vyšla stejně vysoko jako vysvětlování byznysového dopadu technických rozhodnutí (obě 1,00). U první oblasti šlo téměř o novou praktickou schopnost, u druhé o ještě větší rozvojovou mezeru, ale i vyšší očekávanou snahu.

Místo hledání umělého rozdílu v číslech si Petr vybral trade-offy, kterým se chtěl věnovat jako prvním. Druhou oblast vědomě nechal na později.

Právě to je smysl prioritizace. Ne vytvořit dokonale přesné pořadí, ale rozhodnout, čemu věnovat omezenou kapacitu teď. "Později" neznamená "nedůležité" a rozhodnutí se může při změně okolností znovu otevřít.

Petr si jako první rozvojovou prioritu zvolil práci s variantami, trade-offy a přijímaným rizikem. Jenže "zlepšit se v práci s trade-offy" není úkol, který může jednoduše začít plnit.

S mentorem proto cíl rozdělil na menší schopnosti a zaměřil se na jednu konkrétní oblast: umět pojmenovat přijímané riziko a jeho dopad. I tu ale potřeboval převést na něco vykonatelného.

Vznikl první úkol: vybrat jedno známé technické rozhodnutí, zpětně porovnat alespoň dvě možné varianty a u každé popsat přínosy, náklady, omezení, konkrétní rizika a jejich dopady.

V tomto okamžiku už nemusel pokračovat v rozepisování celého rozvojového cíle. Věděl, na čem začne, co má vytvořit a co si na prvním pokusu může ověřit. Výsledek přitom nemusel být napoprvé dobrý. Právě první pokus měl ukázat, co potřebuje zlepšit nebo rozdělit dál.

Takto vznikla použitelná roadmapa: aktuální rozvojový fokus, konkrétní další krok a ostatní cíle ponechané na později. Petr si ji každé ráno krátce připomínal a jednou týdně kontroloval, jestli jeho priority stále odpovídají aktuální situaci.

Když se následně objevila blížící se klientská schůzka, Petr přesunul pozornost na jinou oblast: vysvětlování byznysového přínosu a dopadu technického řešení. Tento cíl měl dosud na později, ale kvůli konkrétní blížící se potřebě získal vyšší naléhavost. Původní práce s trade-offy tím neztratila význam, jen se změnilo, čemu dávalo smysl věnovat pozornost právě teď.

Po schůzce dočasná naléhavost zmizela a oba cíle měly znovu stejné hodnocení. Petr se ale při týdenní kontrole rozhodl pokračovat ve vysvětlování byznysových dopadů. Tato oblast ho bavila a chtěl se jí dál věnovat. Nemusel kvůli tomu vymýšlet nové číslo ani umělý rozdíl mezi stejně hodnocenými cíli. Hodnocení priorit mu pomáhalo porovnávat možnosti, ale nerozhodovalo za něj.

Smyslem roadmapy tedy není naplánovat celý rozvoj dopředu ani vytvořit pevné pořadí úkolů. Má ti dát dostatečně konkrétní další krok, se kterým můžeš začít, a zároveň možnost vědomě změnit současný fokus, když se změní okolnosti nebo tvoje vlastní rozhodnutí.

Petr chtěl lépe vysvětlovat byznysové dopady technických rozhodnutí, a proto požádal manažera o účast na poradách vedení. Manažer to odmítl. Domluvili se ale na menším kroku: Petr dostane přibližně hodinu na přípravu podkladu ke skutečnému technickému rozhodnutí a pak ho spolu půl hodiny projdou. Manažer si ponechá odpovědnost za to, co z podkladu použije a co vedení představí.

Petr tak nezískal přístup na porady vedení ani novou roli. Získal ale příležitost zkoušet konkrétní schopnost na reálném úkolu, s reálným kontextem a možností zpětné vazby. Manažer přitom může získat užitečný podklad pro vlastní práci, ne jen věnovat čas Petrovu rozvoji.

Při hledání příležitostí k rozvoji proto nemusí být hlavní otázkou, jak získat celou novou odpovědnost. Často dává větší smysl zjistit, do které části takové práce se můžeš zapojit už dnes. Pokud takový prostor není dostupný, můžeš začít simulací, ale ta nenahradí skutečná pracovní omezení a důsledky rozhodování.

Petr se na svůj první pokus připravil tak dobře, jak v tu chvíli uměl. Věděl, že mu k obhajobě refactoringu nestačí tvrdit, že se starý kód špatně udržuje. Proto prošel historii změn, spočítal jejich pracnost, odhadl možné úspory a připravil doporučení, proč refactoring udělat právě teď.

Manažer jeho výpočty nezpochybnil. Upozornil ale na něco, s čím Petr nepočítal. Za šest týdnů má tým splnit důležitý závazek vůči významnému klientovi a refactoring by mohl spotřebovat rezervu potřebnou pro případné komplikace. Petr tedy připravil rozumné doporučení, ale bez informace, která mohla zásadně změnit rozhodnutí.

Právě v tom je hodnota prvního pokusu v praxi. Můžeš mít nastudovanou teorii, poctivě se připravit a udělat to nejlepší, co podle svých současných znalostí dokážeš. Teprve střet s reálnou situací ti ale může ukázat, co všechno jsi ještě nevzal v úvahu. Petrova analýza nemusela být chybná. Praxe mu ukázala, kde byla neúplná.

Po prvním doporučení Petr předpokládal, že o důležitém závazku vůči klientovi nemohl vědět, protože nechodí na schůzky vedení. Mentor se ho ale zeptal: "Jak víš, že ses k té informaci nemohl dostat?" Petr si uvědomil, že se před doporučením ani nezeptal, jak důležitý termín je a co by jeho nedodržení znamenalo. Zaměnil informaci, kterou neměl, za informaci, kterou nemohl získat.

Nemusíš mít přístup ke všem informacím vedení, abys mohl připravit dobré technické doporučení. Potřebuješ ale aktivně hledat kontext, který může změnit váhu technických argumentů. Něco se můžeš dozvědět z běžné firemní komunikace, na něco se můžeš zeptat manažera. A pokud důležitou informaci ani tak nezískáš, měl bys ji v doporučení označit jako nejistotu, ne předpokládat, že žádný další kontext neexistuje.

Petr proto nemění svůj rozvojový cíl, ale konkrétní další krok v roadmapě: před příštím doporučením aktivně zjistit kontext rozhodnutí a označit důležité informace, které mu chybí. Zpětná vazba tak nezůstává jen poznáním, ale promítá se do konkrétního kroku, který si Petr naplánoval pro další pokus.

Technické rozhodování nezačíná až porovnáváním implementačních variant. Důležité informace mohou zaznít už při představení samotného zadání a některé je potřeba aktivně zjistit.

Petr si při představení nové funkce pro hromadné importy tentokrát všímal i zákaznických potřeb, očekávaného objemu a možného budoucího rozšíření. Když později porovnával existující zpracování úloh na pozadí s novým event-driven řešením, uvědomil si, že neví, zda je širší využití u dalších zákazníků konkrétní plán, nebo zatím jen možnost.

Místo vlastního předpokladu se zeptal manažera. Teprve po ověření této informace připravil technické doporučení.

Rozdíl proti prvnímu pokusu tedy nebyl jen v kvalitě výsledného podkladu. Petr začal relevantní kontext aktivně vnímat už při zadání a chybějící informace hledal ještě před rozhodnutím. Právě tato změna v jeho postupu ukazuje, že se poučení z předchozí zkušenosti promítlo do skutečné práce.

Petrův rozvojový plán vycházel z rozumné představy cílové role. Jenže nové informace z jeho firmy ukázaly, že část této představy potřebuje zpřesnit.

Petrův manažer přinesl z diskuse s vedením novou informaci. Případná architektonická odpovědnost ve firmě by mohla zahrnovat také technickou spolupráci se zákazníky. Petr by tak potřeboval dokázat porozumět relevantní části cizího systému i bez přístupu ke zdrojovému kódu a bez možnosti prostudovat každý detail. Důležité by bylo rychle rozpoznat podstatné vazby a omezení, oddělit fakta od předpokladů a zjistit, které informace ještě chybí pro společné rozhodnutí.

Petr dobře zná vlastní produkt, ale to není totéž jako vytvořit si dostatečný pracovní model neznámého prostředí. Jeho původní představa cílové role nebyla chybná, jen tuto konkrétní potřebu nezachycovala dostatečně přesně.

Tím se změnil i pohled na jednu z jeho rozvojových mezer. Schopnost systémového uvažování v neznámém prostředí získala vyšší naléhavost a její orientační priorita se posunula z 0,33 na 0,83. To z ní automaticky nedělá nejvyšší prioritu, ale je to důvod znovu posoudit roadmapu.

Dalším krokem může být připravit před vhodnou diskusí se zákazníkem jednoduchý model relevantních systémů, jejich vazeb, omezení a otevřených otázek a po rozhovoru ho zpřesnit.

Podstatné je, že rozvojový plán nemusí být chybný, aby potřeboval změnu. Pokud nové informace změní některý z jeho důležitých předpokladů, je potřeba přehodnotit i rozhodnutí, která z něj vycházela.

V Petrově případě změna zasáhla až původní představu cílové role, a tím i rozvojovou mezeru, její prioritu a další kroky. Nemusí proto začínat od nuly ani přepisovat celý plán. Díky tomu, že na sebe jednotlivé části roadmapy navazují, může upravit právě ty závěry, kterých se nová informace týká.