Mida peaks tarkvaraprojekti eelanalüüs tegelikult andma?_

Tarkvaraprojekti eelanalüüsi müüakse sageli arenduseelsete töötubade kogumina. Selline kirjeldus keskendub tegevusele, mitte tulemusele.

Eelanalüüsi eesmärk on vähendada kõige olulisemat ebakindlust enne suurema investeeringu tegemist. See peab muutma probleemi, esimese kasuliku tulemuse, tarnesuuna ja peamised riskid selgemaks. Kui etapp lõpeb ilusate diagrammidega, kuid otsust on endiselt sama raske teha, ei ole töö oma eesmärki täitnud.

Eelanalüüs ei ole kogu süsteemi detailne spetsifikatsioon

Keerulise süsteemi täielik ette kirjeldamine loob näilise kindluse. Olulised detailid muutuvad, kui kasutajad näevad töötavat tarkvara, integratsioone testitakse ja meeskond õpib, kuidas organisatsioon päriselt toimib.

Eelanalüüs peab minema sügavale seal, kus ebakindlus on kallis, ning jääma pealiskaudsemaks seal, kus õppimine saab tarne ajal ohutult toimuda.

Kasulikud küsimused on:

• Milline eeldus võib investeeringu mõttetuks muuta?
• Milline sõltuvus võib esimese reliisi blokeerida?
• Millise ärireegli valesti mõistmine on kõige kallim?
• Millist kasutajakäitumist tuleb vaadelda, mitte oletada?
• Millist tehnilist valikut on raske tagasi pöörata?
• Milline vastavus- või tegevusnõue mõjutab arhitektuuri?

Eesmärk ei ole eemaldada kogu ebakindlust. Eesmärk on otsustada, millist ebakindlust tuleb vähendada praegu.

Tulemus 1: selge probleem ja soovitud tulemus

Eelanalüüs peab sõnastama:

• kes probleemi kogeb;
• kuidas seda täna lahendatakse;
• millise ärilise mõju see tekitab;
• miks on oluline tegutseda nüüd;
• millised tulemused näitavad paranemist;
• millised eesmärgid jäävad esimesest etapist teadlikult välja.

"Ehitage uus portaal" ei ole tulemus. "Vähendage partnerite käsitsi liitumistööd ja tehke taotluse olek nähtavaks" on sellele lähemal.

Selge tulemus aitab meeskonnal loobuda tehniliselt huvitavast tööst, mis ärilist eesmärki ei toeta.

Tulemus 2: prioritiseeritud esimene toodanguulatus

Eelanalüüs peab jõudma minimaalse funktsionaalsuse (MVP) lahenduseni, mida saab päris keskkonnas kasutada ning mis loob väärtust.

See ei tähenda tingimata minimaalset kasutajaliidest või demo. Toodanguosa võib vajada autentimist, andmemigratsiooni, monitooringut, tugiprotsesse ja integratsioone. Ulatus peab olema äriliselt kitsas, kuid käitamiseks piisavalt terviklik.

Tulemus peaks kirjeldama:

• sihtkasutajaid;
• terviklikku töövoogu;
• vastuvõtukriteeriume;
• vajalikke integratsioone ja andmeid;
• tegevusvastutusi;
• teadlikult edasilükatud osi.

Tulemus 3: tõendid kasutajate ja protsesside kohta

Sidusrühmade arvamused on kasulikud, kuid ei kirjelda alati päris tööd. Eelanalüüs peab sisaldama otseseid tõendeid, nagu kasutajaintervjuud, vaatlus, protsessiandmed, tugipiletid või päris juhtumid.

Otsige erinevust ametliku protsessi ja tegelikkuse vahel:

• põhisüsteemist väljaspool kasutatavad tabelid (sealhulgas Excel);
• käsitsi kontrollid, mis vigu ennetavad;
• mitteametlikud suhtluskanalid;
• andmete korduv kopeerimine;
• erandid, mida lahendab üks kogenud töötaja;
• aruanded, mida luuakse käsitsi, sest süsteem ei vasta lihtsale küsimusele.

Need detailid määratlevad sageli tegeliku tarkvaraprobleemi.

Tulemus 4: tehniline ja integratsioonide hinnang

Tehniline tulemus peab olema otsusega proportsionaalne. See võib hõlmata:

• praegust süsteemi- ja andmemaastikku;
• kriitilisi integratsioone;
• turva- ja vastavuspiiranguid;
• arhitektuurivalikuid ja kompromisse;
• andmemigratsiooni riske;
• keskkondi ja juurutusvajadusi;
• jälgitavuse ja toe nõudeid;
• eksperimente või prototüüpe kõrge riskiga eelduste jaoks.

Hea hinnang selgitab, miks mingit suunda soovitatakse ja milliseid valikuid saab edasi lükata. Tehnoloogiaid ei tohiks valida ainult selleks, et dokument näeks täielik välja.

Tulemus 5: selge riskiregister

Eelanalüüs peab tooma nähtavale väärtust, kulu või tarnet mõjutavad riskid. Iga oluline risk vajab:

• selget kirjeldust;
• tõenäosust ja mõju;
• hinnangu aluseks olevat tõendit või teadmatust;
• omanikku;
• maandamis- või valideerimistegevust;
• hetke, mil otsus uuesti üle vaadatakse.

Levinud riskid on andmekvaliteet, kolmandate osapoolte sõltuvused, kättesaamatud valdkonnaeksperdid, regulatsiooni tõlgendamine, ebarealistlik migratsiooniaken ja puuduv tooteomanik.

Tulemus 6: tarne- ja juhtimismudel

Organisatsioon peab teadma, kuidas pärast eelanalüüsi tööd otsustatakse ja hinnatakse.

Määratlege:

• tooteomand;
• tehniliste otsuste vastutus;
• sidusrühmade kaasamine;
• oodatavad meeskonnaoskused;
• tagasiside ja demonstratsioonide rütm;
• reliisi- ja vastuvõtuprotsess;
• kulu ja edenemise raporteerimine;
• eskaleerimistee;
• lõpetatud töö definitsioon.

Hea plaan ei jäta muljet, et ennustab igat tuleviku funktsionaalsust. See selgitab, kuidas meeskond uue info tekkides usaldusväärseid otsuseid teeb.

Tulemus 7: eeldustega seotud kulu- ja ajavahemik

Varajased hinnangud peavad olema vahemikud, mitte lubadused. Need peavad näitama:

• mida hinnang sisaldab;
• mis on endiselt teadmata;
• millised eeldused vahemikku mõjutavad;
• kui suur on kindlus;
• esimese toodanguetapi kulu;
• milline tõend hinnangut parandab;
• mis võib panna organisatsiooni peatuma või suunda muutma.

Üks täpne number eelanalüüsi lõpus on sageli vähem aus kui selgete eeldustega seotud vahemik.

Tulemus 8: otsus

Kõige olulisem tulemus on soovitus:

• jätkata pakutud esimese ulatusega;
• teha enne investeeringut suunatud eksperiment;
• osta või seadistada olemasolev toode;
• muuta tarkvara ehitamise asemel äriprotsessi;
• lükata töö edasi kuni sõltuvuse lahendamiseni;
• lõpetada, sest väärtus ei õigusta kulu.

Eelanalüüs loob väärtust ka siis, kui vastus on "ärme ehita". Vale investeeringu vältimine on edukas tulemus.

Kui kaua peaks eelanalüüs kestma?

Pikkus sõltub riskist ja keerukusest, mitte tulevase süsteemi suurusest. Fokusseeritud sisemine tööriist võib vajada päevi. Reguleeritud platvorm koos migratsiooni ja paljude integratsioonidega võib vajada mitu nädalat.

Piirake etapp ajaliselt, kuid ärge suruge iga projekti samasse paketti. Õige lõpp-punkt saabub siis, kui järgmine investeerimisotsus on piisava tõendiga toetatud.

Kuidas hinnata eelanalüüsi kvaliteeti?

Lõpus peavad otsustajad suutma vastata:

• Millist probleemi ja kelle jaoks lahendame?
• Mis on esimene päris tulemus?
• Mida kontrollisime, mitte ainult ei eeldanud?
• Millised on suurimad riskid?
• Kes võtab vastu vajalikke otsuseid?
• Kui palju maksab esimene etapp ja mis vahemikku mõjutab?
• Kuidas otsustame jätkamise?

Kui vastused on selgemad, vähendab eelanalüüs ebakindlust. Kui organisatsioonil on lihtsalt rohkem dokumente, siis mitte.