Žinote - ką. Liko - kaip.
Verslo pusė aiški. Funkcijos galvoje ar Excel failuose. Bet trūksta dokumento, pagal kurį potencialūs tiekėjai vienodai suprastų užduotį ir galėtų atlikti tinkamus vertinimus.
Kodėl reikalingas tinkamas techninis dokumentas?
Klaidos įgyvendinant programavimo projektus įvyksta kai užduotis nėra aiški. Techninė dokumentacija/specifikacija padeda išvengti interpretacijų.
Funkcijų sąrašas atrodo pilnas — bet nėra.
Iš pirmo žvilgsnio funkcijų sąrašas gali atrodyti išsamus. Tačiau pradėjus nagrinėti, kaip sistema veiks realiose situacijose, paaiškėja trūkstami scenarijai, integracijos, prieigos ir išimtys. Techninė specifikacija šiuos klausimus išsprendžia dar prieš programavimą — kai sprendimus keisti paprasčiau ir pigiau.
Su klientais nebuvo kalbėta.
Keli pokalbiai su būsimais naudotojais prieš rengiant techninę specifikaciją padeda pamatyti realius procesus, išimtis ir poreikius, kurių neatskleidžia pradinis funkcijų sąrašas. Po šių pokalbių dažnai keičiasi ne tik detalės, bet ir sprendimo logika.
Rinka nebuvo įvertinta.
Peržiūrėjus panašius sprendimus tampa aiškiau, ko iš tikrųjų reikia būtent šiam projektui. Tai padeda atskirti būtinas funkcijas nuo perteklinių, palyginti skirtingus veikimo modelius ir neperkelti į techninę specifikaciją visko, ką jau daro konkurentai.
Trys pasiūlymai — trys skirtingai suprasti projektai.
Jei pradiniai reikalavimai nėra pakankamai aiškūs, kiekvienas tiekėjas užpildo spragas savaip. Galutiniame etape lyginamos ne kainos už tą patį rezultatą, o skirtingos apimtys, prielaidos ir sprendimo logika.
Rezultatas.
Dokumentai, kurie padės išvengti netinkamų projektų vertinimų ir interpretacijų.
Techninė specifikacija.
Aiškiai apibrėžiame sistemos apimtį, pagrindines esybes, procesus, integracijas ir išimtines situacijas. Dokumentas parengiamas taip, kad visi tiekėjai vertintų tą pačią užduotį, o jų pasiūlymus būtų galima objektyviai palyginti.
Funkcinis aprašymas.
Paprasta ir nuoseklia kalba aprašome, kaip sistema veiks vartotojo akimis: kokius veiksmus jis atliks, ką matys ir kaip keisis duomenys. Dokumentas suprantamas tiek verslo, tiek IT komandai.
Biudžeto įvertinimas.
Pateikiame pagrįstą ir detalizuotą projekto biudžetą. Atskirai įvertiname didžiausias nežinomybes ir rizikas, kurios gali turėti įtakos galutinei kainai.
Rizikų registras.
Įvardijame svarbiausias projekto rizikas ir jų galimą poveikį projekto eigai, biudžetui, terminams.
Prielaidų sąrašas.
Užfiksuojame tai, kas projekto vertinimo metu laikoma sutarta ar savaime suprantama. Taip sumažiname riziką, kad neaptartos prielaidos vėliau taps papildomos apimties, kainos ar atsakomybės klausimu.
Atrankos kriterijai.
Techninė užduotis — apie projektą, o atrankos kriterijai — apie tinkamiausią komandą jam įgyvendinti.