Petr Konečný je fiktívna postava. Jeho príbeh je ilustračným scenárom mentoringu, nie skúsenosťou skutočného klienta ani doloženým výsledkom mentoringu.
Spoznaj svojho Petra
Na Petrovom projekte sa už nejaký čas hromadí technický dlh. Nie je to jeden veľký problém, na ktorý by sa dalo ukázať pri jedinom incidente. Skôr množstvo menších rozhodnutí, kvôli ktorým je časť aplikácie čoraz náročnejšie meniť. Vývojári sa o tom opakovane rozprávajú, ale Petr má pocit, že manažment tejto téme nevenuje toľko pozornosti, koľko by si zaslúžila. Niektorí kolegovia už ďalšiu snahu takmer vzdali. Petr zatiaľ nie, aj keď ho začína unavovať, že dokáže problém pomerne presne opísať, ale len ťažko ovplyvňuje, čo s ním firma urobí.
Pritom rozhodne nie je neskúsený vývojár, ktorý by sa prvýkrát stretol s komplikovanejším projektom. Má za sebou približne osem rokov profesionálnej praxe v dvoch firmách, z toho takmer päť rokov u súčasného zamestnávateľa. Za ten čas prešiel viacerými tímami, pracoval na dvoch väčších produktoch a spoznal dosť ľudí aj mimo svojho aktuálneho tímu. Kolegovia za ním chodia konzultovať technické problémy a on sám dostáva skôr väčšie úlohy, pri ktorých potrebuje rozumieť viacerým častiam systému naraz. Občas ho prizvú aj k produktovej diskusii, pretože dokáže vysvetliť, čo existujúce riešenie technicky umožňuje a čo už nie.
Programovanie ho stále baví. Lenže jeho pracovný deň už dávno netvorí hlavne programovanie. Ak chce niekoľko hodín nerušene niečo implementovať, musí si na to vedome vyhradiť čas. Inak sa mu deň ľahko rozpadne medzi konzultácie s kolegami, meetingy a riešenie problémov, pri ktorých ostatní potrebujú jeho znalosť systému.
Petr začína premýšľať, či už nie je čas posunúť sa niekam ďalej. Láka ho väčšia technická zodpovednosť, možnosť ovplyvňovať dlhodobé smerovanie systému a možno aj trochu väčšia váha jeho argumentov, keď sa rozhoduje o veciach, ako je technický dlh. Napadne mu softvérová architektúra. Keby bol architektom, možno by sa už nemusel stále len pozerať na to, ako vznikajú problémy, na ktoré vopred upozorňoval.
Lenže tá posledná časť je zatiaľ hlavne jeho predstava. Petr vlastne nevie, aké rozhodovacie právomoci by architekt v jeho firme mal. Nevie ani, či by mu taká rola skutočne pomohla riešiť problémy, ktoré ho dnes trápia. A jednu podstatnú otázku si zatiaľ takmer nepoložil: čo by sa zmenilo na jeho vlastnej práci, keby sa tým architektom naozaj stal?
Najprv zistiť, kam vlastne chce ísť
Petr si uvedomuje, že chce ďalej profesijne rásť, ale nie je si istý, ktorým smerom sa z pozície seniorného vývojára vydať. Rozhodne sa preto svoje možnosti prebrať s mentorom. S Igorom na prvých stretnutiach prechádzajú rôzne smery kariérneho posunu. Architektúra z toho vyjde ako smer, ktorý Petra zaujíma natoľko, že stojí za to poriadne ho preskúmať. Nie ako definitívne rozhodnutie o zvyšku kariéry, ale ako pracovná hypotéza.
Igor mu však nezačne zostavovať zoznam technológií, ktoré by sa mal naučiť, ani kurzov, ktoré by mal absolvovať. Namiesto toho mu dá domácu úlohu: pripraviť si vlastnú pracovnú predstavu o softvérovom architektovi. Čo taký človek robí počas bežného týždňa? Za čo zodpovedá? Aké schopnosti potrebuje? V čom sa jeho práca líši od práce seniorného vývojára? A čo Petrovi na tejto role zatiaľ nie je jasné?
Petr má hľadať všade, kde mu to pomôže vytvoriť si rozumný obraz. Môže čítať pracovné ponuky, články, pozerať prednášky, diskutovať s AI alebo sa rozprávať s niekým, kto už túto prácu robí. Pri dôležitých zisteniach si má poznačiť, odkiaľ ich získal. Nie preto, aby odovzdal akademickú rešerš, ale aby pri spoločnej diskusii bolo vidieť, čo je skúsenosť konkrétneho človeka, čo tvrdenie z pracovného inzerátu a čo len jeho vlastný predpoklad.
Igor si medzitým nezávisle pripraví svoj model rovnakej roly. Petr ho vopred neuvidí. Na ďalšom stretnutí teda nepôjde o to, aby Petr správne odpísal mentorov zoznam, ale o porovnanie dvoch predstáv. Ak sa budú líšiť, budú mať o čom hovoriť.
Dvanásť bodov a niekoľko nepríjemných prekvapení
Petr sa do úlohy pustí celkom poctivo. Prejde pracovné ponuky na architektonické pozície, prečíta články o rozdiele medzi seniorom a architektom, pozrie si prednášku, diskutuje s AI a porozpráva sa s bývalým kolegom, ktorý dnes pracuje ako softvérový architekt. Postupne z toho poskladá dvanásť oblastí, ktoré mu pripadajú dôležité.
Časť zoznamu mu sedí takmer dokonale. Architekt by mal rozumieť systému ako celku, navrhovať väčšie zmeny ešte pred začiatkom implementácie, orientovať sa v technológiách a integráciách, premýšľať o dlhodobej udržateľnosti. Presne taká práca Petra láka. Už dnes ho na väčších úlohách najviac bavia chvíle, keď musí rozmotať vzťahy medzi viacerými komponentmi a prísť na riešenie, ktoré bude dávať zmysel ako celok.
Zaujímavejšie sú body, pri ktorých si začne písať otázniky. Architekt má mať vplyv na výber technológií a technické smerovanie. Lenže znamená "mať vplyv" aj "mať právo rozhodnúť"? Tri rôzne pracovné ponuky naznačujú rôzny rozsah zodpovednosti. A ak má architekt dohliadať na bezpečnosť, prečo má firma security experta? Má snáď architekt rozumieť úplne všetkému do hĺbky?
Potom príde na rad komunikácia. Bývalý kolega mu opíše, že ho pri prechode k architektúre neprekvapila ani tak väčšia technická zložitosť ako množstvo času stráveného zosúlaďovaním ľudí a tímov. Architekt musí vysvetľovať rozhodnutia, obhajovať kompromisy, počúvať námietky a niekedy presviedčať ľudí, ktorí implementačné detaily vôbec neriešia. Petr si pri tom spomenie na svoje súčasné dni, keď sa kvôli konzultáciám takmer nedostane ku kódu. Ak je toto v architektúre ešte výraznejšie, nemusí to byť taká skvelá zmena, ako si pôvodne predstavoval.
Najviac ho začne trápiť otázka, koľko vlastne architekt programuje. Niektoré zdroje opisujú prácu takmer bez bežnej implementácie, bývalý kolega občas vytvorí prototyp alebo si sám technicky overí nejaký nápad. Petr by pri kóde rád zostal. Nevadilo by mu programovať menej ako dnes, ale predstava, že už prakticky vôbec nič nepostaví vlastnými rukami, sa mu veľmi nepáči.
Posledné prekvapenie je menej vznešené. Do zoznamu sa mu dostane aj dokumentácia architektonických rozhodnutí, ich dôvodov a súvislostí. Podľa bývalého kolegu je to jedna z vecí, ktoré architekt robí častejšie. Petrova prvá poznámka je stručná: "Fuj."
Napriek tomu tento bod zo zoznamu nevyškrtne. Vlastne chápe, prečo by malo byť možné po pol roku zistiť, prečo sa tím kedysi rozhodol práve takto. Len ho neláka predstava, že by raz namiesto kódu hlavne písal dokumentáciu.
Na ďalšie stretnutie teda prinesie pomerne dobrý zoznam. A tiež omnoho viac pochybností, než mal pred domácou úlohou.
Dva modely na jednom stole
Petr najprv Igorovi ukáže svoju prácu. Až potom Igor otvorí vlastný model, ktorý si pripravil nezávisle. Na prvý pohľad to vyzerá povzbudivo: obaja vnímajú systémový pohľad, architektonický návrh, technický dlh, dlhodobú udržateľnosť, komunikáciu aj kompromisy medzi variantmi ako dôležitú súčasť roly.
"Takže som hádam nebol úplne mimo," poznamená Petr.
"Nie. Ale ani cieľom nebolo trafiť sa do môjho zoznamu. Zaujímavejšie je, kde sa tie zoznamy rozchádzajú."
A práve tam začne byť rozhovor pre Petra podstatne menej pohodlný. Igorov model kladie väčší dôraz na obhajovanie technických názorov, rozhodovanie v neistote, prácu prostredníctvom ostatných ľudí, facilitáciu diskusií a prepájanie technického a biznisového sveta. Architekt podľa neho nemusí byť najlepší programátor v miestnosti. Často je dôležitejšie, aby dokázal spojiť relevantné pohľady a pomôcť ostatným urobiť informované rozhodnutie.
Petr sa vráti k obave, ktorá sa mu v poznámkach objavovala čoraz častejšie. "Takže ešte viac komunikácie a ešte menej programovania? Už teraz za mnou ľudia chodia takmer celý deň. Ak to má byť ešte výraznejšie, tak možno architektúra vlastne nie je to, čo hľadám."
Igor ho nezačne upokojovať tým, že aj architekti niekedy píšu kód. "Hej. To je dosť pravdepodobné. Nepovedal by som 'možno'. Ak pôjdeš týmto smerom, je veľmi realistické, že programovania ubudne a komunikácie pribudne."
Toto Petr práve počuť nechcel. Premýšľal o väčšom vplyve na technické rozhodnutia, nie o kariére, v ktorej vymení svoj posledný súvislý čas na programovanie za ďalší kalendár plný stretnutí. Lenže Igor z toho zatiaľ nevyvodzuje, že Petr mieri nesprávnym smerom. Spýta sa ho niečo iné: "Čo presne ťa vlastne baví na programovaní?"
Petr chvíľu premýšľa. "Keď dostanem nejaký zložitý problém a musím ho rozmotať. Prísť na to, ako to celé urobiť. A potom vidieť, že to naozaj funguje."
"A samotné písanie kódu? Syntax, implementácia riadok po riadku? Je to práve toto, o čo nechceš prísť?"
"Asi nie úplne. Ale mám rád ten stav, keď sa do toho ponorím a niekoľko hodín niečo skutočne staviam."
Zrazu sa ukazuje, že veta "chcem ďalej programovať" znamenala niekoľko rôznych vecí. Petr má rád riešenie zložitých problémov, navrhovanie, sústredenú prácu aj konkrétny výsledok, ktorý po ňom zostane. A samozrejme, aj programovanie. Len vôbec nie je samozrejmé, že o všetky tie ostatné veci príde, ak bude menej písať kód. Niektoré môže nachádzať aj v architektonickej práci. Iné mu môžu chýbať výraznejšie, než si dnes myslí.
Igor preto neuzatvára ani jednu možnosť. Ak by Petr zistil, že každodenná implementácia je pre neho nenahraditeľná, môže dávať zmysel preskúmať inú vyššiu technickú rolu, napríklad niektorú podobu tech leada. Ak ho však najviac napĺňa rozmotávanie problémov a návrh riešení, architektúra môže stále stáť za pokus. Rozhodnúť sa to teraz nedá. Petr si ju teda necháva ako pracovný cieľ, len už vie, že si musí omnoho presnejšie overiť, čo od nej očakáva.
Tu by som na chvíľu zastavil aj teba. Keď hovoríš, že ťa na súčasnej práci niečo baví a nechceš o to pri kariérnom posune prísť, čo presne tým myslíš? Samotnú činnosť alebo niečo, čo ti táto činnosť umožňuje zažívať? Pri programovaní to môže byť vytváranie kódu, sústredenie, riešenie problémov, navrhovanie alebo možnosť vidieť hmatateľný výsledok. Sú to príbuzné, ale odlišné potreby.
Keď budeš porovnávať ďalšie kariérne roly, skús sa namiesto ich názvov pozrieť na ich bežný pracovný týždeň. Čo by si pravdepodobne robil viac, čo menej a čoho by si sa musel vzdať? Na toto ti žiadny univerzálny zoznam kompetencií neodpovie. Dôležitý je rozdiel medzi predstavou o role a tým, ako by vyzerala práve pre teba.
Keď máme security experta, prečo to rieši architekt?
Petrov zoznam priniesol ďalšiu otázku, ktorá sa na prvý pohľad zdá celkom rozumná. Pri bezpečnosti sa zastaví. "Ale veď na security máme vo firme security experta. Tak ako to, že to má robiť architekt? Ja rozhodne nechcem byť security expert."
Igor namiesto ďalšieho zoznamu znalostí rozlíši dve veci: kto má odbornú prácu vykonať a kto má v rámci svojej roly zabezpečiť, aby bola táto oblasť vo výslednej architektúre správne pokrytá. Security špecialista môže urobiť analýzu, navrhnúť opatrenia alebo upozorniť na konkrétne hrozby. Architekt sa nemusí stať bezpečnostným expertom, ale ak nesie zodpovednosť za výslednú architektúru, nemôže pri návrhu prehliadnuť oblasť, ktorá je pre celok zásadná.
"Nemusíš robiť prácu security experta," vysvetľuje Igor. "Ale ak nesieš zodpovednosť za výslednú architektúru, musíš vedieť, že security treba riešiť, vedieť, koho prizvať, dostatočne rozumieť tomu, čo ti hovorí, a zabezpečiť, aby sa jeho vstup skutočne premietol do návrhu."
Petr si uvedomí, že si pod pojmom architekt predstavoval človeka, ktorý musí sám vedieť najviac o všetkých dôležitých technických oblastiach. To by však bola celkom absurdná požiadavka. Pri návrhu väčšieho systému predsa môžu jednotlivým častiam rozumieť omnoho hlbšie ľudia, ktorí sa na ne špecializujú. Architekt potrebuje rozpoznať, kedy ich znalosti potrebuje, porozumieť dôsledkom a zabezpečiť, aby sa ich vstup nestratil pri rozhodovaní o celku.
Platí to pre bezpečnosť, ale podľa konkrétneho systému aj pre prevádzku, databázy, infraštruktúru alebo ďalšie špecializácie. Petr si tak do svojej predstavy dopĺňa dôležitý rozdiel. To však neznamená, že každý človek s titulom architekt automaticky nesie rovnakú zodpovednosť. Kde presne táto hranica leží, si bude musieť neskôr overiť pri konkrétnej role a zamestnávateľovi.
"Good enough". Dve slová, ktoré Petr veľmi nemusí
Keď sa pri porovnávaní modelov dostanú k rozhodovaniu medzi variantmi, Petr narazí na pojem "good enough". Igor ho používa v zmysle vedomého kompromisu. Petrovi sa však okamžite vybavia skúsenosti z jeho projektu.
"Na 'good enough' som trochu alergický. U nás to často znamená, že to urobíme rýchlo, pridáme ďalší bordel a niekedy potom to opravíme. A to 'niekedy' nikdy nepríde."
Práve tu sa rozhovor vracia k tomu, prečo sa Petr začal o architektúru vôbec zaujímať. Chce, aby mali dlhodobé technické problémy pri rozhodovaní väčšiu váhu. Igor jeho frustráciu nespochybňuje. Len rozlíši nesprávne pochopený kompromis od kompromisu, o ktorom sa dá rozhodnúť vedome.
"Good enough neznamená, že o probléme nevieš. Práve naopak. Ako architekt by si mal vedieť povedať: Tento variant dokážeme dodať rýchlejšie, ale prijímame tým tieto konkrétne riziká."
Petr dokáže ľahko povedať, že rýchlejší variant vytvorí technický dlh. Lenže čo presne ten dlh spôsobí? Ktorá zmena bude neskôr drahšia? Čo sa môže pokaziť a aký to bude mať dopad? Ktoré riziká sú prijateľné kvôli súčasnému termínu a ktoré by už prijateľné byť nemali? To nie sú len technické otázky. O niektorých dôsledkoch musí rozhodnúť človek, ktorý zodpovedá za produkt, termín alebo obchodný záväzok.
"Ty nemusíš rozhodnúť, že firma toto riziko prijme," hovorí Igor. "Ale musíš zabezpečiť, aby človek, ktorý o tom rozhoduje, skutočne vedel, čo prijíma."
Petr si uvedomí, že väčší technický vplyv možno nevzniká len tým, že človek dostane titul a právomoc hovoriť ostatným, čo majú robiť. Niekedy vzniká tým, že dokáže technický problém preložiť do konkrétnych dôsledkov, podľa ktorých sa firma vôbec môže rozhodovať. Ak niekto vedome prijme riziko kvôli inému cieľu, nemusí to znamenať, že technickým argumentom nerozumel. A ak Petr nedokáže pomenovať cenu kompromisu inak než slovami "technický dlh", možno mu časť podstatného argumentu zatiaľ chýba.
Nie je to pre neho úplne príjemné zistenie. Prišiel s predstavou, že v architektonickej role bude mať konečne väčší vplyv na rozhodnutia, ktoré ho dnes štvú. Teraz zisťuje, že časť práce na budovaní tohto vplyvu môže začať robiť už ako seniorný vývojár. A že ani ako architekt nemusí mať posledné slovo v tom, aké biznisové riziko firma prijme.
Skús si predstaviť situáciu, v ktorej si presvedčený, že firma prehliada technický problém. Čo by o ňom potreboval vedieť človek, ktorý nerozhoduje podľa čistoty architektúry, ale podľa termínu, nákladov, zákazníckych záväzkov a prijímaného rizika? A vieš vôbec, kto takéto rozhodnutie môže urobiť?
Nejde o to vzdať sa technického názoru alebo automaticky dať za pravdu manažmentu. Rovnako nestačí predpokladať, že druhá strana problému nerozumie. Skús oddeliť samotný technický argument od rozhodnutia, pre ktoré má byť podkladom. Niekedy zistíš, že ho potrebuješ lepšie vysvetliť. Inokedy, že skutočne narážaš na hranice svojich právomocí. To sú dve rôzne situácie a vyžadujú si odlišný ďalší krok.
Fuj. Dokumentácia.
Petrova domáca úloha obsahovala aj jednu položku, ktorú Igorov pôvodný zoznam tak výrazne nezdôrazňoval: dokumentáciu dôležitých architektonických rozhodnutí. Petr na ňu mal stále rovnakú spontánnu reakciu. "Fuj."
Igor mu v tom neodporuje nejakým nadšeným prejavom o kráse dokumentácie. Skôr vysvetlí, prečo sa na ňu dnes pozerá inak než len ako na administratívu.
Ak sa dôležité rozhodnutie vrátane jeho dôvodov uchová len v hlavách niekoľkých ľudí, časom začne byť ťažko použiteľné. Nový kolega nevie, prečo existujú určité obmedzenia. Iný tím sa vráti k variantu, ktorý už kedysi zamietli, pretože nepozná dôvod. A po pol roku niekto odstráni zdanlivo zbytočný kompromis bez toho, aby vedel, aký problém pôvodne riešil.
"Dnes môže veľkú časť samotného zapisovania a štruktúrovania prevziať AI, ak si ten proces rozumne nastavíš," hovorí Igor. "Pre teba je dôležitejšie rozpoznať, ktoré rozhodnutie stojí za zaznamenanie a aký kontext sa pri ňom nesmie stratiť."
Petrovi sa tým písanie dokumentácie nestane obľúbenou aktivitou. Začne však rozlišovať medzi nekonečným vytváraním dokumentov a zodpovednosťou za to, aby sa nestratilo dôležité rozhodnutie. Spolu s jeho dôvodmi, predpokladmi a obmedzeniami. A pretože tento bod priniesol do rozhovoru práve Petr, doplnia ho do spoločného pracovného modelu. Mentorov zoznam nie je žiadny answer key; aj Petrov pohľad ho môže spresniť.
Ako pokračujú, podobne spresnia ešte niekoľko oblastí, ktorým sa Petr pri svojom prieskume až tak nevenoval. Architekt nemusí riadiť kapacitu celého tímu, ale mal by vedieť prispieť k odhadu technickej náročnosti rôznych variantov. Pri niektorých zmenách sa potrebuje pozerať na výsledok celého feature alebo riešenia, nielen na jednotlivé riadky pri code review. Musí vedieť zapojiť špecialistov, viesť technické diskusie aj v situácii, keď sám preferuje jeden variant, a chápať širší firemný kontext rozhodnutí. Čím viac týchto tém prejdú, tým menej Petr vníma architekta ako človeka, ktorý je jednoducho technicky o úroveň vyššie než seniorný vývojár.
Namiesto jednej definície má Petr pracovný model
Na konci stretnutia by sa dalo všetko skrátiť na niekoľko pekných slov: systémový pohľad, komunikácia, rozhodovanie, zodpovednosť. Lenže s takouto definíciou by Petr pri ďalšom rozvoji veľmi rýchlo opäť narazil. Čo si má vlastne predstaviť pod "vedieť rozhodovať"? Ako spozná, že už "má systémový pohľad"? A ako má porovnať svoju súčasnú prácu s rolou, ktorej požiadavky zostávajú takéto všeobecné?
Petr s Igorom si preto nechajú model podstatne konkrétnejší. Obsahuje 25 samostatných kompetencií a zodpovedností, ktoré môžu neskôr posudzovať jednu po druhej. Napríklad vidieť dôležité väzby naprieč systémom; rozkladať veľký problém ešte pred implementáciou; porovnávať varianty vrátane ich nákladov, obmedzení a prijímaných rizík; prizvať správnu expertízu a integrovať ju do návrhu; vedieť technické dôsledky vysvetliť človeku, ktorý nesie zodpovednosť za obchodné rozhodnutie; viesť diskusiu a pritom počúvať protichodné názory; alebo zabezpečiť, aby sa dôležité rozhodnutie a jeho kontext nestratili.
Tým však Petr ešte nedostal odpoveď na otázku, či sa má stať architektom. Jeho zoznam nie je univerzálna definícia. V skutočnosti zatiaľ ani nevie, ako by túto rolu chcela vymedziť jeho firma, kto by v nej mal aké rozhodovacie právomoci, koľko času by zaberala komunikácia a či by mu skutočne dala možnosť ovplyvňovať veci, kvôli ktorým o nej začal uvažovať. Všetky tieto otázky si bude musieť postupne overiť v konkrétnom prostredí.
Napriek tomu sa na konci stretnutia pozerá na architektúru inak než na začiatku. Už to nie je len vyššia technická rola, v ktorej by mohol mať väčší vplyv. Je to možno práca, v ktorej strávi menej času písaním kódu, viac času s ľuďmi a viac energie prípravou rozhodnutí, za ktoré ani nemusí niesť konečnú zodpovednosť. Niektoré časti ho stále lákajú. Niektoré sú oveľa menej príjemné, než očakával. A niektoré z jeho pôvodných obáv sa ukázali byť zložitejšie, než si myslel.
Nezískal istotu, že si vybral správny cieľ. Získal niečo, s čím sa dá konečne pracovať: dostatočne konkrétnu predstavu, ktorú môže porovnať so svojou súčasnou realitou a podľa nových informácií ju ďalej meniť.
Keby si si mal z Petrovho prvého kroku odniesť jednu vec, nebol by to zoznam vlastností softvérového architekta. Ten môže v inej firme vyzerať inak. Zaujímavejší je spôsob, akým vznikol: Petr sa najprv pokúsil svoju cieľovú rolu opísať sám, mentor priniesol nezávislý pohľad a obaja hľadali miesta, kde sa ich predstavy rozchádzajú. Nie preto, aby jeden vyhral, ale aby Petr zistil, ktoré predpoklady stoja za overenie.
Možno si podobný pracovný model môžeš zostaviť aj pre rolu, o ktorej premýšľaš. Nemusí byť dokonalý a nemusíš v ňom mať všetko správne. Potrebuješ však niečo konkrétnejšie než názov pozície, aby si mohol začať klásť užitočné otázky: Čo z toho dnes skutočne robím? Kde mám skúsenosť a kde len predstavu? A čo by pre mňa znamenalo, keby sa niektorý z tých predpokladov ukázal ako nesprávny?
Práve k tomu sa Petr dostane ďalej. Keď už dokáže aspoň pracovne opísať, kam chce ísť, musí sa pozrieť na omnoho menej pohodlnú časť: kde voči tomuto cieľu v skutočnosti stojí dnes.