Koristne informacije ...

Vodnik za tehnično specifikacijo projekta

Spletni projekt redko zaide s poti zato, ker bi bila tehnologija preveč zahtevna. Pogosteje se zaplete, ker ekipa začne razvijati, preden se vsi strinjajo, kaj točno nastaja, komu je namenjeno in kako bo rešitev delovala v praksi. Ta vodnik za tehnično specifikacijo projekta vam pomaga zahteve pretvoriti v jasen dokument, ki varuje čas, proračun in kakovost končnega izdelka.

Tehnična specifikacija ni birokratska ovira pred začetkom razvoja. Je dogovor med naročnikom in izvajalcem. Dobra specifikacija pove, kaj uporabnik vidi, kaj lahko naredi, kateri sistemi so povezani v ozadju, kdo upravlja vsebino in po katerih merilih se projekt šteje za uspešno zaključen.

Kaj je tehnična specifikacija projekta

Tehnična specifikacija je dokument, ki poslovno idejo razdeli na izvedljive funkcionalnosti. Pri spletni strani lahko opredeli strukturo strani, obrazce, večjezičnost, način urejanja vsebin in zahteve glede hitrosti. Pri spletni trgovini pa zajame tudi katalog izdelkov, plačila, dostavo, kupone, davčna pravila, zalogo ter povezave z računovodstvom ali logistiko.

Ne gre za to, da mora naročnik poznati programske jezike ali arhitekturo strežnikov. Njegova naloga je jasno razložiti poslovni cilj, proces in posebnosti dela. Naloga razvojne ekipe pa je, da to prevede v rešitev, predvidi tehnične posledice in odkrito pove, katere želje so smiselne, katere zahtevajo dodaten obseg in kje obstajajo boljše alternative.

Dobro pripravljena specifikacija omogoča realnejšo ponudbo. Brez nje je cena pogosto ocena za osnovni scenarij, med projektom pa se pojavijo predpostavke: dodatne uporabniške vloge, izvoz podatkov, poseben izračun cen ali povezava s sistemom, za katerega na začetku nihče ni vedel. To niso nujno slabe ideje. Težava nastane, kadar se obravnavajo kot samoumevni del prvotnega obsega.

Začnite pri poslovnem cilju, ne pri seznamu funkcij

Stavek »potrebujemo novo spletno stran« ni specifikacija. Je izhodišče za pogovor. Pravo vprašanje je, kaj mora nova rešitev spremeniti. Ali mora ustvariti več kakovostnih povpraševanj? Poenostaviti naročanje? Predstaviti kompleksno storitev ameriškemu trgu? Zmanjšati ročno prepisovanje naročil med spletno trgovino, skladiščem in računovodstvom?

Cilj določa prioritete. Če je glavni namen zbiranje povpraševanj, sta jasna uporabniška pot in dobro zasnovan obrazec pomembnejša od desetih vsebinskih modulov. Če je rešitev operativno orodje za partnerje, so uporabniški računi, pravice dostopa in zanesljiva integracija pomembnejši od animacij na vstopni strani.

Ob vsakem cilju določite tudi merljiv rezultat. To ni vedno samo prodaja. Merilo je lahko krajši čas obdelave naročila, manj ročnega dela, več oddanih obrazcev, manj klicev zaradi nejasnih informacij ali možnost, da ekipa samostojno ureja določene vsebine. Brez meril uspeha je težko sprejemati dobre odločitve, ko je treba med razvojem izbirati med dvema možnostma.

Kaj mora zajemati vodnik za tehnično specifikacijo projekta

Specifikacija naj ne nastane kot neurejen seznam želja v e-pošti. Najbolje deluje, ko projekt razdeli na poslovni, uporabniški in tehnični pogled. Dokument ni nujno dolg sto strani, mora pa biti dovolj konkreten, da dve osebi isto zahtevo razumeta enako.

Pri večini spletnih projektov je smiselno jasno opisati vsaj naslednja področja:

• poslovni namen projekta, ciljne uporabnike in glavne uporabniške poti;
• strukturo strani ali modulov, vključno z vsebinami, ki jih bo naročnik urejal sam;
• funkcionalnosti, kot so obrazci, iskalnik, uporabniški računi, rezervacije, plačila ali konfiguratorji;
• integracije z zunanjimi sistemi, vire podatkov in odgovornosti posameznih ponudnikov;
• nefunkcionalne zahteve, med katere sodijo varnost, hitrost, dostopnost, varnostne kopije in podpora;
• merila prevzema, roke, odgovorne osebe ter proces potrjevanja posameznih faz.

Ključna razlika je med opisom funkcije in opisom njenega delovanja. »Uporabnik lahko odda povpraševanje« je začetek. Uporabna specifikacija pove tudi, katera polja obrazec vsebuje, katera so obvezna, komu se sporočilo pošlje, ali uporabnik prejme potrditev, kam se podatki shranijo, kdo ima do njih dostop in kaj se zgodi, če oddaja ne uspe.

Uporabniški scenariji razkrijejo skrite zahteve

Najbolj uporabna tehnika je opis konkretnih scenarijev. Namesto abstraktne zahteve »potrebujemo portal za partnerje« zapišite pot uporabnika: partner se prijavi, vidi cene glede na svoj status, naroči izdelek, preveri zgodovino naročil in prenese račun. Administrator nato spremeni ceno, potrdi naročilo ali uredi dostop novemu partnerju.

Tak opis hitro odpre prava vprašanja. Ali partnerji vidijo enake izdelke? Od kod prihajajo cene? Se zaloga prikazuje v realnem času? Ali račun nastane v spletni rešitvi ali v računovodskem sistemu? Kaj se zgodi, kadar integracija začasno ne deluje?

Scenariji naj pokrijejo tudi izjeme, ne le idealnega poteka. Pri trgovini to pomeni odpoved plačila, delno razpoložljivo zalogo, napačen naslov ali vračilo izdelka. Pri aplikaciji pa lahko pomeni pozabljeno geslo, potek uporabniškega dostopa, dvojni vnos podatkov ali prekinjeno povezavo. Ravno pri teh primerih se pogosto skrivajo stroški, ki jih površinska specifikacija spregleda.

Integracije niso dodatek na koncu projekta

Povezava z ERP, CRM, računovodskim programom, skladiščem ali dostavno službo lahko spletno rešitev spremeni iz lepe predstavitve v učinkovito poslovno orodje. Hkrati je integracija področje, kjer so predpostavke najdražje.

Za vsako integracijo opredelite, kateri sistem je glavni vir podatkov. Če se na primer izdelki in zaloga vodijo v poslovnem sistemu, naj specifikacija pove, ali spletna trgovina podatke prejema na nekaj minut, enkrat dnevno ali šele ob odpiranju strani. Pogostejše usklajevanje daje natančnejše podatke, vendar lahko poveča stroške razvoja, obremenitev sistemov in zahteve za podporo.

Preveriti je treba tudi tehnično pripravljenost zunanjega sistema. Ali ima dokumentiran vmesnik? Ali obstajajo omejitve dostopa, stroški uporabe ali kvote zahtevkov? Kdo je kontaktna oseba pri zunanjem ponudniku? Izvajalec spletne rešitve lahko prevzame razvoj povezave, ne more pa sam ustvariti dostopa do zaprtih podatkov ali odločati o spremembah tujega sistema.

Varnost, hitrost in administracija niso podrobnosti

Nefunkcionalne zahteve so lastnosti, ki jih uporabnik pogosto opazi šele, ko manjkajo. Počasna stran znižuje zaupanje in prodajno učinkovitost. Nejasno upravljanje uporabnikov ustvarja varnostno tveganje. Sistem brez varnostnih kopij in načrta podpore je problem, ki čaka na napačen trenutek.

Specifikacija naj zato opredeli, kdo ima administratorski dostop, katere vloge obstajajo in ali se pomembne spremembe beležijo. Pri obrazcih, uporabniških računih in naročilih je treba določiti, katere podatke rešitev zbira, zakaj jih potrebuje, kdo jih obdeluje in kako dolgo se hranijo. Če projekt cilja na ameriški trg, je smiselno zahteve za zasebnost, obvestila o piškotkih in pravila glede prodaje preveriti dovolj zgodaj, saj se razlikujejo glede na zvezno državo in poslovni model.

Enako velja za vsebinski sistem. Naročnik mora vedeti, katere strani, bloke, novice, izdelke ali medije bo lahko urejal sam. Prilagodljiv administrativni vmesnik je prednost, dokler podpira dejanski način dela. Zahteva po tem, da je »vse urejivo«, lahko projekt po nepotrebnem podraži in administracijo naredi manj pregledno. Boljši pristop je: samostojno uredite tisto, kar se redno spreminja, stabilne in tehnično občutljive dele pa zaščitite pred naključnimi posegi.

Merila prevzema preprečijo nejasen zaključek

Projekt ni pripravljen za objavo zato, ker je videti dokončan. Pripravljen je, ko preverjeno izpolnjuje dogovorjena merila. Ta morajo biti zapisana tako, da jih lahko obe strani preverita brez ugibanja.

Namesto »trgovina mora delovati na telefonu« določite, katere ključne poti se testirajo na mobilnih napravah: iskanje izdelka, dodajanje v košarico, vnos dostave, plačilo in potrditev naročila. Namesto »stran mora biti hitra« določite pričakovano raven optimizacije, obseg vsebin in pogoje merjenja. Rezultat je vedno odvisen tudi od fotografij, vtičnikov, oglaševalskih skript in strežniškega okolja, zato univerzalna številka brez konteksta ni dober dogovor.

Pred objavo načrtujte tudi obdobje uporabniškega testiranja. Naročnik naj preverja rešitev po scenarijih, ne naključno po posameznih straneh. Vse ugotovitve naj se zbirajo na enem mestu, razvrstijo po prioriteti in ločijo med napako glede na specifikacijo ter novo željo. Oboje je legitimno, vendar zahteva drugačen odziv: napako je treba odpraviti, nova funkcionalnost pa potrebuje oceno vpliva na rok in proračun.

Specifikacija je dokument, ki projekt drži skupaj

Dobra tehnična specifikacija ni dokument, ki ga ekipa enkrat podpiše in pozabi. Med oblikovanjem, razvojem in testiranjem postane skupna referenca za odločitve. Ko se pojavi nova ideja, omogoča preprost pogovor: ali je to že del dogovorjenega obsega, kakšno poslovno korist prinaša in kaj zahteva v zameno?

Pri Moxy Web tak pristop pomeni, da se oblikovanje, razvoj, integracije in dolgoročna podpora ne obravnavajo kot ločeni otoki. Spletna rešitev mora biti estetsko dodelana, tehnično premišljena in dovolj preprosta za vsakodnevno uporabo vaše ekipe.

Najboljši čas za težka vprašanja je pred prvo vrstico kode. Zberite procese, primere iz resničnega dela, dostop do zunanjih sistemov in ljudi, ki bodo rešitev dejansko uporabljali. Tako specifikacija ne bo samo opis spletnega projekta, temveč trden načrt za digitalno rešitev, ki podpira vaše podjetje tudi po objavi.