Petrova cesta k architektonickej zodpovednosti

Petr uvažoval o architektúre, pretože chcel mať väčší vplyv na dlhodobé technické rozhodnutia, najmä tie, ktoré sa týkajú technického dlhu. Keď sa však začal bližšie zaujímať o túto rolu, zistil, že vplyv nemusí znamenať mať posledné slovo. Môže spočívať v schopnosti vysvetliť náklady, riziká a dôsledky rôznych technických možností ľuďom, ktorí o nich rozhodujú.

Zároveň si uvedomil, že v takejto role môže mať výrazne menej priestoru na vlastné programovanie. Začal preto rozlišovať, či ho baví predovšetkým písanie kódu, alebo riešenie zložitých problémov. Tie by mohol riešiť aj pri inom type práce.

Architektúru si preto zatiaľ necháva ako možný smer. Skôr než začne plánovať cestu k novej role, potrebuje si overiť, ako bude vyzerať jej každodenná náplň a či o takúto prácu skutočne stojí.

Petr si s mentorom prešiel niekoľko schopností dôležitých pre jeho predstavu o úlohe architekta. Pri práci s technickými kompromismi odhadol svoju súčasnú úroveň približne na 2 z 5, zatiaľ čo pracovný cieľ bol 4 z 5. Rozdiel ukázal, že má priestor na rozvoj, ale sám osebe ešte nehovoril, čo presne Petr potrebuje zvládať inak.

Petr napríklad dokázal rozpoznať technický dlh. Keď však mentor použil situáciu, v ktorej by čistejšie riešenie trvalo šesť týždňov, zatiaľ čo firma potrebuje výsledok za tri, Petr opisoval najmä technické nevýhody rýchlejšej možnosti. Človeku, ktorý má rozhodnúť, však nestačí vedieť, že vznikne technický dlh. Potrebuje poznať dostupné možnosti, ich prínosy, obmedzenia a konkrétne riziká, ktoré by danou voľbou prijal.

Tu sa ukázalo, v čom Petrova rozvojová medzera skutočne spočívala. Nešlo len o všeobecné "zlepšiť prácu s kompromismi", ale o schopnosť pripraviť rozhodnutie tak, aby boli prínosy a prijímané riziká jednotlivých možností zrozumiteľné. Táto medzera existovala už pred hodnotením, ale až jej konkrétne pomenovanie ukázalo, na čom môže Petr skutočne pracovať.

Nie všetkým dôležitým oblastiam rozvoja má zmysel venovať sa naraz. Petr preto porovnal svojich päť rozvojových cieľov podľa očakávanej hodnoty, potrebného úsilia a aktuálnej naliehavosti. Čísla mali sprehľadniť jeho predpoklady, nie rozhodnúť zaňho.

Práca s technickými alternatívami, trade-offmi a prijímaným rizikom mu vyšla rovnako vysoko ako vysvetľovanie biznisového dopadu technických rozhodnutí (obe 1,00). Pri prvej oblasti išlo takmer o novú praktickú schopnosť, pri druhej bola rozvojová medzera ešte väčšia, ale Petr očakával aj vyššie úsilie.

Namiesto hľadania umelého rozdielu v číslach si Petr ako prvú oblasť vybral prácu s trade-offmi. Druhú vedome odložil na neskôr.

Práve v tom spočíva zmysel prioritizácie. Nie vytvoriť dokonale presné poradie, ale rozhodnúť, čomu venovať obmedzenú kapacitu teraz. "Neskôr" neznamená "nedôležité" a pri zmene okolností sa k rozhodnutiu môže vrátiť.

Petr si ako prvú rozvojovú prioritu zvolil prácu s variantmi, trade-offmi a prijímaným rizikom. Lenže "zlepšiť sa v práci s trade-offmi" nie je úloha, s ktorou môže jednoducho začať.

Spolu s mentorom preto rozdelil cieľ na menšie schopnosti a zameral sa na jednu konkrétnu oblasť: vedieť pomenovať prijímané riziko a jeho dopad. Aj tú však ešte potreboval premeniť na niečo, čo sa dá vykonať.

Vznikla prvá úloha: vybrať jedno známe technické rozhodnutie, spätne porovnať aspoň dve možné varianty a pri každej opísať prínosy, náklady, obmedzenia, konkrétne riziká a ich dopady.

V tej chvíli už nemusel pokračovať v rozpisovaní celého rozvojového cieľa. Vedel, na čom začne, čo má vytvoriť a čo si pri prvom pokuse môže overiť. Výsledok pritom nemusel byť na prvýkrát dobrý. Práve prvý pokus mu mal ukázať, čo potrebuje zlepšiť alebo ďalej rozpracovať.

Tak vznikla použiteľná roadmapa: aktuálne rozvojové zameranie, konkrétny ďalší krok a ostatné ciele odložené na neskôr. Petr sa k nej každé ráno krátko vracal a raz týždenne kontroloval, či jeho priority stále zodpovedajú aktuálnej situácii.

Keď sa neskôr objavilo blížiace sa stretnutie s klientom, Petr presunul pozornosť na inú oblasť: vysvetľovanie biznisového prínosu a dopadu technického riešenia. Tento cieľ mal dovtedy odložený na neskôr, no vzhľadom na konkrétnu potrebu v blízkom termíne sa stal naliehavejším. Pôvodná práca s trade-offmi tým nestratila význam, zmenilo sa len to, čomu malo zmysel venovať pozornosť práve teraz.

Po stretnutí dočasná naliehavosť pominula a oba ciele mali opäť rovnaké hodnotenie. Petr sa však pri týždennej kontrole rozhodol zostať pri vysvetľovaní biznisových dopadov. Táto oblasť ho bavila a chcel sa jej ďalej venovať. Nemusel si preto vymýšľať nové číslo ani umelý rozdiel medzi rovnako hodnotenými cieľmi. Hodnotenie priorít mu pomáhalo porovnávať možnosti, no nerozhodovalo zaňho.

Zmyslom roadmapy teda nie je naplánovať celý rozvoj dopredu ani vytvoriť pevné poradie úloh. Má ti dať dostatočne konkrétny ďalší krok, s ktorým môžeš začať, a zároveň priestor vedome zmeniť aktuálne zameranie, keď sa zmenia okolnosti alebo sa sám rozhodneš inak.

Petr chcel lepšie vysvetľovať biznisové dopady technických rozhodnutí, preto požiadal manažéra o účasť na poradách vedenia. Manažér to odmietol. Dohodli sa však na menšom kroku: Petr dostane približne hodinu na prípravu podkladu k skutočnému technickému rozhodnutiu a potom si ho spolu pol hodiny prejdú. Manažér si ponechá zodpovednosť za to, čo z podkladu použije a čo predstaví vedeniu.

Petr tak nezískal prístup na porady vedenia ani novú rolu. Získal však príležitosť skúšať konkrétnu schopnosť na reálnej úlohe, v reálnom kontexte a s možnosťou spätnej väzby. Manažér pritom môže získať užitočný podklad pre vlastnú prácu, nielen venovať čas Petrovmu rozvoju.

Pri hľadaní príležitostí na rozvoj preto nemusí byť hlavnou otázkou, ako prevziať celú novú zodpovednosť. Často dáva väčší zmysel zistiť, do ktorej časti takejto práce sa môžeš zapojiť už dnes. Ak takýto priestor nie je dostupný, môžeš začať simuláciou, tá však nenahradí skutočné pracovné obmedzenia ani dôsledky rozhodovania.

Petr sa na svoj prvý pokus pripravil najlepšie, ako v tej chvíli vedel. Vedel, že na obhájenie refaktoringu nestačí povedať, že sa starý kód zle udržiava. Preto si prešiel históriu zmien, spočítal, koľko práce si vyžiadali, odhadol možné úspory a pripravil odporúčanie, prečo refaktoring urobiť práve teraz.

Manažér jeho výpočty nespochybnil. Upozornil však na niečo, s čím Petr nepočítal. O šesť týždňov musí tím splniť dôležitý záväzok voči významnému klientovi a refaktoring by mohol spotrebovať kapacitnú rezervu potrebnú pri prípadných komplikáciách. Petr teda pripravil rozumné odporúčanie, ale chýbala mu informácia, ktorá mohla zásadne zmeniť rozhodnutie.

Práve v tom je hodnota prvého pokusu v praxi. Môžeš mať naštudovanú teóriu, poctivo sa pripraviť a urobiť to najlepšie, čo so svojimi súčasnými znalosťami dokážeš. Až v reálnej situácii však môžeš zistiť, čo všetko si ešte nevzal do úvahy. Petrova analýza nemusela byť nesprávna. Prax mu ukázala, v čom bola neúplná.

Po prvom odporúčaní Petr predpokladal, že o dôležitom záväzku voči klientovi nemohol vedieť, pretože nechodí na porady vedenia. Mentor sa ho však spýtal: "Ako vieš, že si sa k tej informácii nemohol dostať?" Petr si uvedomil, že sa pred odporúčaním ani nespýtal, aký dôležitý je termín a čo by znamenalo jeho nedodržanie. Zamenil informáciu, ktorú nemal, za informáciu, ktorú nemohol získať.

Nemusíš mať prístup ku všetkým informáciám vedenia, aby si mohol pripraviť dobré technické odporúčanie. Potrebuješ však aktívne hľadať kontext, ktorý môže zmeniť váhu technických argumentov. Niečo sa môžeš dozvedieť z bežnej firemnej komunikácie, na niečo sa môžeš opýtať manažéra. A ak dôležitú informáciu ani tak nezískaš, mal by si ju v odporúčaní označiť ako neistotu, nie predpokladať, že žiadny ďalší kontext neexistuje.

Petr preto nemení svoj rozvojový cieľ, ale konkrétny ďalší krok v roadmape: pred ďalším odporúčaním aktívne zistiť kontext rozhodnutia a označiť dôležité informácie, ktoré mu chýbajú. Spätná väzba tak nezostáva len pri novom poznaní, ale premieta sa do konkrétneho kroku, ktorý si Petr naplánoval na ďalší pokus.

Technické rozhodovanie sa nezačína až porovnávaním možností implementácie. Dôležité informácie môžu zaznieť už pri predstavení samotného zadania a niektoré si treba aktívne zistiť.

Keď tímu predstavili novú funkciu na hromadný import, Petr tentoraz venoval pozornosť aj potrebám zákazníkov, očakávanému objemu a možnému budúcemu rozšíreniu. Keď neskôr porovnával existujúce spracovanie úloh na pozadí s novým event-driven riešením, uvedomil si, že nevie, či je širšie využitie funkcie u ďalších zákazníkov konkrétnym plánom, alebo zatiaľ len možnosťou.

Namiesto vlastného predpokladu sa opýtal manažéra. Až po overení tejto informácie pripravil technické odporúčanie.

Rozdiel oproti prvému pokusu teda nebol iba v kvalite výsledného podkladu. Petr začal relevantný kontext aktívne vnímať už pri zadaní a chýbajúce informácie si zisťoval ešte pred rozhodnutím. Práve táto zmena v jeho postupe ukazuje, že poučenie z predchádzajúcej skúsenosti premietol do skutočnej práce.

Petrov plán rozvoja vychádzal z rozumnej predstavy o cieľovej roli. Nové informácie z jeho firmy však ukázali, že časť tejto predstavy potrebuje spresniť.

Petrov manažér priniesol z diskusie s vedením firmy novú informáciu. Prípadná architektonická zodpovednosť vo firme by mohla zahŕňať aj technickú spoluprácu so zákazníkmi. Petr by tak potreboval rozumieť relevantnej časti cudzieho systému aj bez prístupu k zdrojovému kódu a bez možnosti preskúmať každý detail. Dôležité by bolo rýchlo rozpoznať podstatné väzby a obmedzenia, oddeliť fakty od predpokladov a zistiť, ktoré informácie ešte chýbajú na spoločné rozhodnutie.

Petr dobre pozná vlastný produkt, ale to nie je to isté ako vytvoriť si dostatočný pracovný model neznámeho prostredia. Jeho pôvodná predstava o cieľovej roli nebola nesprávna, len túto konkrétnu potrebu nevystihovala dostatočne presne.

Tým sa zmenil aj pohľad na jednu z jeho rozvojových medzier. Schopnosť systémového uvažovania v neznámom prostredí nadobudla vyššiu naliehavosť a jej orientačná priorita sa posunula z 0,33 na 0,83. To z nej automaticky nerobí najvyššiu prioritu, ale je to dôvod znovu prehodnotiť roadmapu.

Ďalším krokom môže byť pripraviť pred vhodnou technickou diskusiou so zákazníkom jednoduchý model relevantných systémov, ich väzieb, obmedzení a otvorených otázok a po rozhovore ho spresniť.

Podstatné je, že plán rozvoja nemusí byť nesprávny, aby ho bolo potrebné zmeniť. Ak nové informácie zmenia niektorý z jeho dôležitých predpokladov, treba prehodnotiť aj rozhodnutia, ktoré z neho vychádzali.

V Petrovom prípade sa zmena dotkla už pôvodnej predstavy o cieľovej roli, a tým aj rozvojovej medzery, jej priority a ďalších krokov. Nemusí preto začínať od nuly ani prepisovať celý plán. Keďže jednotlivé časti roadmapy na seba nadväzujú, môže upraviť práve tie závery, ktorých sa nová informácia týka.