Petr má prioritu. Len stále nevie, čo má zajtra urobiť.

Petr Konečný je fiktívna postava. Jeho príbeh je ilustračný scenár mentoringu, nie skúsenosť skutočného klienta ani preukázaný výsledok mentoringu. Čísla, rozhovory a pracovné situácie v tomto príklade nie sú záznamom skutočnej spolupráce.

Jeden cieľ na papieri

Keď sa Petr po poslednom stretnutí pozrel do svojich poznámok, konečne mal aspoň nejaké poradie. Z piatich vybraných oblastí mu najvyššie vyšli dve: práca s variantmi, trade-offmi a prijímaným rizikom a schopnosť vysvetliť biznisový prínos technického riešenia. Obe dostali pracovnú Prioritu 1,00. Petr sa rozhodol začať prvou, pretože ho k nej ťahali problémy, ktoré na projekte riešil už dlho. Druhú vedome odložil.

Bolo príjemné aspoň raz neskončiť len pri zozname vecí, ktoré by mal vedieť. Lenže hneď pri ďalšom pohľade na poznámky narazil na otázku, ktorú si pri určovaní priorít nepoložil. Ako vlastne vyzerá utorkové popoludnie človeka, ktorého aktuálnym cieľom je "zlepšiť prácu s trade-offmi"?

Na ďalšom stretnutí ukázal Igorovi jeden riadok vo svojich poznámkach.

"Tak toto mám teraz ako prioritu. A priznám sa, že vôbec neviem, aké tasky si k tomu mám napísať."

"Čo by si urobil, keby som ti povedal, že sa tomu máš budúci týždeň venovať?"

"Asi by som si niečo prečítal. Alebo počkal, kým budeme zase riešiť nejaké rozhodnutie."

"A podľa čoho potom spoznáš, že si sa tomu naozaj venoval?"

Petr sa zarazil. Prečítaný článok by si vedel odškrtnúť. Lenže to ešte neznamená, že bude vedieť lepšie pripravovať rozhodnutia, pri ktorých sa prijíma technické riziko. A čakať na vhodnú situáciu v práci tiež nie je veľmi použiteľný plán, najmä keď si ju sám nevie presne predstaviť.

Igor sa preto vrátil k pôvodnej formulácii a spýtal sa, čo všetko Petr vlastne potrebuje vedieť, aby dokázal s variantmi pracovať inak ako dnes. Petr najprv začal hovoriť o technickom dlhu. O tom, že dokáže rozpoznať problematické riešenie, že vie, ako sa niektoré časti systému budú neskôr komplikovane meniť, a že ho štve, keď sa to pri rozhodovaní berie na ľahkú váhu.

"Toto ale už do veľkej miery zvládaš," zastavil ho Igor. "Čo ti chýba medzi vetou 'toto je zlé riešenie' a podkladom, na základe ktorého sa dá naozaj rozhodnúť?"

Spoločne to rozdelili na štyri menšie oblasti. Petr musí vedieť nájsť relevantné varianty, porovnať ich prínosy, náklady a obmedzenia, konkrétne opísať riziká a ich dopady a napokon oddeliť svoje technické odporúčanie od právomoci človeka, ktorý má prijať výsledné riziko za firmu. Už samotný zoznam znel použiteľnejšie. Napriek tomu sa Petr nevedel rozhodnúť, čím začať.

"Čo z toho ti dnes pripadá najslabšie?" spýtal sa Igor.

"Asi riziká. Varianty nejako vymyslím. Ale často skončím pri tom, že riešenie vytvorí technický dlh. Sám viem, čo tým myslím, len to potom neviem dostať do podoby, s ktorou by niekto mimo vývoja dokázal niečo urobiť."

Aktuálne zameranie teda zúžili ešte raz: vedieť konkrétne pomenovať prijímané riziko a jeho dopad.

"Dobre," povedal Petr. "Takže si mám naštudovať, ako sa opisujú riziká?"

"Možno zistíš, že si potrebuješ niečo doštudovať. Ale najprv by som chcel vidieť, čo už dokážeš urobiť sám. Máš za sebou dosť technických rozhodnutí. Vyber jedno, pri ktorom si si vtedy hovoril, že robíme zlý kompromis."

"Takých by som našiel niekoľko."

"Stačí jedno. Nemusíme hneď riešiť celú históriu projektu. Skús sa k nemu vrátiť a pripraviť aspoň dva varianty. Pri každom napíš, čo prináša, čo stojí, aké vytvára obmedzenia, čo konkrétne sa môže pokaziť a aké by to malo dôsledky. A tiež čo kvôli tomu môže byť neskôr drahšie alebo komplikovanejšie."

Petr chvíľu mlčal. Okamžite mu napadlo jedno staršie rozhodnutie, na ktorom by mohol začať, ale zároveň si uvedomil, že možno nebude poznať všetky pôvodné predpoklady. Ani nevedel, či vtedy skutočne existovali práve dva zmysluplné varianty.

"Takže mám napísať niečo, o čom možno ani nebudem mať všetky informácie?"

"Áno. Ale netvár sa, že ich máš. Keď niečo nevieš, označ to ako neznámu. Pri prvom pokuse nemusíš pripraviť rozhodovací podklad, ktorý by sme mohli rovno poslať vedeniu. Potrebujeme vidieť, čo už dokážeš rozobrať a kde sa zasekneš."

"A čo keď to bude zle?"

"Tak budeme mať aspoň prvú konkrétnu verziu, nad ktorou sa dá premýšľať. Keby si tú schopnosť už spoľahlivo ovládal, nemuseli by sme ju teraz rozvíjať."

Petr si zapísal úlohu. Prvýkrát po niekoľkých stretnutiach nemal v poznámkach len oblasť, v ktorej by sa chcel raz zlepšiť. Mal niečo, čo mohol naozaj otvoriť a skúsiť urobiť bez toho, aby potreboval nové poverenie, novú pracovnú rolu alebo špeciálny projekt.

"A budeme to teraz rozdeľovať ešte na ďalšie úlohy?" spýtal sa Petr.

"Prečo? Vieš, čo máš urobiť?"

"Áno."

"Vieš, na čom si to môžeš vyskúšať?"

"Aj to."

"Tak by som zatiaľ skončil. Keď to skúsiš, zistíme, či ti chýbajú ďalšie vedomosti, menší krok alebo niečo úplne iné. Vymýšľať teraz ďalších desať úloh by nám veľmi nepomohlo."

Keď si napíšeš "zlepšiť komunikáciu", "naučiť sa rozhodovať" alebo napríklad "byť lepší v architektúre", pomenoval si smer, ale ešte nemáš úlohu. Neznamená to, že si musíš hneď naplánovať pol roka práce. Skús sa najprv opýtať, čo konkrétne tvorí schopnosť, ktorú chceš rozvíjať. Ktorú jej časť zatiaľ nezvládaš? Na akej známej situácii si ju môžeš vyskúšať? A čo po prvom pokuse uvidíš, čo dnes ešte nevidíš?

Rozdeľovanie má zmysel zastaviť vo chvíli, keď dokážeš začať. Prvý výstup nemusí byť správny ani kompletný. Potrebuješ ho vedieť posúdiť, nie ho vopred vyhlásiť za dôkaz, že už danú schopnosť ovládaš. Ak ani nevieš, ako pomenovať menšie časti, prvou úlohou môže byť práve zistenie, čo by muselo platiť, aby sa väčší cieľ dal splniť.

Teraz to skúsi sám

Pred koncom stretnutia sa Igor vrátil k druhej oblasti, ktorú Petr pri určovaní priorít nechal na neskôr: vysvetľovanie biznisového prínosu a dopadu technického riešenia.

"Teraz skús tento cieľ rozložiť ty," navrhol Igor.

Petr zdvihol oči od poznámok. "Ale ten sme dali na neskôr."

"A tam aj zostane. Nehovorím, že na ňom máš od zajtra pracovať. Chcem len vedieť, či dokážeš rovnaký postup použiť aj bez toho, aby som ťa previedol každou otázkou."

Petr sa na chvíľu zamyslel. Spomenul si na produktové meetingy, na ktoré ho pozývali ako technického človeka. Často začal vysvetľovať detaily riešenia, pretože práve tým dobre rozumel. Lenže nemusel vedieť, o čom vlastne potrebuje človek na druhej strane rozhodnúť.

"Tak prvá vec je zistiť, komu to vysvetľujem," povedal. "Vývojár bude potrebovať niečo iné ako projektový manažér alebo človek z produktu. A tiež musím vedieť, kvôli akému rozhodnutiu sa o tom vôbec rozprávame."

"Čo ďalej?"

"Vybrať z technických informácií len to, čo je pre daného človeka relevantné. Opísať prínosy, náklady, obmedzenia a riziká. A nezačať automaticky tým, ako funguje databáza, keď potrebuje rozhodnúť o termíne."

Postupne z toho vzniklo päť menších častí:

1. Rozpoznať adresáta a rozhodnutie, ktoré majú informácie podporiť.
2. Pochopiť, čo je pre tohto človeka a dané rozhodnutie relevantné.
3. Preložiť technické riešenie do prínosov, nákladov, obmedzení a rizík.
4. Zvoliť potrebnú úroveň technického detailu.
5. Začať relevantným dopadom a detaily doplniť až vtedy, keď sú potrebné.

Petr sa zastavil pri treťom bode. "Lenže 'preložiť riešenie do prínosov a rizík' je stále dosť široké. To by som asi mal tiež rozložiť."

Igor tentoraz nič nenavrhol. Počkal, kým si Petr sám otvoril poznámky a doplnil otázky: Čo tým produkt získa? Čo to bude stáť teraz a čo to môže ušetriť neskôr? Aké obmedzenie tým vznikne? Čo sa stane, ak zmenu neurobíme? Aké riziko sa znižuje alebo prijíma? A potrebuje na základe tejto informácie vôbec niekto o niečom rozhodnúť?

"Moment," zarazil sa Petr, "veď opis rizika a dopadu už riešime pri trade-offoch."

"A musíš to mať ako dve rôzne schopnosti len preto, že si sa k tomu dostal z dvoch rôznych cieľov?"

Petr pokrútil hlavou. Začínalo mu dochádzať, že rozvojové ciele nie sú oddelené zásuvky. Rovnaká čiastková schopnosť sa môže prejaviť pri navrhovaní variantov aj pri ich vysvetľovaní niekomu, kto zodpovedá za termín alebo rozpočet. Jedna poctivo odvedená práca teda môže mať zmysel z viacerých dôvodov. To však ešte neznamená, že musí obe veľké oblasti aktivovať súčasne.

"Takže pri druhom cieli necháme poznámky, ale stále nebude aktívny."

"Presne. Vedieť niečo rozdeliť na menšie časti a rozhodnúť sa na tom práve teraz pracovať sú dve rôzne veci."

Roadmapa, ktorá nepotrebuje vlastného projektového manažéra

Keď Petr počul slovo roadmapa, najprv si predstavil dokument, v ktorom sa plánuje práca na celý štvrťrok. Míľniky, závislosti, odhady, termíny. Keby mal podobným spôsobom spracovať všetkých päť rozvojových oblastí, potreboval by na to ďalší voľný večer. Možno aj niekoľko.

Igor však od jeho roadmapy očakával niečo jednoduchšie. Petr by sa na ňu mal pozrieť a za chvíľu vedieť, na čo sa teraz sústreďuje, čo môže počkať a aký je jeho ďalší konkrétny krok. Nemusel pri každej kompetencii rozpisovať všetky možné budúce aktivity.

Petr si preto zostavil pracovný prehľad. Na vrchole stále zostával jeho smer k softvérovému architektovi alebo širšej technickej zodpovednosti. Pod ním boli oblasti zoradené podľa priorít. Aktívna bola len jedna a len pri nej mal jasne označený ďalší krok. Rozdelenie druhej oblasti mu zostalo v poznámkach, ale zatiaľ sa netváril, že ide o aktuálnu prácu.

textSMER: SW architekt / vyššia technická zodpovednosť

TERAZ
  Varianty, trade-offy a prijímané riziko [Priorita 1,00]
    - Nájsť relevantné varianty
    - Porovnať prínosy, náklady a obmedzenia
    - AKTUÁLNE ZAMERANIE: Konkrétne riziká a ich dopady
        -> ĎALŠÍ KROK [ ] Rozobrať jedno známe minulé
           technické rozhodnutie cez aspoň dva varianty;
           pri každom uviesť prínosy, náklady, obmedzenia,
           riziká, ich dopady a neskoršie náklady
    - Odlíšiť technické odporúčanie od prijatia rizika

NESKÔR
  Biznisový prínos a dopad technického riešenia [1,00]
    - Adresát, jeho rozhodnutie a potrebný kontext
    - Prínosy, náklady, obmedzenia, riziká
    - Zodpovedajúca úroveň technického detailu
  Rozklad väčšieho problému pred implementáciou [0,80]
  Facilitácia technickej diskusie [0,50]
  Systémový pohľad v neznámom prostredí [0,33]

"To je všetko?" spýtal sa Petr, keď sa pozrel na prehľad.

"Čo ti tam chýba, aby si vedel, čo máš urobiť ako ďalšie?"

"Vlastne nič. Len mi to pripadá až príliš jednoduché."

"Tak je to možno dosť jednoduché na to, aby si to naozaj používal."

Igor mu ukázal, že pri jednotlivých krokoch si vystačí s obyčajným označením: [ ] je otvorená úloha, [x] dokončená a -> aktuálny ďalší krok. Žiadny nástroj zaňho nerozhodne, či má správne nastavený cieľ, ale nemusí si kvôli tomu vytvárať vlastný systém. Stačí zoznam, tabuľka alebo aplikácia, ku ktorej sa naozaj vracia.

"A čo keď sa v práci objaví niečo dôležitejšie ako táto úloha?" spýtal sa Petr.

"Potom sa na roadmapu pozrieš znova. Nerobíme z nej záväzok, že budeš ignorovať všetko, čo príde. Ale budeš potrebovať vedieť, prečo sa tvoje zameranie mení."

Dohodli sa preto na dvoch jednoduchých kontrolách. Každé pracovné ráno sa Petr na chvíľu pozrie, aká je jeho aktuálna rozvojová priorita a či sa počas dňa ponúka situácia, v ktorej ju môže vedome využiť. Raz týždenne si potom urobí krátku retrospektívu: čo sa posunulo, či súčasné zameranie stále dáva zmysel a či sa nezmenili okolnosti, kvôli ktorým by mal poradie prehodnotiť.

Petr si nastavil rannú pripomienku. Bola to drobnosť, ale práve takéto veci sa mu v bežnej pracovnej prevádzke strácali z pozornosti. Vlastné úlohy, konzultácie a meetingy mu bez problémov zaplnili deň. Na ďalší profesijný rast si čas nevyhradí len tým, že ho má napísaný v dokumente.

Stretnutie, ktoré nemalo byť o Petrovom rozvoji

O niekoľko dní neskôr prišiel za Petrom jeho nadriadený. Blížilo sa stretnutie s klientom, na ktorom sa malo preberať technické riešenie plánovanej implementácie. Mal prísť aj CEO klienta. Podľa manažéra technickým súvislostiam celkom dobre rozumel, ale sám nikdy nebol vývojárom. Nešlo mu o to rozobrať implementáciu do posledného detailu. Potreboval mať rozumnú istotu, že firma vie, čo navrhuje, prečo to navrhuje a aké to bude mať dôsledky.

Petr si spočiatku predstavoval najmä technické otázky, ktoré by k takému riešeniu mohol dostať. Potom mu došlo, že presne na podobný moment narazili pri mentoringu. Sám mal sklon považovať netechnickú časť diskusie za niečo, čo sa ho týka až vo chvíli, keď niekto potrebuje vysvetliť detail implementácie. Lenže tentoraz sa od neho mohlo očakávať niečo iné: pomôcť druhej strane pochopiť, čo navrhovaný variant znamená pre jej cieľ.

Otvoril roadmapu. Aktívnu mal stále prácu s trade-offmi, s Prioritou 1,00. Hneď pod ňou však videl druhý, doteraz odložený cieľ: vysvetľovanie biznisového prínosu a dopadu technického riešenia. Tiež 1,00.

Doteraz ani jeden z nich nemal konkrétny časový tlak zvonka. Teraz tu bolo skutočné stretnutie s klientom, na ktoré sa musel pripraviť. Petr sa preto nepokúšal vymýšľať novú matematiku ani spätne prepisovať hodnotu celej kompetencie. Pri druhom cieli upravil len jednu vec: Naliehavosť.

textPriorita = Naliehavosť + (Hodnota / Úsilie)

BIZNISOVÝ DOPAD PRED STRETNUTÍM
  Naliehavosť 0   + (3,5 / 3,5) = 1,00

BIZNISOVÝ DOPAD KVÔLI STRETNUTIU
  Naliehavosť 0,5 + (3,5 / 3,5) = 1,50

TRADE-OFFY
  Naliehavosť 0   + (3 / 3)     = 1,00

Petr presunul vysvetľovanie biznisového dopadu do sekcie TERAZ a trade-offy do NESKÔR. Nevymazal svoju pôvodnú úlohu ani nezistil, že mal pred týždňom nesprávne priority. Zmenili sa okolnosti. Práve preto mali v modeli Naliehavosť oddelenú od Hodnoty a Úsilia.

Zároveň si všimol, že pôvodná práca s rizikami nestratila zmysel. Konkrétne opísať, čo jeden technický variant prinesie, čo stojí a aké riziko so sebou nesie, je užitočné aj pre človeka, ktorý nechce riešiť implementačné detaily. Obe rozvojové oblasti sa prekrývali, len Petr tentoraz potreboval venovať väčšiu pozornosť tomu, ktoré informácie sú pre klienta podstatné.

Možno máš vo svojej roadmape niečo, čomu si sa chcel venovať tento mesiac, a potom príde situácia, v ktorej sa zrazu hodí iná schopnosť. To ešte neznamená, že si pri pôvodnom určovaní priorít urobil chybu. Spýtaj sa, čo sa naozaj zmenilo. Je to hodnota schopnosti? Kapacita potrebná na jej rozvoj? Alebo len konkrétny termín a potreba človeka, s ktorým práve pracuješ?

Keď sa zmení naliehavosť, môže mať zmysel na chvíľu prepnúť zameranie. Ale nemýľ si zmenu priority s pokrokom v schopnosti. To, že Petr dostal príležitosť vysvetliť technické riešenie klientovi, samo osebe nič nedokazuje o tom, ako dobre to zvládol. Zatiaľ len vie, čomu má v najbližšom čase venovať pozornosť.

A čo keď sa termín zasa uvoľní?

V deň stretnutia Petr ráno otvoril svoju roadmapu. Pripomienka mu ukázala aktuálne zameranie a pri príprave sa vrátil k otázke, ktorá mu ešte nedávno pripadala nezaujímavá: Čo vlastne potrebuje človek na druhej strane vedieť, aby si mohol vytvoriť rozumný názor na navrhované riešenie?

Nechcel automaticky začať technickým detailom, ktorému sám najlepšie rozumel. V poznámkach si preto zvýraznil prínosy, náklady, obmedzenia a riziká, ktoré mohli byť pre klienta relevantné, a veci, pri ktorých potreboval ďalší kontext. Všetko to vychádzalo z obyčajnej rannej kontroly zoznamu. Bez nej by sa Petr pravdepodobne sústredil na prípravu riešenia ako na ďalšie technické stretnutie. Teraz si aspoň vedome pripomenul, že si na ňom chce vyskúšať iný spôsob uvažovania.

Stretnutie prebehlo. Petr z neho nerobil dôkaz, že už dokáže vysvetľovať biznisový dopad na úrovni architekta. Na to by potreboval rozumieť tomu, ako druhá strana jeho vstupy použila, čo fungovalo a čo bude musieť nabudúce zmeniť. To zatiaľ v poznámkach nemal. Vedel však, že sa počas prípravy dokázal zamerať na niečo, čo predtým často prehliadal.

Na konci týždňa otvoril roadmapu pri svojej krátkej retrospektíve. Termín, kvôli ktorému prepol zameranie, už uplynul. Nemal žiadny ďalší konkrétny dôvod držať zvýšenú Naliehavosť, preto ju vrátil z 0,5 na 0. Priorita biznisového dopadu sa tým zmenila späť z 1,50 na 1,00. Trade-offy zostali celý čas na 1,00.

Petr sa zarazil. Minule sa pri rovnakom hodnotení rozhodol pre trade-offy. Mal by sa teda automaticky vrátiť k pôvodnému plánu?

Prekvapilo ho, že sa mu vlastne nechce. Pri príprave na stretnutie s klientom zistil, že keď sa biznisový kontext neberie ako cudzia časť meetingu, ale ako otázka, prečo sa má vôbec nejaké technické riešenie urobiť, začína ho zaujímať. Stále to bola schopnosť, pri ktorej mu veľa vecí nebude príjemných. Len teraz mal chuť venovať jej ešte nejaký čas pozornosť.

Na ďalšom stretnutí to opísal Igorovi.

"Naliehavosť som vrátil späť na nulu, takže mi zase obe vychádzajú na jednotku," povedal Petr. "Ale ako hlavné zameranie by som nechal ten biznisový dopad. Aspoň zatiaľ."

"Prečo?"

"Mám pocit, že som sa tým doteraz skôr snažil nejako preplávať. Teraz mi pripadá zaujímavé zistiť, či tomu dokážem naozaj rozumieť. Nielen vysvetliť technické riešenie, keď sa niekto spýta."

"Tak si ho tam nechaj. Pri rovnakom hodnotení sa nemusíme tváriť, že vzorec rozhodne aj za teba. Hlavne nech vieš, prečo si si vybral práve toto."

Petr si teda nevymýšľal žiadny dodatočný bonus, ktorým by nové poradie matematicky obhájil. Aktuálna roadmapa jednoducho hovorila:

Ostatné tri ciele zostávali tiež v sekcii NESKÔR, bez zmeny svojich pracovných priorít. Petrovi nezmizla pôvodná motivácia riešiť technický dlh. A práca s trade-offmi sa mu mohla hodiť aj pri rozvíjaní nového zamerania. Len už nepotreboval viesť každú relevantnú oblasť ako aktívnu úlohu.

Všimni si, že Petr tu urobil dve rôzne rozhodnutia. Najprv prepol zameranie, pretože prišiel konkrétny termín a požiadavka z práce. Potom naliehavosť zase znížil, pretože tento dôvod pominul. To sú zmeny okolností. Až potom sa rozhodol zostať pri rovnakom cieli, pretože pri aktuálne zhodnom hodnotení mu dávalo zmysel pokračovať. Ani jedna z týchto vecí ešte nie je dôkazom, že sa v danej schopnosti zlepšil.

Dobrá rozvojová roadmapa nie je zoznam, ktorý musíš za každú cenu dodržiavať, ani systém, v ktorom prepočítavaš každé rozhodnutie na tri desatinné miesta. Má ti umožniť rozpoznať, čo robíš teraz, prečo práve to a podľa čoho by si sa rozhodol inak. Niekedy sa zmení termín. Inokedy až pri skutočnom pokuse zistíš, čo ti išlo a čo nie. To je iný dôvod na úpravu a mal by si ich vedieť rozlíšiť.

Ďalšia otázka nie je v tabuľke

Na začiatku Petr nevedel, čo s abstraktnou prioritou vôbec urobiť. Teraz dokázal veľkú kompetenciu rozložiť, vybrať z nej malý vykonateľný krok, zostaviť prehľad, ku ktorému má zmysel sa vracať, a upraviť ho, keď do práce vstúpi skutočný termín. Naučil sa pracovať s roadmapou. Z toho však ešte nevyplýva, že ovládol kompetencie, ktoré v nej má napísané.

Pri svojej súčasnej priorite mal navyše ďalší problém. Chcel lepšie vysvetľovať technické rozhodnutia ľuďom, ktorí nesledujú implementačné detaily. Na to mu už nebude stačiť len premýšľať o týchto situáciách alebo si ich rozpisovať v dokumente.

Potreboval príležitosť, pri ktorej si to naozaj vyskúša. A ideálne takú, kde bude môcť vidieť, čo jeho vysvetlenie druhému človeku poskytlo a čo mu, naopak, chýbalo.

Otázka teda prestávala byť "čo mám v roadmape". Začínala byť oveľa praktickejšia: Kde na to v bežnej práci nájdem priestor, keď tú zodpovednosť ešte nemám?