Co jsem pochopil — možná dříve než většina ostatních
Dokumentace, která přežije předání: samostatný agent jen na dokumentaci, paralelní vývoj, někdy plánovač na pozadí. Sběr při práci, validace na konci, MD a prezentace.
Dokumentace, která přežije předání — a proč na ni nemusím čekat až po hotovém vývoji.
Jak se mění dokumentace práce a proč to začíná dávat smysl
Realita
Dokumentace bývá často vnímaná jako nutné zlo.
Nikdo ji nechce psát.
Nikdo ji nečte.
A ve chvíli, kdy ji potřebujete, už dávno neodpovídá realitě.
V delivery to známe:
- onboarding nového člověka je náročný
- předání projektu není nikdy úplně hladké
- návrat k něčemu po třech měsících znamená znovu skládat kontext
Důležité je ale tohle:
Problém většinou nevzniká proto, že by dokumentace vůbec nebyla.
Spíše proto, že se přestane používat tak, jak byla jednou napsaná.
Typicky:
- postupy jsou tak rutinní, že si je tým zapamatuje
- začnou se zjednodušovat nebo upravovat „za pochodu“
- s každým dalším člověkem se postupy přirozeně vylepšují
A v tu chvíli: dokumentace přestává odpovídat realitě — proces se reálně posune, ale není to nikde zachycené.
Co se reálně změnilo
Dnes už dokumentace nevzniká jen na konci. Vzniká průběžně.
Důležité upřesnění: to, že vzniká průběžně, neznamená, že je hotová.
V praxi u mě fungují dvě vrstvy:
- Sběr během práce
- Validace na konci
Jak to dělám v praxi
1) Dokumentace vzniká během práce
Nečekám, až něco dokončím.
Ve chvíli, kdy něco řeším:
- dělám screenshoty
- popisuji, co dělám
- předávám to jazykovému modelu
Ten mi pomáhá:
- strukturovat postup
- zpřesnit kroky
- doplnit kontext
Výsledek: už během práce vzniká surový materiál — ne hotová dokumentace, ale základ, na němž lze stavět.
Tento přístup u mě reálně vznikl z konkrétních předání: když má kolega znovu nastavit totéž jako já — export, automatizaci, napojení nástrojů — nestačí mi jen zápis, potřebuji opakovatelný návod s kontextem.
2) Samostatný agent jen na dokumentaci (a někdy plánovač)
V některých nastaveních mám na dokumentaci samostatného agenta, který neřeší nic jiného. Vývojový agent tak může paralelně pokračovat ve své práci a nemusí čekat na to, až po dokončení vývojového celku někdo dopíše dokumentaci — tu řeší jiná linka. Potřebný obsah je zapsaný v průběhu, nebo ho přebírá ten, kdo dokumentaci spravuje. Já nemusím po každém bloku vývoje zpomalovat a v hlavě si držet druhou frontu: až to dodělám, čeká mě ještě dokumentace.
V určitých případech k tomu navíc mám automatický plánovač zaměřený na dokumentaci. Pak ten proces vůbec neřeším a dokumentace vzniká na pozadí — bez toho, abych si ji musel připomínat po dokončených úkolech.
3) Finální validace probíhá na konci
Jakmile práci dokončím:
- vezmu celý soubor ve formátu Markdown
- nahraji jej do jazykového modelu
- začnu klást otázky
Typicky:
- „Jak bych toto nastavil od nuly?“
- „Kde v tomto postupu mohu udělat chybu?“
- „Co z toho není jasné?“
Beru to jako zkoušku srozumitelnosti: pokud model z textu utvoří smysluplný celek a neodporuje screenshotům a krokům, které v podkladu jsou, je to dobrý signál. Pokud začne doplňovat kroky z vlastní hlavy nebo mluví o věcech, které v podkladu nejsou, je třeba text zpřesnit.
U kritických míst platí totéž: člověk s kontextem provede poslední kontrolu — model je rychlá kontrola struktury a mezer v textu, nikoli náhrada odpovědnosti za produkční změny.
Když je výsledek konzistentní a použitelný, pokládám dokumentaci za platnou.
Když ne, upravuji ji, dokud nedává smysl.
4) Z toho vzniká soubor ve formátu Markdown
Výstup není zápis v poznámkovém bloku. Je to:
- návod krok za krokem
- vysvětlení „proč“
- kontext pro někoho jiného
Cíl: aby to dokázal použít někdo, kdo u toho nebyl.
5) K tomu často vzniká prezentace v HTML
Ze souboru Markdown lze připravit například:
- prezentaci v jednom souboru HTML
- se screenshoty
- spustitelnou bez instalace — ovládání jako u slidů
Používám ji jako:
- onboarding
- workshop
- předání projektu
Navíc lze udržet vizuální styl značky, pokud to dává smysl.
U interních postupů sleduji, co na slidech končí — stejně jako u jakéhokoli sdílení obrazovky.
6) Screenshoty nejsou detail, ale základ
Bez screenshotů to lze zvládnout. Vyžaduje to však více úsilí v komunikaci s modelem i s lidmi.
Konkrétně bez nich:
- opakujeme stejné otázky
- znovu vysvětlujeme kontext
- v konverzaci s jazykovým modelem spotřebováváme více vstupu na opakování toho, co jeden screenshot vyřeší hned
Když screenshoty máme:
- máme z první iterace zpracovatelný podklad
- ten nahraji jako základ
- a už jen na něm stavíme další vrstvy
Výsledek: méně opakování, méně nejasností, efektivnější práce — zejména u věcí s rozhraním a konfigurací.
7) Vzniká vlastní knowledge base
Výstupy ukládám do jedné struktury:
- soubory Markdown (detailní popis)
- prezentace HTML (rychlé pochopení)
- screenshoty
Vzniká z toho vlastní znalostní báze, nad níž poté spouštím jazykové modely a vyhledávám informace.
Co z toho plyne v praxi
Na začátku:
- je to pomalejší
- je to náročnější na disciplínu
- nutí to přemýšlet jinak
Po delší době:
- vracíme se k věcem bez zbytečné ztráty času
- onboarding bývá rychlejší
- předání projektů je jednodušší
- nemusíme vysvětlovat pořád dokola totéž
A hlavně: věci se přestávají ztrácet v hlavách a konverzacích.
Ekonomika celého přístupu
Na začátku je investice do tvorby a údržby vyšší a disciplína též.
V dlouhém horizontu — u opakovaných činností, onboardingu a předání — se mi investice vrací v řádu výrazné úspory času, někdy u konkrétního typu úkolu výrazně oproti stavu „děláme to znovu od nuly“.
Nejde o univerzální procenta pro každý tým; jde o to, že neopakujeme stejnou práci a stejné vysvětlování, pokud už jednou máme ověřený podklad.
Co funguje (a co ne)
Funguje:
- dokumentovat průběžně (sběr) a validovat na konci
- kombinace textu a screenshotů
- „zkoušet“ dokumentaci otázkami a kontrolou konzistence
Nefunguje:
- psát dokumentaci až po projektu jako jednorázový dodatečný výstup
- mít ji jen jako formální položku
- neaktualizovat ji podle reality
Co je na tom důležité
AI zde není hlavní téma. Je to nástroj, který:
- pomůže se strukturou
- zrychlí práci
- umožní rychlou zkoušku srozumitelnosti
Kvalita pořád stojí na tom, jak dobře je to použitelné pro někoho jiného — a zda to obstojí i mimo vlastní kontext autora.
Shrnutí
Posun není jen v nástrojích. Je v tom, že:
- dokumentace vzniká přirozeně během práce
- projde finální validací
- je vizuální a konkrétní
- a dá se použít v reálných situacích — předání, školení, návrat po měsících
Rozdíl dnes není v tom, zda dokumentaci vůbec máme. Rozdíl je v tom, zda podle ní dokáže někdo jiný skutečně pokračovat — bez telefonátů do hlavy autora.