Funkcionalna specifikacija - osnova uspešnega spletnega projekta

Splet je pravo grobišče nasedlih projektov. Izvedbeni roki se lahko podaljšajo za nekajkrat, stroški letijo v nebo. Tipičen razlog je odsotnost funkcionalne specifikacije.

Do konca zapisa boste razumeli, kaj funkcionalna specifikacije je in katerim pastem se lahko izognete.

O čem pravzaprav govorimo

Kako se lotiti gradnje hiše? Preprosto: pokličete zidarja, mu pokažete parcelo, približno nakažete od kje do kje naj stoji hiša, in - da ne izgubljate časa po nepotrebnem - vprašate za ceno.

Zidar vam namesto cene pove nekaj sočnih, se obrne na peti in zapusti prizorišče.

Noben investitor pri zdravi pameti se ne bi lotil gradnje na tak način. Celo neizkušenim graditeljem, ki se lotevajo gradnje bodoče družinske hiše, je jasno, da je najprej potreben načrt.  Da se družina dogovori, kje bodo otroške sobe, kje kuhinja, ali potrebujemo klet ali ne, a bo ena garaža dovolj itd. Premikanje črt po papirju je bistveno cenejše kot kasneje podiranje sten in štemanje lukenj v nosilne zidove.

Pri razvoju spletnih rešitev je zgodba podobna, le da večina naročnikov meni, da načrt ni potreben. Dokumentacija da je zapravljanje časa in denarja. Pustimo birokracijo, roki so kratki, dajmo se kar takoj lotiti betoniranja.

In ravno takšna logika je zanesljiva pot v zapravljanje časa in denarja.

Ko primerjajo ponudbene predračune in končne stroške, naročniki ne morejo verjeti, da gre za isti projekt. V trenutku tega pisanja (november 2018) vem za kar nekaj večjih projektov, ki bi morali biti zaključeni že lani (pa ne nujno v decembru) a so še vedno globoko v razvoju. O odnosih med izvajalcem in naročnikom v takšnih primerih pa raje ne bi ugibal.

Da povzamem: splača se investirati v dober načrt. Na področju softvera mu pravimo funkcionalna specifikacija.

Kaj je funkcionalna specifikacija

Glavna naloga funkcionalne specifikacije je poenotenje predstave vseh deležnikov o končnem rezultatu projekta. Pri tem ne mislim samo na naročnika in izvajalca, ampak tudi na razumevanje različnih oddelkov in služb znotraj podjetja (naročnika).

Niso redki primeri, ko nabava skromno naroči počitniški bungalov, potem pa se tekom razvoja izkaže, da prodaja pravzaprav pričakuje hotel z bazenom. Nadaljevanje zgodbe je temu primerno pestro.

Zato je nujno, da se, še preden se lotimo izvedbe, vsi podpišejo pod formalen, poljudno napisan in vsem razumljiv dokument, ki podrobno opisuje:

• obseg in vsebino projekta,
• delovanje in izgled aplikacije,
• interakcijo z uporabniki ter ostalimi sistemi,
• obveznosti tako izvajalca kot naročnika.

Hkrati je funkcionalna specifikacija referenčna točka za:

• navodila razvojni ekipi,
• kontrolo kakovosti in testiranje,
• pisanje tehnične dokumentacije,
• obvladovanje sprememb na projektu.

Če spadate med tiste redke srečneže, ki lahko že s predpripravljeno Wordpress šablono pokrijejo vse svoje spletne potrebe, potem funkcionalne specifikacije morda res ne potrebujete.

A v praksi je življenje bolj komplicirano. Vseh specifik in potreb določenega podjetja se z instant programskimi paketi praviloma ne da pokriti. Kot je v članku na to temo zapisal Joel Spolsky, direktor Stack Overflow: vsak projekt, ki zahteva več kot en teden kodiranja ali več kot enega programerja, potrebuje funkcionalno specifikacijo.

Funkcionalna specifikacija prinaša številne prednosti

1. Specifikacija je navodilo razvijalcem, kako izvesti posamezne funkcije in integracije. 
   Koherenten razvoj brez krpanja za nazaj pomeni, da je koda kakovostnejša, aplikacija pa hitrejša in bolj stabilna.
2. Funkcionalna specifikacija je neodvisna od izvedbe. Lahko jo naročite ločeno, zlasti, če jo če želite uporabiti kot osnovo za povpraševanje pri izbiri (ali zamenjavi) izvajalca.
3. Če se razvojnik (ali celotna ekipa) sredi projekta zamenja, bo nov razvijalec znal oceniti zatečeno stanje, kaj je že narejeno in koliko še manjka do cilja.
4. Delo poteka hitreje in brez odvečnih zapletov, manj je neprijetnih diskusij v stilu:

“A tako ste si to predstavljali? Tega nam pa na začetku niste povedali.”
“Saj smo se ja že pogovarjali o tem.”
“S kom? Z Manco? Nič ni omenila. Sedaj je pa tako na porodniški. Tole je pa kup dodatnega dela.”
“Kakšno dodatno delo? Trdite da ste strokovnjaki, to bi morali že v osnovi predvideti!”
“Oprostite, kako naj vemo, da za ključne kupce želite ločeno spletno stran v hebrejščini?”
itd, itd.

Ne tvegajte po nepotrebnem

Kljub vedno znova potrjeni resnici, da funkcionalna specifikacija pomeni zanesljivejšo, kakovostnejšo in cenejšo izvedbo, se v praksi kar nekako noče zgoditi. Zakaj?

Pisanje specifikacije je delo za izkušenega strokovnjaka (več o tem v nadaljevanju).  Z vsemi sestanki in usklajevanji traja nekje od enega tedna do enega meseca in to nekaj stane.

Na prvi pogled gre za strošek, ki se mu zlahka odpovemo. Saj vendar vsi vemo, o čem se pogovarjamo, kaj ne? (Ha, ha.) Račun za takšno lahkomiselnost pride kasneje. In je praviloma nekajkrat višji od cene specifikacije.

Od nerealnih obljub nimate nič

Če izvajalcem pošljete povpraševanje v stilu “Koliko pri vas stane en kos spletne trgovine?” boste dobili ponudbe, ki se lahko tudi za 100% razlikujejo ena od druge. Ker je naloga slabo definirana, bodo izvajalci, da se izognejo tveganjem, v ceno vračunali “rezervo” za dela, ki bodo priplavala na površje tekom projekta.

Ne glede na to, za katerega ponudnika se boste odločili, ne boste vedeli, koliko vas bo razvoj na koncu dejansko stal (ker brez specifikacije tega ne more vedeti niti ponudnik sam) in kakšni so realni roki za izvedbo. V bistvu s takšnim splošnim povpraševanjem niste dosegli nič.

Nasprotno pa dobro napisana specifikacija izvajalcem pušča zelo malo manevrskega prostora. Že ponudbe so bolj realne, izbrani razvijalec se tudi kasneje ne bo mogel izgovarjati, češ “tega pa nismo vedeli” in z aneksi reševati prenizko ponudbeno ceno.

Dobra specifikacija odvrne tiste izvajalce, ki samozavestno mislijo, da stvar obvladajo, ker so že razvili dve ali tri preproste aplikacije. Ko pa jih postaviš pred kompleksen, natančno opisan tehnični izziv, pa samozavest hitro splahni. Če projektu niso kos je bolje, da se to ugotovi pred začetkom projekta, sicer ga nikoli ne boste pripeljali do konca.

Velja pa tudi obratno: ko sta obseg in cena določena, bo naročnik težko z vedno novimi “fičerji” bogatil slabo načrtovane procese.

V smislu dobrih računov in dobrih prijateljev je torej v interesu obeh, da je funkcionalna specifikacija sestavni del pogodbe.

Kako začeti specifikacijo

Če se odločate za novo spletno aplikacijo, to počnete z nekim namenom. Verjetno imate vsaj okvirno predstavo o tem, kaj naj bi uporabnik počel na novi spletni strani, kaj mu boste ponudili in kaj naj bi imel od tega. Govorimo o uporabniških zahtevah, na primer:

Uporabniku (spletne trgovine) se določi distribucijski center, iz katerega se mu bo dostavljalo blago.

Takoj se pojavi vrsta podvprašanj: si bo uporabnik center izbral sam, ali se mu ga sistem določi avtomatično, glede na lokacijo (naslov dostave)? Lahko uporabnik distribucijski center kasneje tudi zamenja? Kaj se zgodi z izdelki, ki jih novi distribucijski center ne drži na zalogi? Kaj če se uporabnik preseli in spremeni naslov?

Pomembno je, da se ne ustavimo pri pavšalnih zahtevah ampak čim bolj opredelimo vse podrobnosti in s tem povezane scenarije. V kolikor jih ne boste opredelili že sami, je naloga načrtovalca, da vam jih pomaga razjasniti in oblikovati dokončni postopek.

Vsekakor pa je dokument “Uporabniške zahteve” prvi korak pri zasnovi bodoče rešitve in sestavni del Funkcionalne specifikacije.

Kdo sodeluje pri pripravi dokumenta

Priprava specifikacije zahteva sodelovanje celotne projektne ekipe, in sicer

1. Naročnika s svojimi zahtevami in željami,
2. Strokovnjaka za uporabniško izkušnjo,
3. Razvojne ekipe, ki bo pomagala oceniti izvedljivost predlaganih rešitev,
4. Projektnega vodje, ki bo poskrbel, da bo obseg rešitve ostal v razumnih okvirih.

Vseeno pa mora biti za sam dokument odgovorna ena oseba, izkušen strokovnjak, ki je

1. tehnično podkovan in ima izkušnje z razvojem spletnih projektov,
2. razume logiko poslovnih procesov naročnika, jih zna analizirati in prevesti v funkcionalnosti aplikacije,
3. zna in rad piše - se ne ustraši praznega lista papirja,
4. zna pisati v poljudnem jeziku, brez odvečnega tehničnega žargona,
5. razume tako naročnika kot izvajalca in zna poiskati sinergije med različnimi deležniki v procesu.

Vem, kaj boste rekli. Takšni modeli ne obstajajo. No, ni čisto res. V Creatimu se kakšen najde:)

Za konec

Razvojni projekti nikoli ne potekajo popolnoma gladko. A če celotna ekipa, tako na strani naročnika kot izvajalca, diha za iste, jasno začrtane cilje, potem bodo tudi ovire obvladljive. Praksa nam vedno znova dokazuje, da kakovostna funkcionalna specifikacija pomaga držati smer, da spletni projekt pripeljemo do uspešnega zaključka. Predvsem pa vam bo prihranila živce, čas in denar.

Zato je dobra funkcionalna specifikacija največ, kar lahko naredite za uspešnost projekta.