Specifikacija ni 50 strani teksta
Pogosta napaka: podjetje pred razvojem napiše obsežen dokument z vsako podrobnostjo sistema. Petdeset strani z diagrami, tabelami in seznami funkcij. Razvijalec prikima in naredi nekaj. Po treh mesecih ugotovi naročnik, da ni to, kar si je mislil. Specifikacija ni kriva. Tudi pomagala ni.
Dobra specifikacija je krajša in bolj koristna. Razvijalcu pove, kaj graditi. Vam pove, kaj boste dobili. Je dogovor, ki prepreči različne razlage iste besede.
Sedem delov dobre specifikacije
1. Cilj v eni povedi
Najpomembnejši stavek dokumenta. Ena poved o tem, zakaj sistem sploh delamo. Poslovno, ne tehnično.
Cilj sistema je, da naša komerciala preneha porabljati pol dneva za odgovore na rutinska vprašanja strank in se osredotoči na nove posle.
Vsaka naslednja odločitev se vrača k temu cilju. Nova zahteva, ki cilja ne podpira, je kandidat za izpust.
2. Glavni uporabniki in njihovi cilji
Tri do pet skupin uporabnikov. Za vsako: kdo so in kaj hočejo doseči s sistemom. Brez tehničnih podrobnosti.
Komercialisti (15 oseb): hočejo hitro videti stanje stranke in pripraviti ponudbo.
Vodji prodaje (2): potrebujeta pregled rezultatov ekipe in odprtih težav.
Stranke (200 oseb): hočejo videti svoja naročila in pretekle fakture.
3. Kritični procesi (3 do 5 največ)
Procesi, ki morajo delovati. Brez njih sistem ni uporaben. Za vsakega opišete korak za korakom: kdo ga sproži in kakšen je rezultat.
Proces: ponovitev preteklega naročila
1. Stranka se prijavi v portal.
2. Na seznamu naročil izbere preteklo naročilo.
3. Klikne "ponovi naročilo".
4. Sistem ustvari novo naročilo z istimi artikli in trenutnimi cenami iz pogodbe.
5. Stranka popravi količine in potrdi.
6. Naročilo se zapiše v ERP.
Trije taki opisi povedo razvijalcu več kot sto alinej s funkcijami.
4. Kaj sistem NE bo počel
Pogosto najpomembnejši del specifikacije. Eksplicitno izpisani primeri, ki so zunaj obsega:
Sistem ne bo:
- obravnaval reklamacij (te ostanejo v obstoječem procesu)
- imel mobilne aplikacije v prvi fazi
- nadomestil obstoječega sistema za fakturiranje
- vključeval lojalnostnih točk
Brez tega seznama razvoj v tretjem mesecu obstane pri vprašanju "ali to vključuje tudi X". Izpisan seznam izključitev to reši vnaprej.
5. Sistemi, s katerimi se bo povezal
Vsak zunanji sistem (ERP, e-pošta, plačilni vmesnik, dobaviteljski portal). Za vsakega: kateri podatki tečejo v katero smer.
ERP (Pantheon):
- sistem bere: artikli, zaloge, cene po stranki, fakture
- sistem piše: nova naročila, sprememba kontaktnih podatkov stranke
6. Merila za uspeh
Kako boste vedeli, da je sistem uspešen? Tri merila, ki so merljiva in se vežejo na cilj.
Sistem bo uspešen, če:
- 60 odstotkov rutinskih vprašanj strank obravnava portal namesto komerciale
- povprečni čas odgovora pade pod 2 minuti
- 70 odstotkov B2B strank uporabi portal vsaj enkrat mesečno
Brez merljivih meril nikoli ne veste, ali je projekt uspel. "Smo zadovoljni" je premalo.
7. Časovni okvir in proračun
Kdaj mora biti pripravljeno in koliko denarja je na razpolago. Brez teh dveh številk razvijalec ne more priporočiti pravega obsega. Lahko predlaga rešitev za 5.000 EUR. Lahko predlaga rešitev za 50.000 EUR. Brez okvira ne ve, kaj je primerno.
Česa NE pisati v specifikacijo
Ne pišite tehničnih rešitev
"Sistem mora uporabljati REST API z OAuth 2.0 avtentikacijo" je odločitev za razvijalca. Ne za vas. Vi opišete, kaj sistem dela. Razvijalec izbere, kako ga zgradi.
Izjema: če imate obstoječe sisteme, ki zahtevajo določen način. Na primer ERP s točno določenim vmesnikom. To omenite kot omejitev, ne kot zahtevo.
Ne pišite vsake funkcije, na katero ste pomislili
Vsaka dodatna funkcija pomeni dodatno delo, dodaten strošek in dodatno možnost napake. Specifikacija naj vsebuje le tisto, kar je nujno za prvo verzijo. Vse ostalo gre v seznam idej za kasneje.
Ne pišite "in podobne stvari"
"Sistem mora podpirati pošiljanje obvestil in podobne stvari" so odprta vrata za razlage. Bodisi naštejete, kaj točno, bodisi to izpustite. Razvijalec ni telepat.
Format, ki dela
Specifikacija ne potrebuje posebnega formata. Word, Google Docs, navaden tekst v repozitoriju, vse je v redu. Pomembno je le, da je dokument:
- Kratek (3 do 8 strani za večino projektov)
- Konkreten (primere namesto abstraktnih opisov)
- Verzioniran (vsaka sprememba ima datum in podpis)
- Dostopen vsem v projektu
Kaj se zgodi po napisani specifikaciji
Specifikacija ni dogovor v kamnu. Je izhodišče. V prvih dveh tednih razvoja se običajno izkaže, da je nekaj napačno opisanega. Nekaj manjka. Nekaj je odvečnega. To je normalno in zaželeno. Bolje popraviti specifikacijo na začetku kot pol projekta kasneje.
Pošten razvijalec bo specifikacijo z vami pregledal. Postavil bo vprašanja in predlagal popravke. Slab znak je, če jo molče sprejme in razvija po mrtvi črki, brez vprašanj.
Vzorec strukture
Tukaj je minimalna struktura, ki je za večino projektov dovolj:
- Cilj sistema (1 odstavek)
- Uporabniki in njihovi cilji (1 stran)
- Kritični procesi (1 do 2 strani z opisi po korakih)
- Sistemi za povezavo (pol strani na sistem)
- Kaj sistem ne bo počel (kratko)
- Merila za uspeh (3 do 5 točk)
- Časovni okvir in proračun (kratko)
Skupaj 3 do 8 strani. Več od tega običajno pomeni, da je obseg prevelik za en projekt. V tem primeru ga razdelite.
Bistvo
Specifikacija ni bibliografija vašega podjetja. Je dogovor: razvijalcu pove, kaj graditi, vam pove, kaj boste dobili. Krajši in bolj poslovno usmerjen dokument prinese boljši sistem od dolgega tehničnega.