Séria: Ako písať dokumentáciu a manuály v IT projekte
Pracovníčka supportu riešila objednávku, ktorá po úspešnej platbe zostala v stave Čaká na platbu. Interného AI asistenta sa opýtala:
„Ako máme opraviť stav objednávky po úspešnej platbe?“
AI našla konkrétny postup:
Séria: Ako písať dokumentáciu a manuály v IT projekte
Interný AI asistent mal pomáhať supportu pri riešení problémov s objednávkami. Do znalostnej bázy sme preto pridali dokument, ktorý opisoval celý proces platby:
Séria: Ako písať dokumentáciu a manuály v IT projekte
Používateľ nahlásil, že po odoslaní objednávky nedostal potvrdzovací e-mail.
V znalostnej báze sme našli tri dokumenty:
Prvý dokument opisoval nastavenie e-mailového servera. Druhý obsahoval zoznam udalostí, pri ktorých systém posiela notifikácie.…
Verzia 1.0 — účinná od: [dopíš dátum]
Táto smernica slúži na zjednotenie kritérií pripravenosti úloh pred začiatkom realizácie. Cieľom je minimalizovať nejasnosti, dodatočné otázky, nesprávne odhady a riziko implementácie na základe neúplných alebo nejasných požiadaviek.
Úloha sa nesmie zaradiť do vývoja, ak nespĺňa Definition of Ready (DoR).…
Séria: Ako písať dokumentáciu a manuály v IT projekte
Release vyšiel.
Release notes boli pripravené.
Používateľský manuál ostal starý.
Support manuál neobsahoval novú funkcionalitu.
Admin dokumentácia neobsahovala nové nastavenie.
A výsledok?
Séria: Ako písať dokumentáciu a manuály v IT projekte
User story je často jedna veta. A akceptačné kritériá k nej buď nie sú vôbec, alebo sú tiež len „nejaké poznámky“.
Potom to dopadne vždy rovnako:
Séria: Ako písať dokumentáciu a manuály v IT projekte
Prečo sa v sérii o dokumentácii venujeme user story
Na prvý pohľad to môže vyzerať zvláštne.
Táto séria je o dokumentácii, manuáloch a znalostných bázach.
Prečo teda začíname pri user story?…
Séria: Ako písať dokumentáciu a manuály v IT projekte
V mnohých firmách existuje dokumentácia len na papieri.
Formálne je potrebná, ale v praxi ju nikto nepíše.
Keď sa otvorí téma dokumentácie, reakcie bývajú podobné:
„Nemáme na to čas.“
„Najprv treba dokončiť funkcionalitu.“
„To dopíšeme neskôr.“
„Veď to máme v kóde.“…
Séria: Ako písať dokumentáciu a manuály v IT projekte
V mnohých firmách vyzerá realita približne takto:
Dokumentácia?
Používateľská sa dopíše o niekoľko verzií neskôr, keď zákazník začne urgovať.
Administrátorská je často stará niekoľko rokov.
Technická dokumentácia nevzniká vôbec.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
V predchádzajúcich článkoch sme pomenovali dva problémy:
Najčastejšie sa miešajú tieto veci:
Výsledok je jeden veľký dokument, ktorý síce existuje, ale nikto sa v ňom nevie orientovať.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
V predchádzajúcich článkoch sme si ukázali dve veci:
Teraz sa pozrime na problém, ktorý je menej viditeľný – ale v produktových firmách veľmi častý.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
V prvom článku série „Nie je manuál ako manuál“ som pomenovala problém miešania cieľových skupín v dokumentácii.
Dnes sa posunieme o krok ďalej.
Čo sa deje vo firmách, kde dokumentácia neexistuje vôbec?
Príde nový kolega.…
(Web verzia – rozšírený článok do série „Dokumentácia ako súčasť kvality produktu“)
Vo firme zaznie veta:
„Treba napísať manuál.“
Nikto sa nepýta:
Výsledok?
Jeden dokument, ktorý obsahuje:
Táto smernica slúži na zjednotenie vnímania stavu „hotovo“ naprieč všetkými rolami v tíme. Zamedzuje nejasnostiam a zvyšuje kvalitu doručovaných výstupov.
Každá úloha (story, bug, task…) sa považuje za „hotovú“ iba vtedy, ak sú splnené nasledovné spoločné podmienky:
