Petr Konečný je fiktívna postava. Jeho príbeh je ilustračný scenár mentoringu, nie skúsenosť skutočného klienta ani doložený výsledok mentoringu. Opísané pracovné situácie, rozhovory a rozhodnutia sú súčasťou tohto fiktívneho príkladu.
Keď si už Petr myslel, že vie, kam smeruje
Petr mal zo svojej rozvojovej roadmapy celkom dobrý pocit. Nie preto, že by sa mu podarilo odškrtnúť všetky úlohy alebo že by sa za posledných niekoľko týždňov nejako zásadne zmenila jeho pracovná rola. Stále bol seniorný vývojár, stále riešil bežnú prácu na projekte a stále ho občas štvalo, koľko technických problémov vzniká pre rozhodnutia, ktoré nedokáže priamo ovplyvniť. Len už mal oveľa konkrétnejšiu predstavu o tom, čo vlastne chce rozvíjať a prečo.
Na prvých stretnutiach s Igorom si skúšal zostaviť pracovný model softvérového architekta. Vtedy si myslel, že architektúra znamená najmä väčší vplyv na technické smerovanie systému. Postupne však zistil, že s takouto rolou môže súvisieť oveľa viac práce s ľuďmi, kompromisy, rozhodovanie v neistote a zodpovednosť za dôsledky, ktoré sa nedajú vyjadriť len kvalitou kódu. Z pôvodnej predstavy nakoniec vznikol pomerne konkrétny model dvadsiatich piatich kompetencií a zodpovedností. Nebola to univerzálna definícia architekta, ale pre Petrovo ďalšie uvažovanie predstavovala použiteľný pracovný základ.
Potom začal porovnávať tento model s tým, čo skutočne robí a vie. Vybral niekoľko dôležitých rozdielov, zostavil z nich priority a postupne ich premieňal na konkrétne úlohy. Dokonca sa mu podarilo získať priestor na dva pokusy pri skutočných technických rozhodnutiach. Pri prvom prehliadol dôležitý kontext týkajúci sa klienta a termínu. Pri druhom sa na chýbajúce informácie spýtal skôr, než dokončil odporúčanie.
Druhý podklad manažér označil za použiteľný. Pridal však ďalšiu otázku: podľa čoho by tím spoznal, že sa má k zvolenému technickému riešeniu v budúcnosti vrátiť? Petr zatiaľ nemal podklady na stanovenie konkrétnej hranice, pri ktorej by malo zmysel rozhodnutie prehodnotiť. Nechcel si ju vymýšľať, a tak ju nechal ako otvorenú otázku.
Bolo to príjemne iné než jeho pôvodný spôsob uvažovania. Kedysi mal tendenciu vnímať podobnú pripomienku ako nedostatok svojho technického návrhu, ktorý musí čo najrýchlejšie odstrániť. Teraz už dokázal prijať, že rozumné odporúčanie môže obsahovať aj presne pomenovanú neistotu. Neznamenalo to, že sa z neho stal hotový architekt alebo že niekto objektívne zmeral zlepšenie jeho schopností. Bolo však možné porovnať, ako pripravoval prvý a druhý podklad a čo pri nich urobil inak.
Na svojej roadmape si ako aktuálny fokus naďalej nechával vysvetľovanie biznisového prínosu a dopadu technických riešení. Mal na to konkrétny dôvod a niekoľko ďalších vecí, ktoré chcel pri práci skúšať. Ostatné rozvojové oblasti zatiaľ zostávali na neskôr.
A práve vo chvíli, keď mal pocit, že jeho plán konečne dáva zmysel, prišla informácia, ktorá sa netýkala žiadnej z jeho ďalších úloh.
Architekt, ktorý nepozná zákazníkov systém
Po nejakom čase sa manažér na pravidelnom 1:1 vráti k Petrovmu dlhodobému smerovaniu.
"Hovoril som o tom aj s vedením," začne. "U nás vlastne nemáme samostatnú rolu softvérového architekta presne v takej podobe, akú si si pôvodne skúšal opísať. Ale dáva nám zmysel uvažovať o tom, či by sme takúto zodpovednosť nemohli postupne vymedziť podľa toho, čo firma skutočne potrebuje."
Petr spozornie. O väčšej technickej zodpovednosti sa už niekoľkokrát rozprávali, ale zatiaľ išlo najmä o to, na čom môže pracovať v súčasnej role. Toto znie trochu inak.
"Takže by u nás mohla vzniknúť pozícia architekta?" spýta sa.
"Možno. Ale zatiaľ by som to tak nenazýval. Nemáme rozhodnuté, či z toho vznikne samostatná rola, aké by mala právomoci ani kto by ju prípadne zastával. Skôr sme sa bavili o tom, kde nám dnes podobná technická zodpovednosť chýba alebo kde by nám mohla pomôcť."
Petr trochu sklamane prikývne. Na okamih si už stihol predstaviť, že sa jeho kariérny plán výrazne posunul dopredu. Manažér mu však žiadne povýšenie neponúka. Prináša len novú informáciu o tom, ako firma uvažuje o technických zodpovednostiach.
Jednou z tém, ktoré sa pri rozhovore s vedením otvorili, je spolupráca s významnejšími zákazníkmi. Niektorí majú vlastné technické tímy, vlastné systémy a pomerne zložité prostredie, do ktorého sa musia produkty Petrovej firmy nejako začleniť. Dnes sa podobné situácie riešia podľa toho, kto má práve potrebné informácie a kto je k danému zákazníkovi alebo projektu najbližšie. Niekedy je to človek z vývoja, inokedy niekto z produktu alebo manažér. Ak by však firma chcela takúto spoluprácu technicky zastrešovať systematickejšie, mohol by dávať zmysel človek, ktorý dokáže fungovať ako jeden z technických partnerov zákazníka.
"To by ale znamenalo poznať aj ich systémy," namietne Petr. "A to predsa často vôbec nepôjde. My niekedy nemáme poriadne informácie ani o všetkých častiach vlastného produktu, nieto ešte o tom, čo si zákazník prevádzkuje u seba."
"Práve," odpovie manažér. "Nemôžeš počítať s tým, že ti dajú celý zdrojový kód a niekoľko týždňov na jeho preštudovanie. Skôr dostaneš nejakú dokumentáciu, opis prostredia a obmedzený čas s ľuďmi, ktorí jednotlivým častiam rozumejú. A potom budete potrebovať rozhodnúť, ako majú vaše systémy spolupracovať, kde sú hranice zodpovednosti a aké obmedzenia musíte rešpektovať."
Petr si predstaví podobnú situáciu. Má pred sebou rozhodnutie o integrácii, ale nepozná presnú implementáciu druhej strany. Nevie, ako majú zákazníkove systémy rozdelené zodpovednosti, kde uchovávajú dôležité dáta ani ako riešia niektoré prevádzkové problémy. Nemôže si otvoriť ich repozitár, prejsť služby jednu po druhej a vytvoriť si obraz rovnakým spôsobom ako vo vlastnej firme.
"A čo ak bez tých detailov nedokážem povedať, či to bude fungovať?"
"Potom budeš musieť rozpoznať, ktoré detaily naozaj potrebuješ. Niektoré si vyžiadaš od ich ľudí. Niektoré možno nebudú relevantné. A ak ti bude chýbať niečo zásadné, jednoducho nebudeš môcť urobiť bezpečný záver. Ale nemôžeme stavať každé spoločné rozhodnutie na tom, že jeden človek preštuduje celý ich systém do posledného detailu."
Petr sa nad tým zamyslí. Vo vlastnej firme má jednu veľkú výhodu, ktorú už takmer nevníma. Je tam skoro päť rokov. Pozná históriu produktov, pamätá si niektoré staršie rozhodnutia, vie, na koho sa obrátiť, a často dokáže odhadnúť, kde sa problém pravdepodobne nachádza, ešte skôr, než sa naň poriadne pozrie. Keď si potrebuje niečo overiť, väčšinou má možnosť otvoriť kód alebo sa spýtať kolegu.
V zákazníkovom prostredí by mu veľká časť týchto oporných bodov chýbala. A pritom by od neho firma mohla chcieť, aby pomohol pripraviť technické rozhodnutie s dôsledkami pre obe strany.
"Ja som si pod architektúrou stále predstavoval hlavne zodpovednosť za naše systémy," napokon prizná. "Rozumieť im ako celku, navrhovať väčšie zmeny, strážiť dlhodobé smerovanie. Toto je trochu iná práca."
"Nie je to úplne iná disciplína," odpovie manažér. "Ale je to iný kontext. A ak niekedy budeme u nás vymedzovať architektonickú zodpovednosť, mali by sme vychádzať z toho, čo skutočne potrebujeme. Nie iba zo všeobecnej predstavy o tom, ako má vyzerať softvérový architekt."
Petr cestou zo stretnutia nepremýšľa nad tým, či sa má naučiť nejakú ďalšiu technológiu. Premýšľa nad niečím nepríjemnejším. Už niekoľko týždňov si starostlivo skladá plán, ako sa priblížiť k cieľovej role. Lenže skutočná podoba tejto roly v jeho firme môže byť konkrétnejšia a v niektorých ohľadoch iná, než si na začiatku predstavoval.
A ak je cieľ iný, možno nebude stačiť len pokračovať podľa doterajšieho zoznamu.
Dvadsaťpäť bodov, ktoré nemusia skončiť v koši
Na ďalšom stretnutí Petr Igorovi opíše, čo sa dozvedel. Tentoraz neprinesie nový technický problém ani podklad, ktorý chcú spoločne prejsť. Otvorí pôvodný pracovný model architekta a vedľa neho svoju aktuálnu roadmapu.
"Takže teraz vlastne neviem, či sme si celý čas nenastavili nesprávny cieľ," povie. "Keď sme robili ten zoznam kompetencií, predstavoval som si hlavne architekta pre naše produkty. A teraz sa ukazuje, že firma možno bude potrebovať človeka, ktorý sa dokáže rýchlo zorientovať v systémoch zákazníkov."
"Čo presne je na tom pôvodnom modeli zlé?" spýta sa Igor.
Petr začne prechádzať zoznam. Systémové uvažovanie, návrh riešení, technické kompromisy, práca s neistotou, komunikácia s rôznymi ľuďmi, facilitácia diskusií, zohľadňovanie biznisového kontextu. Nič z toho zrazu neprestalo dávať zmysel. Dokonca by sa väčšina týchto schopností hodila aj pri spolupráci s technickým tímom zákazníka.
"Asi na ňom nie je nič zlé," pripustí. "Len sme niektoré veci opísali príliš všeobecne."
"Napríklad?"
Petr sa zastaví pri systémovom uvažovaní. Keď túto oblasť posudzovali prvýkrát, vyšlo mu, že už dokáže pomerne dobre chápať širšie súvislosti v prostredí, ktoré pozná. Problém mal skôr s neznámymi časťami systému. Vtedy si uvedomil, že systémový pohľad nie je to isté ako hlboká expertíza na každú použitú technológiu. Jeho pôvodný odhad 2/5 preto po rozhovore spresnili približne na 3/5 oproti pracovnému cieľu 4/5.
Teraz však má pred sebou situáciu, ktorá tomuto rozdielu dáva oveľa konkrétnejšiu podobu. Nejde len o to, či sa vyzná v komponente, ktorý bežne nepoužíva. Môže potrebovať pracovať s celou relevantnou časťou cudzieho prostredia, ku ktorému nemá prístup ku kódu, nepozná históriu rozhodnutí a nemôže sa spoliehať ani na to, že si všetky potrebné informácie zistí sám.
"Takže by som sa mal naučiť rýchlo pochopiť cudzí systém," navrhne Petr.
"To stále znie dosť široko. Čo znamená pochopiť ho?"
"No, vedieť, z čoho sa skladá, aké technológie používa, aké tam majú služby, databázy, integrácie..."
"A načo to chceš vedieť?"
"Aby som s nimi dokázal navrhnúť riešenie."
"Aké riešenie?"
Petr sa zarazí. V hlave sa mu už začal vytvárať zoznam vecí, ktoré by musel naštudovať pri každom novom zákazníkovi. Lenže Igorova otázka ho vracia k niečomu, čo už raz riešili: nie všetky informácie o systéme majú rovnakú hodnotu pre každé rozhodnutie.
"Dobre," začne znova. "Keby sme sa napríklad mali rozhodnúť, ako prenášať dáta medzi naším produktom a ich systémom, potreboval by som vedieť, ktoré časti spolu komunikujú, kto za čo zodpovedá, aké sú obmedzenia a čo sa má stať, keď niečo zlyhá."
"A potrebuješ na to poznať implementáciu každej ich služby?"
"Asi nie. Ale niekedy môže byť konkrétny implementačný detail dôležitý."
"Jasné. Potom potrebuješ zistiť práve ten detail. Alebo sa k nemu dostať cez človeka, ktorý ho pozná. Len by som sa najprv pýtal, na aké rozhodnutie ho potrebuješ."
Petr sa vráti k svojej pôvodnej formulácii. Systémové uvažovanie si predtým spájal najmä so schopnosťou vidieť dôležité väzby a dopady zmien naprieč riešením. To zostáva dôležité. Lenže v cieľovej role, o ktorej teraz uvažuje, pribúda schopnosť vytvoriť si tento obraz rýchlo, z obmedzených informácií a len do takej hĺbky, akú konkrétne rozhodnutie skutočne vyžaduje.
"Takže mám vlastne zistiť, čo všetko neviem?" spýta sa Petr.
"To by bola celkom nekonečná úloha," odpovie Igor. "Skôr potrebuješ zistiť, čo pre dané rozhodnutie vedieť musíš. Čo už je potvrdené, čo si len myslíš, na čo sa máš opýtať a ktoré detaily teraz nemajú podstatný vplyv."
Petr si začne predstavovať prípravu na rozhovor s technickým tímom zákazníka. Namiesto snahy zostaviť úplnú technickú dokumentáciu ich prostredia by si najprv vymedzil rozhodnutie, ktoré spolu riešia. Potom hlavné systémy a hranice medzi nimi, dôležité väzby, známe technické alebo prevádzkové obmedzenia a miesta, kde jeho model stojí na predpokladoch. Až podľa toho by pripravil otázky. Niektoré by potreboval položiť hneď, pretože bez odpovede sa nedá rozumne pokračovať. Iné by možno nemusel riešiť vôbec.
Neznamená to, že hlbšie technické porozumenie je zbytočné. Ak konkrétne rozhodnutie závisí od správania databázy, integračného rozhrania alebo niektorej časti infraštruktúry, musí sa dostať k potrebnému detailu. Rozdiel je v tom, že sa nepokúša získať všetky detaily vopred. Hĺbku poznania odvodzuje od rozhodnutia, nie od toho, koľko dokumentácie alebo kódu má ešte k dispozícii.
"Presne toto by som chcel vedieť robiť," povie Petr po chvíli. "Pozrieť sa na prostredie, ktoré vôbec nepoznám, a neprepadnúť hneď pocitu, že si musím naštudovať celý jeho stack."
"Potom už máš konkrétnejší opis schopnosti než pred chvíľou. Len by som zatiaľ nepredpokladal, že ju vôbec nemáš. Niektoré časti už používaš. Potrebuješ zistiť, čo z nich dokážeš preniesť do neznámeho prostredia a kde sa ti začne strácať pôda pod nohami."
Petr teda neprepisuje celý model architekta. Vráti sa k jednej jeho časti a spresní ju podľa novej informácie z firmy. Z pôvodného všeobecnejšieho systémového pohľadu vzniká konkrétnejšia požiadavka:
V obmedzenom čase si vytvoriť dostatočný pracovný model relevantnej časti neznámeho alebo externého technického prostredia, rozpoznať dôležité hranice, väzby, obmedzenia, predpoklady a neznáme a zistiť len takú úroveň detailu, ktorá je potrebná pre konkrétne architektonické rozhodnutie.
Petr si formuláciu prečíta ešte raz. Je dlhšia než pôvodná položka. Zároveň si však oveľa ľahšie predstaví situáciu, v ktorej by ju mohol použiť, aj otázky, podľa ktorých by zistil, kde má medzery.
Keď sa pripravuješ na rolu s väčšou technickou zodpovednosťou, môžeš ľahko dospieť k záveru, že potrebuješ poznať viac technológií a viac systémov. Niekedy to bude pravda. Skús však rozlíšiť dve veci: rozšíriť si technické znalosti a vedieť urobiť technické rozhodnutie v prostredí, ktoré nikdy nebudeš poznať celé.
V druhom prípade nie je cieľom odstrániť všetky neznáme. Potrebuješ zistiť, ktoré z nich môžu zmeniť rozhodnutie, ktoré informácie dokážeš overiť a kde už musíš prizvať človeka s hlbšími znalosťami. Rovnako dôležité je rozpoznať, kedy máš dosť podkladov a kedy by si len nahrádzal chýbajúcu istotu vlastnou predstavou. To je práca, ktorá môže byť pre architekta podstatná aj v situácii, keď väčšinu implementačných detailov vôbec nevidí.
Priorita, ktorá sa zmenila bez jedinej novej úlohy v práci
Petr má chuť presunúť práve spresnené systémové uvažovanie rovno medzi svoje aktuálne priority. Konečne totiž vidí konkrétnu situáciu, v ktorej by sa mu mohlo hodiť. Lenže keď otvorí roadmapu, všimne si, že túto oblasť v nej už má. Je iba v časti NESKÔR, s pracovnou Prioritou približne 0,33.
Pri pôvodnom hodnotení to dávalo zmysel. Petr už v určitých situáciách systémový pohľad používal, takže oproti pracovnému cieľu 4/5 vychádzal približne z odhadu 3/5. Pre danú oblasť zvolil Hodnotu 1, pretože išlo o rozšírenie schopnosti, ktorú už používal. Snaha zostala 3, pretože rozvoj takejto širokej kompetencie nebude úloha na jedno popoludnie. A Naliehavosť bola 0. Nemal žiadnu konkrétnu požiadavku zamestnávateľa ani termín, ktorý by mu hovoril, prečo sa tejto schopnosti venovať skôr než iným.
Teraz sa na tú nulu pozerá inak.
"Takže by som tomu mal zvýšiť Hodnotu?" spýta sa Igora.
"Prečo práve Hodnotu?"
"No, zrazu sa ukazuje, že to pre tú rolu môže byť oveľa dôležitejšie, než sme si mysleli."
"A zmenila sa samotná schopnosť? Alebo sa objavil konkrétnejší dôvod, prečo ju môžeš potrebovať v prostredí, v ktorom pracuješ?"
Petr sa vráti k tomu, ako pôvodné priority zostavovali. Hodnota vyjadrovala význam rozvoja danej oblasti vzhľadom na jeho aktuálnu úroveň a cieľ. Snaha približne hovorila, koľko kapacity si to vyžiada. Naliehavosť zachytávala konkrétny vonkajší dôvod, prečo sa niečomu venovať práve teraz, napríklad termín alebo potrebu zamestnávateľa.
Nová informácia od manažéra neznamená, že Petr počas jedného rozhovoru získal nové schopnosti. Nedokazuje ani to, že sa jeho pôvodný odhad musí okamžite zmeniť. A firma zatiaľ nepotvrdila žiadnu novú pozíciu ani konkrétnu pracovnú úlohu, ktorú by mal Petr prevziať.
Napriek tomu už systémové uvažovanie v neznámom prostredí nie je len všeobecná schopnosť, ktorá by sa raz mohla hodiť nejakému architektovi. Vedenie jeho firmy práve zvažuje technickú zodpovednosť, pre ktorú by mohla byť podstatná. To je konkrétnejší dôvod než pôvodná všeobecná predstava.
Petr sa preto rozhodne použiť rovnaký pracovný mechanizmus, ktorým predtým reagoval na blížiace sa stretnutie s klientom. Hodnotu a Snahu zatiaľ ponechá bez zmeny. K Naliehavosti pridá 0,5, pretože sa objavila relevantná potreba zamestnávateľa, hoci je zatiaľ len vo fáze zvažovania.
Výpočet zostáva jednoduchý:
textPriorita = Naliehavosť + (Hodnota / Snaha)
PÔVODNÝ STAV
Hodnota: 1
Snaha: 3
Naliehavosť: 0
Priorita: 0 + (1 / 3) ≈ 0,33
PO NOVEJ INFORMÁCII Z FIRMY
Hodnota: 1
Snaha: 3
Naliehavosť: 0,5
Priorita: 0,5 + (1 / 3) ≈ 0,83Petr sa pozrie na výsledok. Na prvý pohľad je to celkom výrazná zmena. Priorita, ktorú ešte nedávno takmer prehliadal na konci zoznamu, má teraz približne 0,83. Nie je to však číslo, ktoré by samo rozhodlo o jeho nasledujúcom pracovnom týždni.
"Takže to mám presunúť do TERAZ?" spýta sa.
"Pozri sa, čo už v TERAZ máš," odpovie Igor.
Petr otvorí aktuálny fokus: vysvetľovanie biznisového prínosu a dopadu technických riešení, Priorita 1,00. Je to oblasť, v ktorej sa vedome rozhodol pokračovať po stretnutí s klientom. Dostal pri nej priestor na dva konkrétne pokusy a z toho druhého si odniesol ďalšiu otvorenú otázku. Nemá dôvod ju len tak zahodiť.
"Nechcem teraz rozbiehať dve veľké veci naraz," povie. "A navyše zatiaľ ani neviem, či sa k nejakej takej zákazníckej diskusii dostanem."
"Tak prečo by si musel automaticky prepnúť?"
"Nemusel. Len mi už nedáva zmysel nechať tú oblasť úplne bokom."
Práve v tom sa Petrov pohľad na prioritizáciu za posledný čas zmenil. Číslo mu nemá hovoriť, čo musí urobiť bez ohľadu na ostatné okolnosti. Má mu pomôcť zviditeľniť dôvody rozhodnutia. Systémové uvažovanie v neznámom prostredí je teraz relevantnejšie než pred niekoľkými týždňami, ale to ešte neznamená, že sa stalo jedinou správnou súčasnou prioritou.
Petr teda ponechá vysvetľovanie biznisového dopadu ako svoj aktívny rozvojový fokus. Pri systémovom uvažovaní však aktualizuje prioritu, spresní cieľovú schopnosť a rozhodne sa pripraviť konkrétny krok pre prípad, že sa objaví vhodná pracovná príležitosť.
Všimni si rozdiel medzi zmenou dôležitosti rozvojovej oblasti a rozhodnutím, že na nej musíš začať pracovať okamžite. Nová informácia ti môže zmeniť predstavu o tom, čo budeš v cieľovej role potrebovať. Tým sa zmenia aj dôvody, podľa ktorých posudzuješ jednotlivé medzery. Nemusíš však automaticky opustiť všetko, čomu si sa doteraz venoval.
Ak máš roadmapu postavenú na konkrétnych predpokladoch, môžeš zmeniť práve ten, ktorého sa nová informácia týka. Tu Petr neprehodnotil celý život ani neprepočítal všetky kompetencie od začiatku. Spresnil jednu požiadavku cieľovej roly a upravil jej Naliehavosť podľa toho, čo sa dozvedel od zamestnávateľa. Či sa tým zmení aj jeho súčasný fokus, zostáva samostatným rozhodnutím.
Úloha pre situáciu, ktorá ešte nenastala
Petr sa vráti k roadmape. Pri práve spresnenej oblasti má teraz konkrétnejší opis a vyššiu prioritu, ale stále ešte nemá nič, čo by mohol v bežnej práci skutočne urobiť. Napísať si "naučiť sa rýchlo orientovať v zákazníckych systémoch" by mu veľmi nepomohlo. Je to len inak sformulovaná kompetencia.
"Takže si mám nájsť nejakú cudziu aplikáciu a skúsiť si ju zmapovať?" spýta sa.
"To by mohol byť jeden typ cvičenia," odpovie Igor. "Ale čo by si si na tom vlastne chcel vyskúšať?"
"Rýchlo si vytvoriť obraz systému z dokumentácie a dostupných informácií."
"A pre aké rozhodnutie?"
Petr sa znova zarazí. Už druhýkrát počas toho istého stretnutia sa pristihol pri tom, že chce začať zbieraním informácií skôr, než si ujasní, na čo ich bude potrebovať.
"Takže by som mal mať najprv konkrétnu situáciu," povie. "Napríklad keď budeme so zákazníkom riešiť integráciu alebo zmenu na rozhraní našich systémov."
"To už je bližšie k tomu, čo ti opisoval manažér. A čo by si na takú diskusiu pripravil?"
Petr začne vymenúvať veci, ktoré mu napadli pri rozhovore o novom modeli roly. Najprv by potreboval vedieť, aké rozhodnutie sa má urobiť a ktorá časť zákazníkovho prostredia je preň relevantná. Potom by si z dostupných podkladov nakreslil jednoduchý model hlavných systémov, ich hraníc a dôležitých väzieb. Oddelil by potvrdené fakty od vlastných predpokladov. Zapísal by obmedzenia a otázky, bez ktorých sa zatiaľ nedá dospieť k rozumnému záveru.
"A po tej diskusii?" spýta sa Igor.
"Upravil by som model podľa toho, čo sa potvrdilo. A nechal by som v ňom veci, ktoré stále nevieme."
"Dokázal by si potom povedať, či ten model stačí na rozhodnutie, ktoré ste riešili?"
"To by som práve chcel skúsiť zistiť."
Petr si uvedomí, že má konečne niečo podobné ako pri prvom rozklade práce s trade-offmi. Vtedy si vybral známe technické rozhodnutie a mal opísať aspoň dve možnosti vrátane nákladov, obmedzení a rizík. Tentoraz nemá pripravovať odporúčanie pre konkrétnu technológiu. Má si vyskúšať, ako z neúplných informácií vytvoriť pracovný obraz cudzieho prostredia, ktorý pomôže pri rozhodovaní.
Rozdiel je v tom, že zatiaľ nemá dohodnutú žiadnu vhodnú diskusiu so zákazníkom. Manažér mu nepovedal, že bude zastrešovať nové technické partnerstvo, ani mu nesľúbil účasť na konkrétnom rokovaní. Nemá teda zmysel tváriť sa, že úlohu začne plniť hneď zajtra.
Do roadmapy si však môže pripraviť presnú podobu kroku pre prípad, že sa takáto príležitosť objaví:
textSMER
SW architekt / vyššia technická zodpovednosť
v kontexte skutočných potrieb firmy
TERAZ
Biznisový prínos a dopad technického riešenia
Priorita: 1,00
NESKÔR
Systémové uvažovanie v neznámom externom prostredí
Priorita: približne 0,83
(pôvodne 0,33)
PRIPRAVENÝ ĎALŠÍ KROK
[ ] Ak sa objaví vhodná technická diskusia so zákazníkom,
vopred vytvoriť jednoduchý pracovný model relevantnej
časti jeho prostredia pre konkrétne rozhodnutie.
Zachytiť:
- hlavné systémy a hranice zodpovednosti;
- dôležité väzby a závislosti;
- známe technické a prevádzkové obmedzenia;
- potvrdené fakty;
- vlastné predpoklady;
- podstatné otvorené otázky.
Pri každej oblasti poznamenať, prečo je informácia
potrebná pre dané rozhodnutie. Nesnažiť sa
zmapovať celý systém ani všetky implementačné detaily.
Po diskusii model aktualizovať:
- čo sa potvrdilo alebo zmenilo;
- ktoré dôležité informácie stále chýbajú;
- či je model dostatočný na riešené rozhodnutie.Petr sa chvíľu pozerá na zápis. V skutočnosti z toho ešte nič neurobil. Nevie, či dostane vhodnú príležitosť ani aké podklady by pri nej mal k dispozícii. Napriek tomu už dokáže pomerne presne povedať, čo by si v takej situácii chcel vyskúšať a podľa čoho by sa dal jeho postup neskôr posúdiť.
"A keby sa tá príležitosť neobjavila?" spýta sa.
"Potom budeš vedieť, že ju zatiaľ nemáš," odpovie Igor. "Môžeme hľadať iný spôsob, ako si niektoré časti vyskúšať. Ale nerobil by som teraz z hypotetického cvičenia dôkaz, že vieš pracovať so skutočným zákazníkom."
Petr prikývne. Spomenie si, ako kedysi chcel chodiť na stretnutia vedenia a nakoniec získal menšiu, ale reálnu príležitosť pripraviť technický podklad. Možno sa niečo podobné podarí aj tentoraz. Možno nie. Zatiaľ má aspoň konkrétnu pracovnú otázku, s ktorou môže prísť za manažérom, ak sa otvorí vhodná téma.
A hlavne si všimne ešte jednu vec. Táto úloha nevznikla preto, že by pri poslednom technickom odporúčaní urobil ďalšiu chybu. Vznikla preto, že sa dozvedel niečo nové o podobe práce, ku ktorej sa chce postupne priblížiť.
Návrat, ktorý neznamená začať od začiatku
Keď Petr neskôr prechádza svoje poznámky, prvýkrát vidí celú doterajšiu cestu trochu inak. Na začiatku chcel hlavne väčší vplyv na technické rozhodnutia. Pripadal si dosť skúsený na to, aby pri niektorých veciach nemusel len čakať, čo rozhodnú ostatní. Architektúra mu preto pripadala ako logický ďalší krok.
Lenže už pri vytváraní prvého modelu zistil, že samotný titul mu automaticky nedá posledné slovo pri každom technickom rozhodnutí. Musel začať rozlišovať, za čo architekt skutočne zodpovedá, aké informácie potrebujú ostatní ľudia a kde sa končí technické odporúčanie a začína prijatie biznisového rizika. Potom si uvedomil, že niektoré schopnosti využíva menej, než si myslel. Vybral priority, vytvoril roadmapu a začal s konkrétnou praxou.
V priebehu sa jeho plán niekoľkokrát zmenil. Blížiace sa stretnutie s klientom mu dočasne zvýšilo Naliehavosť vysvetľovania biznisového dopadu. Keď termín pominul, Naliehavosť sa vrátila na pôvodnú hodnotu, ale Petr sa rozhodol v danej oblasti pokračovať. To bola zmena súčasnej priority podľa okolností a jeho vlastného rozhodnutia.
Neskôr pri prvom skutočnom podklade pre manažéra zistil, že prehliadol dôležitý záväzok voči klientovi. Pri mentoringu si uvedomil, že informáciu, ktorú nemal, sa vopred ani nepokúsil získať. Zmenil teda ďalší konkrétny krok vo svojej roadmape. Pri druhom pokuse sa na podstatný kontext spýtal ešte pred odporúčaním. To bola zmena spôsobu práce na základe spätnej väzby a nového pochopenia problému.
Teraz sa však stalo niečo iné.
Petr nerieši, že mu pri poslednom pokuse chýbala ďalšia otázka. Nerieši ani to, že sa objavil naliehavejší termín, pre ktorý má na týždeň prepnúť fokus. Dostáva informáciu, ktorá spresňuje samotnú predstavu cieľovej roly. Zrazu sa potrebuje vrátiť až k tomu, čo si o architektonickej zodpovednosti pôvodne myslel.
Pôvodný model roly nebol nesprávny. Petr ho zostavil podľa dostupných informácií a pri ďalšej práci mu skutočne pomohol. Len vtedy ešte nevedel, akú podobu by mohla vyššia technická zodpovednosť dostať práve v jeho firme. Teraz má od manažéra konkrétnejšiu, hoci stále nezáväznú informáciu o jednom smere, ktorý vedenie zvažuje.
A táto informácia sa postupne premietne do ďalších častí jeho plánu. Spresní jednu požiadavku cieľovej roly. Vďaka tomu lepšie pochopí svoju rozvojovú medzeru. Znovu posúdi jej prioritu podľa aktuálnej potreby zamestnávateľa. Upraví roadmapu a pripraví konkrétny krok, ktorým môže novú schopnosť pri vhodnej príležitosti skúšať.
Petr pritom nemusí zahodiť svoju doterajšiu prácu. Stále má tie isté skúsenosti, tie isté dve technické odporúčania, tú istú otvorenú otázku, čo by v budúcnosti spustilo prehodnotenie technologického rozhodnutia a ten istý aktuálny rozvojový fokus. Len sa už na svoj plán nepozerá ako na cestu k raz a navždy pevne definovanému cieľu.
Na konci ďalšieho stretnutia si ešte raz otvorí model architekta a vedľa neho roadmapu.
"Vieš, čo je na tom zvláštne?" povie Igorovi. "Keď sme ten model zostavili prvýkrát, mal som pocit, že teraz konečne viem, čo mám robiť. A čím viac sa k tej práci približujem, tým viac zisťujem, že tá rola môže vyzerať trochu inak."
"To je celkom užitočná informácia, nie?"
"Hej. Len mi chvíľu trvalo prísť na to, že to nemusí znamenať, že sme predtým urobili niečo zle."
Petr si spomenie, ako dlho sa pôvodne snažil prísť na správnu definíciu architekta. Ako porovnával pracovné ponuky, články a skúsenosť bývalého kolegu. Ako sa pri prvom rozhovore s Igorom zarazil pri predstave, že bude menej programovať. A ako nakoniec prijal, že potrebuje pracovný model, s ktorým môže začať, nie definitívny opis každej možnej architektonickej pozície.
Teraz ho práve takýto model priviedol k otázkam, ktoré by si bez neho najskôr nepoložil. A umožnil mu zapracovať novú informáciu namiesto toho, aby musel začínať znova.
"Takže ten Framework nie je návod, ktorým prejdem od začiatku do konca a mám hotovo," povie Petr.
"Nebol ani predtým," odpovie Igor. "Len si zatiaľ nemal dôvod vracať sa takto ďaleko."
Petr sa pousmeje. Pred časom by ho podobná odpoveď možno trochu štvala. Chcel jasný plán, podľa ktorého sa môže postupne dostať k väčšej technickej zodpovednosti. Teraz však už chápe, prečo taký plán musí vedieť reagovať na nové informácie. Keby sa jeho pôvodná predstava roly nikdy nemohla zmeniť, mohol by sa v nej ďalej poctivo rozvíjať, aj keď by prestávala zodpovedať práci, ktorú chce v skutočnosti robiť.
Z Petra sa zatiaľ nestal architekt. Firma o novej role nerozhodla a Petr ešte nemá skúsenosť s prípravou technického modelu cudzieho zákazníckeho prostredia pre spoločné rozhodnutie. Jeho roadmapa teda neobsahuje žiadny nový dosiahnutý kariérny výsledok.
Obsahuje však presnejšiu predstavu o možnej cieľovej zodpovednosti, konkrétnejšiu rozvojovú medzeru, aktualizovanú prioritu a pripravený krok pre situáciu, v ktorej sa táto schopnosť môže naozaj prejaviť.
A Petr už vie, že ak takú príležitosť dostane, jeho prvou úlohou nebude zistiť všetko o zákazníkovom systéme. Najprv bude potrebovať pochopiť, o čom sa vlastne rozhoduje a aké informácie sú na to naozaj dôležité.
Možno sa potom ukáže, že jeho pracovný model potrebuje ďalšiu úpravu. Možno zistí, že niektoré časti zvláda lepšie, než čakal, a iné vôbec. A možno prinesie ďalší rozhovor s manažérom informáciu, ktorá jeho predstavu architektonickej zodpovednosti znovu zmení.
Tentoraz však Petr nebude považovať samotnú zmenu plánu za problém. Dôležitejšie preňho bude, či dokáže vysvetliť, ktorá nová informácia ho k zmene viedla a čo kvôli nej urobí inak.