Séria: Ako písať dokumentáciu a manuály v IT projekte
Reálny problém z praxe
Nový tester v projekte otvorí user story a vidí funkcionalitu, ktorá sa zdá byť súčasťou produktu.
Otestuje ju, napíše test case a pripraví poznámky do dokumentácie.
O niekoľko dní sa dozvie, že:
„To je špeciálna úprava pre klienta XY.“
Problém je, že nikde v zadání nebolo uvedené, že ide o klientskú úpravu.
Výsledok:
- tester považuje funkcionalitu za súčasť produktu
- support ju začne sľubovať iným klientom
- dokumentácia ju opisuje ako štandardnú funkciu
Tak vzniká chaos medzi tým, čo je core produkt a čo je zákazková výnimka.
Čo sa tu vlastne pokazilo (analýza systému)
Vo firmách, ktoré vyvíjajú produkt a zároveň robia klientské úpravy, vznikajú dve vrstvy funkcionality:
- Core – štandardná funkcionalita produktu
- Custom – úpravy pre konkrétneho klienta
Problém nastáva vtedy, keď sa tieto dve vrstvy miešajú už v zadaniach.
User story potom vyzerajú rovnako, aj keď reprezentujú úplne odlišné veci:
- jednu funkcionalitu má používať každý zákazník
- druhá existuje len pre jedného klienta
Ak to nie je jasne označené, tím postupne stráca prehľad o tom, čo je vlastne súčasť produktu.
Skutočné náklady (čas, chaos, riziko)
Neoznačené klientské úpravy spôsobujú v projektoch typické problémy.
Zmätené testovanie
Tester nevie, či má funkcionalitu testovať ako:
- štandardný scenár produktu
- alebo klientskú výnimku
Chaos v dokumentácii
Používateľský manuál opisuje funkcionalitu, ktorá v skutočnosti platí len pre jedného klienta.
Falošné očakávania
Support môže funkcionalitu sľúbiť inému klientovi, pretože vyzerá ako súčasť produktu.
Problémy pri onboardingu
Nový kolega nevie rozlíšiť:
- čo je štandard produktu
- čo je historická zákazková úprava
Minimálny model riešenia
Najjednoduchšie riešenie je označovať už na úrovni user story, či ide o:
- Core funkcionalitu
- Custom úpravu
Toto označenie môže byť napríklad:
- label v Jire
- komponent
- samostatné pole v issue
Dôležité je, aby bolo viditeľné už pri čítaní zadania.
Príklad:
User story: Export objednávok do XML
Typ: Custom
Klient: XY
Takto je okamžite jasné, že nejde o všeobecnú funkcionalitu produktu.
Prepojenie na kvalitu a workflow
Rozlíšenie Core vs Custom ovplyvňuje viac častí projektu.
Testovanie
Test cases musia rozlišovať:
- štandardné správanie systému
- klientské varianty
Dokumentáciu
Používateľský manuál má opisovať core funkcionalitu produktu.
Klientské úpravy patria do samostatnej vrstvy dokumentácie.
Support
Support musí vedieť, či problém:
- súvisí so štandardnou funkcionalitou
- alebo s klientskou úpravou
Release notes
Zmeny v core produkte majú úplne iný dopad než zmeny v klientskom riešení.
Krátke zhrnutie
Ak sa Core a Custom funkcionalita nerozlišuje už v user story, postupne sa premieša v:
- testoch
- dokumentácii
- komunikácii so zákazníkmi
Výsledkom je projekt, v ktorom nikto presne nevie, čo je vlastne štandardná funkcionalita produktu.
Jednoduché označenie na úrovni user story pomáha udržať prehľad a zabraňuje tomu, aby sa klientské výnimky postupne tvárili ako súčasť produktu.