dokumenteerimine

Tegevuse eesmärk on tagada läbipaistvus ning ühtsed ja ühised arusaamad, vältimaks võimalikke tõrkeid projekti arendusfaasis. 

Pea meeles! Pane kirja pigem rohkem kui vähem! Hästi dokumenteeritud projektidel on väiksem risk hilineda ning hiljem olulisi muudatusi vajada. 

Agiilne lähenemine annab arendusele kiire edasi liikumise, vajalikul määral paindlikkust ning on üldiselt ka kulu-efektiivne. Ohukohaks võib saada aga see, kui kõiki töö käigus tehtud suulisi kokkuleppeid ei täiendata kirjaliku versiooniga tehtud otsustest.

Soovitav on vältida offline tööriistu ja kellegi konkreetse käes „istuvaid“ dokumente, palju parem lahendus on kasutada dokumentatsiooni jaoks mõnda online-keskkonda, mis võimaldab koos töötada ja kommenteerida. Näiteks Google Docs, O365, Confluence või Notion.

Dokumentatsiooni tuleks jagada asjaosalistega esimesel võimalusel, mitte alles siis, kui see valmis on!

Kindlasti tuleks kirja panna:

• Projekti kirjeldus
• Probleemi definitsioon
• Eesmärgid
• Mõõdikud
• Skoop, ehk mida teeme ja mida ei ole plaanis teha
• Põhikontaktid
• Lingid disainile, töö planeerimise keskkonnale jne.
• Riskid
• Koosolekute memod

Soovitavalt võiks dokumentatsioonis olla ka kasutajatestidega valideeritud hüpoteesid, et vältida samade vigade kordamist.

Projekti kirjeldus

Funktsionaalne kirjeldus

Kuidas teenus töötab kasutaja vaatenurgast? See dokument peaks lahti sõnastama kõik selle, mis ei ole prototüübist silmaga nähtav. Siia kuuluvad:

• Kasutajateekondade kokkuvõtted
• Võimalikud veakohad (nii kasutaja kui süsteemi jaoks)
• Sisumudel
• Lehekülgedel oleva info päritolu ja eesmärk

Tehniline kirjeldus

Kuidas sellist teenust ehitada? Ehkki see dokument on eelkõige arendajale suunatud, oleks hea, kui kogu tuumiktiim saaks vajadusel kursis püsida. Kirjelda lahti:

• Süsteemiarhitektuur
• Infrastruktuur
• Taustaprotsessid
• Andmemudel
• Liidestused muude süsteemidega
• Ootused veebirakenduse kiirusele

Tehnoloogia valik

Siin on abiks ristfunktsionaalsete nõuete juhis ning IT-arhitektuuripaneel.

Kommunikatsioonikirjeldus

Kuidas sellest teenusest rääkida? See dokument alustab elu sageli sisemise pressiteatena, mis on mõeldud organisatsiooni teavitamiseks teenuse avalikustamisel. Näidisstruktuur:

• Pealkiri, mis kutsub teenust lõppkaustaja jaoks arusaadava nimega
• Alampealkiri, mis kirjeldab ühe lausega, kellele see mõeldud on ning mis kasu see toob
• Kokkuvõte, mis ühe lõiguga võtab kokku teenuse sisu (nii, vajaliku baasinfo saaks kätte ka need, kes edasi lugeda ei viitsi)
• Probleemi kirjeldus: mida lahendatakse?
• Lahenduse kirjeldus
• Tsitaat organisatsiooni esindajalt
• Kasutamise kirjeldus
• Tsitaat kasutajalt nende positiivse kogemuse kohta
• Lõpetus ja edasised sammud

Sinu järgmine samm:

Pane kirja dokumentatsioon ning tee dokumentatsioon tiimile ligipääsetavaks. 

Pane tähele! Praeguseks hetkeks, enne edasisi tegevusi peaks olema läbi mõeldud ka vastused põhilistele küsimustele, mis on käsitletud avaliku teenuse arendamise lõuendil, sh peaks olema paigas visioon, ajakava ja eelarve ning vajalike väliste koostööpartneritega lepingud sõlmitud. 

 

Oled selle tegevusega lõpetanud? Liigume edasi: 

Pilootprojekt