Petr má prioritu. Jen pořád neví, co má zítra udělat.

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. Čísla, rozhovory a pracovní situace v tomto příkladu nejsou záznamem skutečné spolupráce.

Jeden cíl na papíře

Když se Petr po posledním setkání podíval do svých poznámek, měl konečně nějaké pořadí. Z pěti vybraných oblastí mu nejvýš vyšly dvě: práce s variantami, trade-offy a přijímaným rizikem a schopnost vysvětlit byznysový přínos technického řešení. Obě dostaly pracovní Prioritu 1,00. Petr se rozhodl začít tou první, protože ho k ní táhly problémy, které na projektu řešil už dlouho. Druhou vědomě odložil.

Bylo příjemné alespoň jednou neskončit u seznamu věcí, které by měl umět. Jenže hned při dalším pohledu na zápis narazil na otázku, kterou si při prioritizaci nepoložil. Jak vlastně vypadá úterní odpoledne člověka, který má jako svůj aktuální cíl "zlepšit práci s trade-offy"?

Na další schůzce ukázal Igorovi řádek ve svých poznámkách.

"Tak tohle mám teď jako prioritu. A přiznám se, že vůbec nevím, co si s tím mám napsat do tasků."

"Co bys udělal, kdybych ti řekl, že se tomu máš příští týden věnovat?"

"Asi bych si něco přečetl. Nebo počkal, až zase budeme řešit nějaké rozhodnutí."

"A podle čeho pak poznáš, že ses tomu opravdu věnoval?"

Petr se zarazil. Přečtený článek by dokázal odškrtnout. Ale ten přece ještě neznamená, že bude umět lépe připravovat rozhodnutí, u kterých se přijímá technické riziko. A čekání na vhodnou situaci v práci také není moc použitelný plán, zvlášť když si ji sám neumí přesně představit.

Igor proto vezme původní formulaci a zeptá se, co všechno Petr vlastně potřebuje umět, aby s variantami dokázal pracovat jinak než dnes. Petr nejprve začne mluvit o technickém dluhu. Že pozná problematické řešení, že ví, jak se budou některé části systému později komplikovaně měnit, a že ho štve, když se to při rozhodování bere na lehkou váhu.

"Tohle ale do velké míry umíš už teď," zastaví ho Igor. "Co ti chybí mezi větou 'tohle je špatné řešení' a podkladem, podle kterého se dá opravdu rozhodnout?"

Společně to rozdělí na čtyři menší oblasti. Petr musí umět najít relevantní varianty, porovnat jejich přínosy, náklady a omezení, konkrétně popsat rizika a jejich dopady a nakonec oddělit své technické doporučení od pravomoci člověka, který má přijmout výsledné riziko za firmu. Už samotný seznam zní použitelněji. Přesto se Petr nedokáže rozhodnout, kterou věcí začít.

"Co z toho ti dnes připadá nejslabší?" zeptá se Igor.

"Asi rizika. Varianty nějak vymyslím. Ale často skončím u toho, že řešení vytvoří technický dluh. Sám vím, co tím myslím, jen to pak neumím dostat do podoby, se kterou by někdo mimo vývoj mohl něco udělat."

Zúží tedy aktuální fokus ještě jednou: umět konkrétně pojmenovat přijímané riziko a jeho dopad.

"Dobře," řekne Petr. "Takže si mám nastudovat, jak se popisují rizika?"

"Možná zjistíš, že potřebuješ něco dostudovat. Ale nejdřív bych chtěl vidět, co už dokážeš udělat sám. Máš za sebou dost technických rozhodnutí. Vyber jedno, u kterého sis tehdy říkal, že děláme špatný kompromis."

"Takových bych našel několik."

"Stačí jedno. Nemusíme hned řešit celou historii projektu. Zkus se k němu vrátit a připravit aspoň dvě varianty. U každé napiš, co přináší, co stojí, jaká vytváří omezení, co konkrétně se může pokazit a jaké by to mělo důsledky. A taky co kvůli tomu může být později dražší nebo složitější."

Petr chvíli mlčí. V hlavě se mu okamžitě vybaví jedno starší rozhodnutí, u kterého by mohl začít, ale zároveň si uvědomí, že možná nebude znát všechny původní předpoklady. Neví ani, jestli tehdy opravdu existovaly právě dvě smysluplné varianty.

"Takže mám napsat něco, o čem možná ani nebudu mít všechny informace?"

"Ano. Ale nepředstírej, že je máš. Když něco nevíš, napiš to jako neznámou. Pro první pokus nemusíš sestavit rozhodovací podklad, který bychom mohli rovnou poslat vedení. Potřebujeme vidět, co už umíš rozebrat a kde se zasekneš."

"A co když to bude blbě?"

"Tak aspoň budeme mít první konkrétní verzi, nad kterou se dá přemýšlet. Kdybys tu schopnost už spolehlivě zvládal, nemuseli bychom ji teď rozvíjet."

Petr si poznamená úkol. Poprvé za několik setkání nemá v zápisu jen oblast, ve které by se chtěl jednou zlepšit. Má něco, co může opravdu otevřít a zkusit udělat, aniž by k tomu potřeboval nové pověření, novou pracovní roli nebo zvláštní projekt.

"A budeme to teď rozpadat ještě na další úkoly?" zeptá se Petr.

"Proč? Víš, co máš udělat?"

"Jo."

"Víš, na čem to můžeš zkusit?"

"Taky."

"Tak bych zatím skončil. Až to zkusíš, zjistíme, jestli ti chybí další znalost, menší krok nebo něco úplně jiného. Vymýšlet teď deset dalších úkolů by nám moc nepomohlo."

Když si napíšeš "zlepšit komunikaci", "naučit se rozhodovat" nebo třeba "být lepší v architektuře", máš pojmenovaný směr, ale ještě ne úkol. Neznamená to, že si musíš hned rozplánovat půl roku práce. Zkus se nejdřív zeptat, co konkrétně tvoří tu schopnost, kterou chceš rozvíjet. Kterou její část zatím nezvládáš? Na jaké známé situaci ji můžeš vyzkoušet? A co po prvním pokusu uvidíš, co dnes nevidíš?

Rozpad má smysl zastavit ve chvíli, kdy dokážeš začít. První výstup nemusí být správný ani kompletní. Potřebuješ ho umět posoudit, ne ho předem prohlásit za důkaz, že už schopnost ovládáš. Pokud ani nevíš, jak menší části pojmenovat, může být prvním úkolem právě zjištění, co by muselo platit, aby šel větší cíl splnit.

Teď to zkusí sám

Než schůzku ukončí, Igor se vrátí k druhé oblasti, kterou Petr při prioritizaci nechal na později: vysvětlování byznysového přínosu a dopadu technického řešení.

"Teď zkus rozpadnout tenhle cíl ty," navrhne Igor.

Petr zvedne oči od poznámek. "Ale ten jsme dali na později."

"A tam taky zůstane. Neříkám, že na něm máš od zítřka pracovat. Chci jen vědět, jestli dokážeš stejný postup použít i bez toho, že tě každou otázkou provedu."

Petr chvíli přemýšlí. Vzpomene si na produktové meetingy, při kterých bývá přizvaný jako technický člověk. Často začne vysvětlovat detail řešení, protože právě jemu dobře rozumí. Jenže nemusí vědět, co vlastně člověk na druhé straně potřebuje rozhodnout.

"Tak první věc je zjistit, komu to vysvětluju," řekne. "Vývojář bude potřebovat něco jiného než project manager nebo člověk z produktu. A taky musím vědět, kvůli jakému rozhodnutí se o tom vůbec bavíme."

"Co dál?"

"Vybrat z technických informací jen to, co je pro toho člověka relevantní. Popsat přínosy, náklady, omezení a rizika. A nezačít automaticky tím, jak funguje databáze, když potřebuje rozhodnout o termínu."

Postupně z toho vznikne pět menších částí:

1. Rozpoznat adresáta a rozhodnutí, které má informace podpořit.
2. Pochopit, co je pro tohoto člověka a toto rozhodnutí relevantní.
3. Přeložit technické řešení do přínosů, nákladů, omezení a rizik.
4. Zvolit potřebnou úroveň technického detailu.
5. Začít relevantním dopadem a detail doplnit, až když je potřeba.

Petr se u třetího bodu zastaví. "Jenže 'přeložit řešení do přínosů a rizik' je pořád dost široké. To bych asi taky měl rozpadnout."

Igor tentokrát nic nenavrhuje. Počká, až Petr sám otevře poznámky a doplní si otázky: Co tím produkt získá? Co to bude stát teď a co to může ušetřit později? Jaké omezení tím vznikne? Co se stane, když změnu neuděláme? Jaké riziko se snižuje nebo přijímá? A má na základě té informace vůbec někdo něco rozhodnout?

"Moment," zarazí se Petr, "vždyť popis rizika a dopadu už řešíme u trade-offů."

"A musíš to mít jako dvě různé schopnosti jen proto, že ses k tomu dostal ze dvou různých cílů?"

Petr zakroutí hlavou. Začne mu docházet, že rozvojové cíle nejsou oddělené šuplíky. Stejná dílčí schopnost se může projevit při návrhu variant i při jejich vysvětlování někomu, kdo odpovídá za termín nebo rozpočet. Jedna poctivě odvedená práce tedy může dávat smysl z více důvodů. To však ještě neznamená, že musí obě velké oblasti aktivovat současně.

"Takže tomu druhému cíli necháme poznámky, ale aktivní pořád nebude."

"Přesně. Umět něco rozdělit na menší části a rozhodnout se na tom právě teď pracovat jsou dvě různé věci."

Roadmapa, která nepotřebuje vlastního projektového manažera

Petr si při slově roadmapa nejdřív vybaví dokument, ve kterém se plánuje práce na celé čtvrtletí. Milníky, závislosti, odhady, termíny. Kdyby měl podobným způsobem zpracovat všech pět rozvojových oblastí, potřeboval by na to další volný večer. Možná několik.

Igor ale od jeho roadmapy očekává něco jednoduššího. Petr se na ni má podívat a během chvíle poznat, na co se teď soustředí, co může počkat a jaký je jeho další konkrétní krok. Nemusí u každé kompetence rozepisovat všechny možné budoucí aktivity.

Petr proto sestaví pracovní přehled. Na vrcholu je stále jeho směr k architektonické nebo širší technické odpovědnosti. Pod ním jsou prioritizované oblasti. Jen jedna je aktivní a jen u ní má zřetelně označený další krok. Rozpad druhé oblasti v poznámkách zůstává, ale zatím nepředstírá, že jde o aktuální práci.

textSMĚR: SW architekt / vyšší technická odpovědnost

TEĎ
  Varianty, trade-offy a přijímané riziko [Priorita 1,00]
    - Najít relevantní varianty
    - Porovnat přínosy, náklady a omezení
    - AKTUÁLNÍ FOKUS: Konkrétní rizika a jejich dopady
        -> DALŠÍ KROK [ ] Rozebrat jedno známé minulé
           technické rozhodnutí přes alespoň dvě varianty;
           u každé uvést přínosy, náklady, omezení,
           rizika, jejich dopady a pozdější náklady
    - Rozlišit technické doporučení od přijetí rizika

POZDĚJI
  Byznysový přínos a dopad technického řešení [1,00]
    - Adresát, jeho rozhodnutí a potřebný kontext
    - Přínosy, náklady, omezení, rizika
    - Odpovídající úroveň technického detailu
  Rozklad většího problému před implementací [0,80]
  Facilitace technické diskuse [0,50]
  Systémový pohled v neznámém prostředí [0,33]

"Tohle je všechno?" zeptá se Petr, když se na přehled podívá.

"Co ti tam chybí k tomu, abys věděl, co udělat jako další?"

"Vlastně nic. Jen mi to přijde až moc jednoduché."

"Tak je to možná dost jednoduché na to, abys to skutečně používal."

Igor mu ukáže, že u jednotlivých kroků si vystačí s obyčejným označením: [ ] je otevřený úkol, [x] dokončený a -> aktuální další krok. Žádný nástroj za něj nerozhodne, jestli má správně nastavený cíl, ale nemusí kvůli tomu stavět vlastní systém. Stačí seznam, tabulka nebo aplikace, ke které se opravdu vrací.

"A co když se v práci objeví něco, co je důležitější než tenhle úkol?" zeptá se Petr.

"Pak se na roadmapu podíváš znovu. Neděláme z ní závazek, že budeš ignorovat všechno, co přijde. Ale budeš potřebovat vědět, proč se fokus mění."

Domluví se proto na dvou jednoduchých kontrolách. Každé pracovní ráno se Petr na chvíli podívá, co je jeho aktuální rozvojová priorita a jestli se během dne nabízí situace, ve které ji může vědomě použít. Jednou týdně si pak udělá krátkou retrospektivu: co se posunulo, jestli současný fokus pořád dává smysl a zda se nezměnily okolnosti, kvůli kterým by měl pořadí přehodnotit.

Petr si nastaví ranní připomínku. Je to drobnost, ale právě takové věci se mu v běžném pracovním provozu vytrácejí. Vlastní úkoly, konzultace a meetingy mu bez problémů vyplní den. Na další profesní růst si čas nevyhradí jen tím, že ho má napsaný v dokumentu.

Schůzka, která neměla být o Petrově rozvoji

O několik dní později za Petrem přijde jeho nadřízený. Blíží se schůzka s klientem, na které se bude probírat technické řešení plánované implementace. Přijde i CEO klienta. Podle manažera technickým souvislostem poměrně dobře rozumí, ale sám vývojářem nikdy nebyl. Nejde mu o to rozebrat implementaci do posledního detailu. Potřebuje mít rozumnou jistotu, že firma ví, co navrhuje, proč a s jakými důsledky.

Petr si zpočátku vybaví hlavně technické otázky, které by u takového řešení mohl dostat. Pak mu dojde, že přesně na podobný moment naráželi při mentoringu. On sám má sklon považovat netechnickou část diskuse za něco, co se ho týká až ve chvíli, kdy někdo potřebuje vysvětlit detail implementace. Jenže tentokrát se po něm může chtít něco jiného: pomoct druhé straně pochopit, co navrhovaná varianta znamená pro její cíl.

Otevře roadmapu. Aktivní má stále práci s trade-offy, Prioritu 1,00. Hned pod ní však vidí druhý, dosud odložený cíl: vysvětlování byznysového přínosu a dopadu technického řešení. Také 1,00.

Doteď žádný z nich neměl konkrétní časový tlak zvenčí. Teď je tu skutečná klientská schůzka, na kterou se musí připravit. Petr tedy nezkouší hledat novou matematiku ani nepřepisuje zpětně hodnotu celé kompetence. U druhého cíle upraví jen jednu věc: Naléhavost.

textPriorita = Naléhavost + (Hodnota / Snaha)

BYZNYSOVÝ DOPAD PŘED SCHŮZKOU
  Naléhavost 0   + (3,5 / 3,5) = 1,00

BYZNYSOVÝ DOPAD KVŮLI SCHŮZCE
  Naléhavost 0,5 + (3,5 / 3,5) = 1,50

TRADE-OFFY
  Naléhavost 0   + (3 / 3)     = 1,00

Petr přesune vysvětlování byznysového dopadu do sekce TEĎ a trade-offy do POZDĚJI. Nevymazal svůj původní úkol ani nezjistil, že měl před týdnem špatné priority. Změnily se okolnosti. Právě pro ně si v modelu nechali Naléhavost oddělenou od Hodnoty a Snahy.

Zároveň si všimne, že původní práce s riziky neztratila smysl. Konkrétně popsat, co jedna technická varianta přinese, co stojí a jaké riziko s sebou nese, je užitečné i pro člověka, který nechce řešit její implementační detaily. Obě rozvojové oblasti se překrývají, jen Petr tentokrát potřebuje dávat větší pozor na to, co z těch informací je podstatné pro klienta.

Možná máš ve své roadmapě něco, čemu ses chtěl věnovat tento měsíc, a pak přijde situace, ve které se najednou hodí jiná schopnost. To ještě neznamená, že jsi udělal chybu při původní prioritizaci. Zeptej se, co se opravdu změnilo. Je to hodnota schopnosti? Kapacita potřebná k jejímu rozvoji? Nebo jen konkrétní termín a potřeba člověka, se kterým právě pracuješ?

Když se ti změní naléhavost, může dávat smysl na chvíli přepnout fokus. Ale nepleť si změnu priority s pokrokem ve schopnosti. To, že Petr dostal příležitost vysvětlit technické řešení klientovi, samo o sobě nic nedokazuje o tom, jak dobře to zvládl. Zatím jen ví, čemu má v nejbližší době věnovat pozornost.

A co když se termín zase uvolní?

V den schůzky Petr ráno otevře svou roadmapu. Připomínka mu ukáže aktuální fokus a on se při přípravě vrátí k otázce, která mu ještě nedávno připadala nezajímavá: Co vlastně člověk na druhé straně potřebuje vědět, aby si mohl udělat rozumný názor na navrhované řešení?

Nechce začít automaticky technickým detailem, kterému sám nejlépe rozumí. V poznámkách si proto zvýrazní přínosy, náklady, omezení a rizika, které pro klienta mohou být relevantní, a věci, u kterých potřebuje další kontext. Všechno to má původ v obyčejné ranní kontrole seznamu. Bez ní by se Petr pravděpodobně soustředil na přípravu řešení jako na další technickou schůzku. Teď si alespoň vědomě připomněl, že si na ní chce zkusit jiný způsob uvažování.

Schůzka proběhne. Petr z ní nedělá důkaz, že už umí vysvětlovat byznysový dopad na úrovni architekta. K tomu by potřeboval rozumět tomu, jak jeho vstupy druhá strana použila, co fungovalo a co bude muset příště změnit. To zatím v poznámkách nemá. Ví ale, že se během přípravy dokázal zaměřit na něco, co dříve často přehlížel.

Na konci týdne otevře roadmapu při své krátké retrospektivě. Termín, kvůli kterému přepnul fokus, už uplynul. Žádný další konkrétní důvod držet navýšenou Naléhavost nemá, a proto ji vrátí z 0,5 na 0. Priorita byznysového dopadu se tím změní zpět z 1,50 na 1,00. Trade-offy zůstaly celou dobu na 1,00.

Petr se zarazí. Minule se při shodě rozhodl pro trade-offy. Měl by se tedy automaticky vrátit k původnímu plánu?

Překvapí ho, že se mu vlastně nechce. Při přípravě na klientskou schůzku zjistil, že když se byznysový kontext netváří jako cizí část meetingu, ale jako otázka, proč se má vůbec nějaké technické řešení udělat, začíná ho zajímat. Pořád je to schopnost, u které mu bude spousta věcí nepohodlných. Jen teď má chuť jí ještě nějakou dobu věnovat pozornost.

Na dalším setkání to Igorovi popíše.

"Naléhavost jsem vrátil zpátky na nulu, takže mi zase obojí vychází na jedničku," řekne Petr. "Ale nechal bych jako hlavní fokus ten byznysový dopad. Aspoň zatím."

"Proč?"

"Mám pocit, že jsem se kolem toho doteď spíš snažil proplout. Teď mi přijde zajímavé zjistit, jestli tomu dokážu opravdu rozumět. Nejen vysvětlit technické řešení, když se někdo zeptá."

"Tak si to tam nech. Při shodě nepotřebujeme předstírat, že vzorec rozhodne i za tebe. Hlavně ať víš, proč sis vybral právě tohle."

Petr tedy nevymýšlí žádný dodatečný bonus, kterým by si nové pořadí matematicky obhájil. Aktuální roadmapa jednoduše říká:

Ostatní tři cíle zůstávají také v sekci POZDĚJI, beze změny svých pracovních priorit. Petrovi nezmizí původní motivace řešit technický dluh. A práce s trade-offy se mu může hodit i při rozvíjení nového fokusu. Jen už nepotřebuje mít každou relevantní oblast vedenou jako aktivní úkol.

Všimni si, že Petr tady udělal dvě různá rozhodnutí. Nejdřív přepnul fokus, protože přišel konkrétní termín a požadavek z práce. Potom naléhavost zase snížil, protože ten důvod pominul. To jsou změny okolností. Až pak se rozhodl u stejného cíle zůstat, protože mu při aktuálně shodném hodnocení dávalo smysl pokračovat. Ani jedna z těch věcí ještě není důkazem, že se v dané schopnosti zlepšil.

Dobrá rozvojová roadmapa není seznam, který musíš za každou cenu dodržet, ani systém, ve kterém přepočítáváš každé rozhodnutí do třetího desetinného místa. Má ti umožnit poznat, co děláš teď, proč právě to a podle čeho by ses rozhodl jinak. Někdy se změní termín. Jindy teprve zjistíš, co ti šlo a nešlo při skutečném pokusu. To je jiný důvod k úpravě a měl bys ho umět odlišit.

Další otázka není v tabulce

Na začátku Petr nevěděl, co s abstraktní prioritou vůbec udělat. Teď dokáže velkou kompetenci rozložit, vybrat z ní malý vykonatelný krok, sestavit přehled, který má smysl otevírat, a upravit jej, když do práce vstoupí skutečný termín. Naučil se s roadmapou pracovat. Z toho ale ještě neplyne, že ovládl kompetence, které v ní má napsané.

U své současné priority má navíc další problém. Chce lépe vysvětlovat technická rozhodnutí lidem, kteří nesledují implementační detaily. K tomu už mu nebude stačit o těch situacích jen přemýšlet nebo si je rozepisovat v dokumentu.

Potřebuje příležitost, ve které to opravdu zkusí. A ideálně takovou, kde bude moct vidět, co jeho vysvětlení druhému člověku poskytlo a co mu naopak chybělo.

Otázka tedy přestává být "co mám v roadmapě". Začíná být mnohem praktičtější: Kde na to v běžné práci vezmu prostor, když tu odpovědnost ještě nemám?