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ý.…
Príklad
Predstav si systém, ktorý kontroluje diaľničnú známku alebo mýto podľa evidenčného čísla vozidla (EČV).
Používateľ zadá číslo vozidla pri nákupe známky, kamera ho neskôr načíta na diaľnici a systém overí, či je známka platná.
Na prvý pohľad ide o jednoduchý údaj. V praxi však nastávajú problémy:
Ak systém tieto rozdiely nezvládne, môže vzniknúť chyba: vodič zaplatí známku, ale kontrolný systém jeho vozidlo neidentifikuje správne a označí ho ako neplatiča.…
Príklad
Predstav si situáciu v online službe – napríklad parkovanie, prenájom auta alebo predplatné služby.
Zákazník poruší pravidlá: napríklad prekročí čas parkovania, jazdí bez platného lístka alebo poruší podmienky používania služby.
Systém automaticky odošle e-mail alebo SMS:
„Porušili ste podmienky služby. Bude vám účtovaná pokuta.“
Ak je komunikácia nejasná, zákazník nevie:
Príklad
Vodič kamióna zistí, že mu systém naúčtoval mýto dvakrát za ten istý úsek. Podá reklamáciu cez zákaznícky portál, priloží evidenčné číslo prejazdu a čaká na vyjadrenie.
Ak systém nesprávne spáruje prejazdy, neoverí duplicitu alebo refundáciu pošle na nesprávny účet, problém sa neobmedzí len na jednu chybu v účtovaní – zasiahne účtovníctvo, reporting aj dôveru zákazníka.…
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:
Príklad
Predstav si dopravnú spoločnosť, ktorá dostane mesačnú faktúru za prejazdy po spoplatnených úsekoch.
Faktúra obsahuje desiatky položiek – dátum, čas, úsek, sadzbu podľa hmotnosti vozidla, emisnú triedu a výslednú sumu.
Na prvý pohľad sedí celková suma.
Ale účtovníčka si všimne, že pri dvoch prejazdoch je použitá nesprávna sadzba pre nápravový počet.…
Príklad
Klient zaplatí objednávku kartou. Platobná brána zobrazí chybu „Platba zlyhala“, no suma je z účtu stiahnutá. Klient skúsi zaplatiť znova – systém prijme druhú platbu a objednávka sa vytvorí dvakrát.
Z pohľadu biznisu ide o citlivý moment: dôvera zákazníka, peniaze aj reputácia sú v hre.…
Príklad
Predstav si mýtny systém, kde sa cena vypočíta podľa prejdeného úseku medzi vjazdom a výjazdom. Vozidlo vojde na úsek A, vyjde na úseku C, ale systém mu naúčtuje úsek až po D.
Alebo opačný prípad – vozidlo vojde, no výjazd sa nezaznamená a zákazníkovi sa po čase naúčtuje maximálna tarifa.…
Príklad
Predstav si úsek diaľnice, kde už nie sú závory ani mýtne brány. Vozidlo prejde pod portálom a systém automaticky načíta údaje z palubnej jednotky (ENC) alebo z kamerového systému (free-flow).
Vodič nič neplatí na mieste – suma sa zaúčtuje dodatočne podľa prejdeného úseku.
Na papieri jednoduché.…
Príklad
Predstav si prvý júlový víkend. Polovica krajiny vyráža na dovolenku, tranzit cez Slovensko je silný a mýtny systém spracúva tisíce prejazdov za minútu.
Bežne systém funguje stabilne. No v špičke sa ukáže realita: oneskorené párovanie prejazdov, duplicitné záznamy, oneskorené notifikácie o nedoplatku.
V takýchto situáciách netestujeme funkčnosť jednej obrazovky.…
Vozidlo prechádza mýtnym úsekom, no palubná jednotka (OBU) stratí GPS signál v tuneli.
Po výjazde zo zóny sa signál obnoví, ale systém zaznamená len časť trasy. Výsledok?
Nesprávne vypočítané mýto, reklamácia dopravcu a otázka: kto je zodpovedný – zariadenie, infraštruktúra alebo backend?
Výpadok signálu nie je výnimočná situácia.…
Príklad
Predstav si dopravcu, ktorý prechádza mýtnym úsekom. Vozidlo má nainštalovanú palubnú jednotku (OBU), ktorá má zaznamenať prejazd, vypočítať poplatok podľa úseku, náprav a emisnej triedy a odoslať údaje do centrálneho systému.
Ak OBU stratí GPS signál v tuneli, nesprávne identifikuje vozidlo alebo odošle duplicitné dáta, môže dôjsť k nesprávnemu účtovaniu – buď k podúčtovaniu (strata príjmu), alebo k preúčtovaniu (reklamácie, pokuty, reputačné riziko).…
V Európe neexistuje jednotný model spoplatnenia ciest – a práve to je pre testera dôležité. Na Slovensku, v Česku, Rakúsku, Maďarsku, Rumunsku či Bulharsku používajú osobné vozidlá systém časovej diaľničnej známky, zatiaľ čo nákladné vozidlá nad stanovenú hmotnosť podliehajú elektronickému mýtu podľa prejdenej vzdialenosti. Podobne funguje aj Slovinsko.…
