72. Vedení DevOps týmu a mentoring juniorů

Úvod a kontext

Předchozí dvě lekce probraly architektonická rozhodnutí, která dělá
seniorní inženýr. Tahle lekce je o jiné, stejně důležité části
seniorní role — vedení lidí. Řada DevOps inženýrů se dřív nebo
později ocitne v roli, kde tráví část času mentoringem juniorů nebo
neformálním (či formálním) vedením týmu, aniž by přestali být
technicky aktivní. Tato lekce shrnuje praktické principy, jak tuto
roli zvládnout dobře.

Teorie

Přechod od "dělat" k "umožnit dělat druhým"

Nejčastější past pro nově povýšeného senior/lead inženýra je zůstat
u modelu "nejrychlejší cesta je udělat to sám". Krátkodobě to
funguje, dlouhodobě to škáluje špatně — tým jako celek zvládne víc
práce, než jeden člověk, jen pokud lead tráví část času tím, že
zvyšuje schopnosti ostatních, ne že přebírá jejich práci. Klíčová
změna myšlení: úspěch leada se neměří tím, co osobně naprogramoval,
ale tím, co tým jako celek dodal a jak se v čase zlepšil.

Mentoring přes code review

Code review (viz modul 3 o Git workflow) je jeden z nejpřirozenějších
míst pro mentoring — probíhá pravidelně, na konkrétním, kontextuálním
příkladu, a nevyžaduje samostatný čas navíc. Rozdíl mezi review jako
"kontrolou kvality" a review jako "mentoringem":

• Kontrola kvality se ptá jen "je tenhle kód v pořádku?" a
  odpověď je binární (schválit / vrátit k opravě).
• Mentoring přes review vysvětluje proč je návrh lepší nebo
  horší, ukazuje alternativy a jejich kompromisy, a záměrně nechává
  prostor pro to, aby junior sám objevil část řešení, místo aby
  dostal hotovou odpověď. Konkrétně to znamená psát komentáře typu
  "zkus se zamyslet, co se stane, když tahle funkce dostane prázdný
  seznam" místo rovnou "chybí ti kontrola na prázdný seznam".

Důležitá rovnováha: přehnaně dlouhé, "profesorské" review zpomaluje
tým a junior se může cítit demotivovaně — mentoring má být
dávkovaný a zaměřený na 1–2 nejdůležitější věci v daném review, ne
na vyjmenování všeho, co by šlo zlepšit.

Delegování a předávání odpovědnosti

Efektivní delegování neznamená jen "rozdělit úkoly", ale vědomě
předávat odpovědnost, ne jen práci:

• Delegovaná práce bez odpovědnosti — junior dostane přesný
  zadání "udělej tohle přesně takhle" a lead zůstává jediný, kdo
  rozhoduje. Rychlé teď, ale juniora to neposouvá dál.
• Delegovaná odpovědnost — junior dostane problém k vyřešení
  ("naše nasazování je pomalé, navrhni zlepšení") s jasným rámcem
  (rozpočet, deadline, koho se zeptat) a lead se stává konzultantem,
  ne rozhodovatelem. Pomaleji teď (junior potřebuje víc podpory), ale
  buduje to jeho schopnost samostatně rozhodovat příště.

Postupné zvyšování míry odpovědnosti (od jasně definovaných úkolů
po open-ended problémy) je typický vzorec růstu juniora do
seniorního inženýra.

Psychologické bezpečí

Pojem popularizovaný výzkumem Google (projekt Aristotle) — týmy s
vysokým psychologickým bezpečím (lidé se necítí trestáni za to, že
přiznají chybu, zeptají se na "hloupou" otázku, nebo nesouhlasí s
leadem) dlouhodobě dosahují lepších výsledků než týmy, kde lidé
mlčí ze strachu. Přímá souvislost s blameless postmortemy z modulu
14 — kultura, která netrestá za přiznání chyby v postmortemu, je
jen jeden konkrétní projev širšího principu psychologického bezpečí
v týmu.

Praktické kroky, jak psychologické bezpečí budovat jako lead:

• Aktivně přiznávat vlastní chyby a nejistotu ("nevím, pojďme to
  společně zjistit") — modeluje to chování, které chcete v týmu.
• Reagovat na chyby otázkou "co se z toho naučíme", ne hledáním
  viníka.
• Explicitně oceňovat, když někdo přizná problém včas, i když to
  znamená nepříjemnou zprávu.

Plánování práce týmu

Lead typicky přebírá i část plánovací zodpovědnosti — rozdělení
práce mezi krátkodobé úkoly (provozní práce, opravy) a dlouhodobé
investice (technický dluh, automatizace, viz "toil" z modulu 14).
Časná chyba je nechat tým 100 % času řešit naléhavé provozní věci —
bez vyhrazeného prostoru na investice se technický dluh a "toil"
jen hromadí a dlouhodobě zpomalují celý tým. Typické doporučení je
vyhradit pevný, chráněný podíl kapacity (např. 20 %) na dlouhodobé
zlepšování, který se neruší ani při vytížení.

Praktický příklad

Konkrétní ukázka mentoringového code review komentáře, který
demonstruje rozdíl popsaný v teorii — místo prostého opravení chyby
lead vede juniora k tomu, aby přišel na řešení sám:

Původní kód (junior, pull request):

def get_user_lessons(user_id):
    lessons = db.query(f"SELECT * FROM lessons WHERE user_id = {user_id}")
    return lessons

Komentář leada (mentoring styl, ne "kontrola kvality"):

Dobrý základ! Než to schválím, zkus se zamyslet nad dvěma věcmi:

1. Co se stane, když `user_id` bude obsahovat text jako
   `1; DROP TABLE lessons;`? Mrkni se na lekci o SQL injection
   z modulu 13 (bezpečnostní skenování) — jak bys tenhle dotaz
   přepsal, aby byl bezpečný?

2. Tahle funkce vrací úplně všechny sloupce (`SELECT *`). Zamysli
   se, jestli je to žádoucí, když třeba tabulka `lessons` obsahuje
   i interní metadata, která by neměla jít přes API ven.

Zkus si to upravit a napiš, jaký přístup jsi zvolil a proč — rád se
podívám znovu.

Tento styl komentáře řeší konkrétní problém (SQL injection, over-
fetching), ale nechává juniora, aby si sám dohledal řešení a
zdůvodnil ho — buduje to schopnost, ne jen opravuje jeden řádek kódu.

Shrnutí

Vedení DevOps týmu znamená přechod od osobního výkonu k násobení
schopností celého týmu — přes mentoring v code review (vysvětlování
"proč", ne jen opravování), vědomé delegování odpovědnosti (ne jen
práce) a budování psychologického bezpečí, ve kterém lidé otevřeně
přiznávají chyby a nejistotu. Lead zároveň zodpovídá za plánování
práce tak, aby vedle naléhavých provozních úkolů zůstal chráněný
prostor na dlouhodobé investice do kvality a automatizace.

Kontrolní otázky

1. Jaký je rozdíl mezi "dělat práci za tým" a "umožnit týmu dělat
   víc", a proč se dlouhodobě vyplácí ten druhý přístup?
2. Vysvětlete rozdíl mezi delegováním práce a delegováním
   odpovědnosti na konkrétním příkladu.
3. Jak souvisí psychologické bezpečí s blameless postmortemy z
   modulu 14?
4. Mini cvičení: přepište komentář "Tohle je špatně, použij radši
   parametrizovaný dotaz" do mentoringového stylu, který juniora
   vede k tomu, aby sám pochopil proč.