Sedem pasti, ki lahko pokopljejo vašo spletno prenovo

Po raziskavah dobra polovica spletnih projektov nasede - ali gre cena v nebo ali pa sploh niso dokončani. A zelo redki propadejo zaradi neizkušenosti razvojne ekipe. Glavna težava je nedorečenost - različni deležniki imajo različne predstave, kako naj bi projekt potekal, kdo je za kaj odgovoren in kaj naj bi bil sploh rezultat projekta.

V nadaljevanju je sedem točk, bolje rečeno čeri, na katerih lahko nasede vaš spletni projekt, če ne boste pozorni. In nekaj predlogov, kako pravočasno zaznati težave, da boste vašo spletno barko srečno pripeljali do cilja.

1. Nerealistični cilji

Uporabniki ne bodo uporabljali aplikacije zgolj zato, ker si vi to želite. Če v njej niso prepoznali koristi, je ves trud zaman. Podobno z novo spletno trgovino ne boste kar podvojili prometa ali pa avtomatično zlezli iz šestnajste strani na prvo mesto v Googlovih rezultatih iskanja. 

Cilji naj bodo jasni, ambiciozni, vendar realistični. Podobno velja za roke. Zaradi preoptimističnih rokov projekt ne bo prej gotov, samo živčnosti in slabe volje bo več.

Kako prepoznati simptome:

1. Izhodišče projekta je bolj spisek želja kot objektivne poslovne analize
2. V ospredju debate so želje uprave namesto potrebe uporabnikov
3. Glavni kriterij je odobravanje direktorja

Zdravilo: 

Argumentacija na osnovi uporabniških podatkov, analize poslovnega okolja in razpoložljivih virov. Objektivna analiza je podlaga vseh nadaljnih odločtev. 

2. Nerealne predstave o ceni projekta

Bolj kot je aplikacija kompleksna, težje je določiti ceno razvoja. Če še nimate izdelane funkcionalne specifikacije, bodo začetne ponudbene vrednosti izvajalcev precej okvirne. Tu je nevarnost, da se oklenete najnižje cene, ko se debata o funkcionalnostih bodoče aplikacije še niti ni dobro začela. Začetne ponudbe naj služijo bolj za predstavo o redu velikosti kot o dejanski ceni.

Kako prepoznati simptome:

1. Površna analiza poslovnih, uporabniških in tehničnih zahtev
2. Nejasna predstava o končnem rezultatu projekta
3. Dolg spisek želja, ki še narašča -  ob fiksnem proračunu.
4. Ponudbe izvajalcev se razlikujejo za nekajkrat

Zdravilo:

1. Dvofazni pristop

Pri večjih projektih je razvoj najbolje projekt razdeliti v dve fazi: na izdelavo koncepta in izvedbo. Za izdelavo koncpeta se z izvajalcem dogovorite za fiskno ceno. Rezultat te faze bo osnova za izdelavo predračuna izvedbe.

2. Prilagoditev delovanja

Če nimate časa za poglobljeno analizo bo najbolje, da obrnete zgodbo in izvajalcem sporočite okviren budžet. S tem jim nakažete nivo zahtevnosti naloge, nato pa izberete tistega, 

• Za katerega v toku pogajanj ocenite, da vas razume in je tehnično dorasel nalogi
• vam ponudi največji obseg storitev za dano ceno. 

Priporočamo: Koliko stane spletna trgovina?

Šele ko se bosta z izvajalcem zakopali v drobovje projekta, se bo pokazala vsa kompleksnost, kar lahko vpliva na ceno. Zato se vnaprej dogovorite o možnosti odstopa od pogodbe po fazi načrtovanja, v kolikor bi cena presegla okvire vaših zmožnosti. Ker izvajalcu ta scenarij ni v interesu, se bo trudil, da ostane v mejah sprejemljivega. 

Priporočamo: Funkcionalna specifikacija - osnova uspešnega spletnega projekta

3. Slaba komunikacija

Informacija nastane pri prejemniku. Meni je jasno, kaj sem želel s tem povedati, vsem, ki to berete, pa morda ne. Vedno se prepričajte, če je sogovornik razumel vaše sporočilo, da ne bo prihajalo do nesporazumov. Nejasna komunikacija vodi v konflikte, podvojeno delo in zamude na projektu.

Kako prepoznati simptome:

1. Pogosti konflikti znotraj projektne ekipe
2. Ni jasno, kdo je za kaj zadolžen
3. Delo se podvaja, pogosto z različnimi rezultati
4. Ekipa ne uporablja dogovorjenih komunikacijskih poti
5. Kopičenje dela ob nespremenjenem obsegu projekta

Zdravilo:

Redni timski sestanki, kjer se pregleda napredek na projektu in spodbudi člane ekipe, da odkrito spregovorijo o težavah in pomislekih. Prej ko boste razrešili posamezne dileme, manjša bo škoda za projekt kot celoto.

Jasna komunikacija brez pretirano čustvenih reakcij. Tudi v konfliktnih situacijah ostanemo mirni in komuniciramo jasno. Težko bo jutri sodelovati z nekom, ki ste ga danes ozmerjali, ker so vam popustili živci. Na projektu potrebujete motivirane ljudi, tudi na strani izvajalca. 

Konstruktivna kritika
Tudi s pohvalami ni treba pretirano varčevati. Potrebujete motivirano ekipo. K dobremu vzdušju pripomore tudi zdrava doza humorja.

Spletna orodja za vodenje in timsko delo kot sta Basecamp in Trello za bolj preproste projetke in Jira, Clickup ali Redmine za bolj zahtevne. Ta orodja omogočajo centralno organizirano komunikacijo, feedback in vpogled v zgodovino reševanja posameznih problemov. Tu so zabeležene tudi vse operativne odločitve. S tem ima tudi naročnik pregled nad dogajanjem.

4. Nejasne vloge in odgovornosti 

Izvajalec na vaši strani potrebuje kompetentnega sogovornika. Nekoga, ki razume splet, zna reševati probleme in se hitro odločiti. Skupaj z vodjem projekta na izvajalčevi strani bosta razdelila vloge članom vsak svoje ekipe. Izogibajte se pasivnemu govoru: “Treba je pripraviti…” Kdo mora pripraviti? Pomembno je, da člani ekipe poznajo svoje zadolžitve pa tudi naloge kolegov, da vedo na koga se obrniti v primeru težav. 

Simptomi:

1. Preveč ljudi skupaj odgovornih za preveč stvari
2. V opredelitvi nalog se uporablja pasivni način ali množina (se mora, moramo pripraviti) brez jasnih navodil kdo je za kaj zadolžen
3. Vodja projekta se izogiba odločitvam in se izgovarja na “šefe”
4. Pometanje težav pod preprogo

Zdravilo:

1. Oba vodja projekta, na strani naročnika in izvajalca, morata imeti pooblastila za operativno ukrepanje in znata jasno komunicirati
2. Vsi člani projektne ekipe imajo jasno opredeljene vloge na projektu
3. Vsaka večja naloga ima odgovorno osebo, ki ve, kaj so njene zadolžitve

5. Slabo pripravljeni podatki in vsebine

Content is always late. Vsebina pregovorno zamuja. Če temu dodamo še neustrezne formate in neažurne podatke, raztresene po neznanem številu strežnikov, dobimo popolno nevihto. Naročnik “misli” da ima podatke pripravljene, in šele ko bi jih moral predati, ugotovi, da so pomanjkljivi, neažurni, da se podvajajo, ali pa se jih preprosto ne da izvoziti. Čas je za paniko.

Kako prepoznati simptome:

1. Nihče ni odgovoren za vsebine
2. Postopek priprave vsebin ni dorečen
3. Ni načrta migracije podatkov
4. Migracija podatkov ni bila testirana

Zdravilo: temeljita priprava podatkov in načrt migracije. 

Pripravite načrt, kako boste  preverili kakovost in ustreznost podatkov. Če boste vse podatke prenesli naenkrat, lahko priprava poteka tudi nekaj mesecev, saj je potrebno podatke prečistiti, poenotiti in postopek temeljito testirati. Če si lahko privoščite, da nekaj časa vzporedno vzdržujete staro in novo rešitev, se raje odločite za migracijo po korakih, da zmanjšate tveganja. Celoten postopek bo tako krajši, saj imate opravka z manjšim obsegom podatkov.

6. Spremembe na projektu

Spremembe so v tem poslu edina stalnica. Zahteve naročnika, uporabnikov, regulatorjev, spremembe v tehničnem okolju in zakonodaji lahko kadarkoli spremenijo načrtovan potek projekta. Tega se je dobro zavedati in se na to možnost ustrezno pripraviti. Vem, predvidevanje nepredvidljivega zveni paradoksalno. kljub temu pa že zavedanje o možnosti sprememb omogoča oblikovanje alternativnih scenarijev in vnaprejšnji dogovor o postopkih v primeru spremembe, s tem pa  lažje obvladovanje situacije. Manj bo improviziranja, konfliktov in nepotrebnih stroškov.

Simptomi:

1. Na projektu ni nobene rezerve.
   Projekt bo uspešen samo, če bo šlo vse kot po maslu. Kar je skregano z realnostjo.
2. Različne predstave o obsegu in vplivu spremembe na delovanje rešitve
   Zaradi soodvisnosti posameznih komponent lahko ena sprememba povzroči verižno reakcijo in vpliva na komponente sistema, ki na prvi pogled s spremembo nimajo nobene zveze.
3. Nerazumevanje vpliva spremembe na potek projekta 
   Ni nujno, da se projekt zamakne samo za čas, potreben za njeno izvedbo, na primer en teden. Kaj pa če sprememba na primer zahteva vključitev strokovnjaka za podatkovne baze, ki je prost šele čez en mesec? 
4. Nepravočasno upoštevanje sprememb
   Morda lovite rok in želite izvedbo sprememb šele po objavi. A lahko se zgodi, da bo kasneje izvedba spremembe bistveno dražja (ker sprememba vpliva na vse faze, ki so izvedene po njej). Povedano drugače - če imate težave pri temeljenju hiše, jih je smiselno odpraviti v fazi temeljenja in ne šele potem, ko hiša že stoji. 

Zdravilo:

1. Rezerva (finančna in časovna) za nepredvidena dela (vsaj 10 -15%)
2. Analiza spremembe in njenega vpliva na projekt iz vseh zgornjih vidikov
3. Izdelava alternativnih scenarijev reševanja spremembe
4. Upoštevanje razpoložljivosti potrebnih strokovnjakov

7. Nedorečen postopek prevzema

Projekt je v zaključni fazi, manjka še kljukica naročnika in gremo v objavo. A kako veste, da je rešitev dobro izvedena? Kaj je merilo uspeha?

Mnogi naročniki imajo na tej točki težave s podpisom prevzemnega zapisnika, ki je praviloma pogoj za izstavitev računa. Bojijo se, da bo po podpisu izvajalec pobral denar in postal kronično neodziven, naročnika pa pustil samega s kopico problemov in na pol delujočo aplikacijo. Takšni primeri se, na žalost, dogajajo.

Simptomi 

Ni jasno, kako naj bi končna rešitev delovala oz. kaj so kriteriji za prevzemV fazi načrtovanja se dogovorite, kaj so uporabniške zahteve, kaj so ključne komponente rešitve in kaj so pričakovani rezultati (npr: uporabnik se lahko registrira. Registriran uporabnik lahko oblikuje seznam priljubljenih izdelkov. Uporabnik se lahko prijavi na dogodek. Uporabnik lahko odpove najem do pet dni pred datumom prevzema, itd.) Ti kriteriji so nato osnova za vrednotenje rezultatov razvoja.

Naročnik ne želi podpisat prevzemnega zapisnika, zahteva pa objavo
Takšna zahteva ponavadi izhaja iz strahu, da se bodo šele po objavi odkrile “resnične” napake.  A če končno uporabniško testiranje poteka v produkcijskem okolju, se pravi na delujoči aplikaciji in v istem okolju v katerem bo kasneje na voljo uporabnikom, je strah odveč.

Projekt je končan, prevzemni zapisnik pa ni podpisan
Naročnik prevzemnega zapisnika noče podpisati, ker manjka še nekaj malenkosti. Tu naj velja načelo sorazmernosti. Selitve v novo stanovanje verjetno ne boste odklonili, ker v omari manjkajo obešalniki. Drugače je, če manjkajo vhodna vrata. 

Čeprav vas ščiti garancija, se z izvajalcem dogovorite še za kak mesec kalibracijskega obdobja takoj po objavi. Takrat so razvijalci z mislimi še na projektu in bodo hitro “polovili” razne hrošče in izvedli manše popravke. Več kot 80% še neodkritih napak sporočijo uporabniki v tednu ali dveh po objavi. 

Zdravilo:

1. Uporabniško testiranje
2. Vnaprejšnji dogovor o kriterijih prevzema
3. Dogovor o postopku prevzema
4. Kalibracijska doba (babysitting) po objavi
5. Garancijska doba
6. Zaupanje med partnerjema

Razvoj spletne rešitve ima kup kolesc, ki lahko v vsakem trenutku zaribajo. Splača se jih dobro podmazati, preden zaženemo mašino.