Vedno so me maltretirali z ene strani programerji in z druge strani projektni vodje: “Specifikacije, specifikacije, specifikacije!” Oboji namreč živijo v iluziji, da je s spletnimi stranmi in drugimi internetnimi aplikacijami tako kot z načrtovanjem na primer hiše: daš arhitektu, da si zamisli, na podlagi tega ugotoviš, koliko bo stalo in potem vržeš vse skupaj gradbeniku, da zadevo naredi - ob tem predvidiš še malo odstopanj in požreš nekaj sprememb načrtov, pa je.
Ampak pri nas ne gre tako. Funkcionalne specifikacije in podobni dokumenti imajo zgolj eno uporabno vrednost - vsem udeležencem v projektu razložijo, zakaj pri stvari gre. Daleč od tega, da bi lahko služili kot osnova za časovni ali finančni načrt, ker so ali preveč splošni, da bi lahko iz njih dobil kake relevantne informacije, ali preveč natančni (če jih delajo kontrol friki), da bi na koncu imeli kakršnokoli podobnosti z dejanskim izdelkom.
Obstajajo pa precej boljši načini, da sodelavcem dopoveš, zakaj pri projektu gre. Po mojih izkušnjah je najbolj učinkovito narisat konceptualno strukturo podajanja informacij, ki ni nujno točna, ampak odraža koncept in način delovanja aplikacije, nato pa pripravit čimveč wireframeov, s katerimi rešuješ specifične logične in navigacijske probleme. Na osnovi tega lahko sodelujočim v projektu (najbolje osebno) predstavljaš potrebe in izhodišča ter skupaj z njimi iščeš rešitve in razvijaš prototip izdelka. Ko imaš prototip, pa se lahko začne programiranje. In šele v tej točki imamo realno osnovo za oceno stroškov izvedbe.
Končno sem našel somišljenike in to ne kjerkoli - tako razmišljajo pri 37 Signals.
Don’t write a functional specifications document. Why? Well, there’s nothing functional about a functional specifications document.
15 responses so far ↓
1 Gregorg // Jan 18, 2006 at 19:29
Evo, končno se je en opogumil in povedal accountom, kar jim gre. Ni več daleč čas, ko jim bomo povedali še za ostale nefunkcionalnosti in se bodo uzrli v nefunkcionalnem ogledalu lastne nefunkcionalnosti. Power to the people!
2 jure // Jan 18, 2006 at 19:45
Tole je prejšnjič na isto temo citiral Ozi iz Cluetrain manifesta:
“A couple of weeks after arriving, he [new Chief Operating Officer] called me into his office to bond with me and also, not incidentally, to find out when the next wave of marketing materials would be ready. I said I didn’t know. Why not? he demanded. I replied that I had a really well-motivated team of professionals who were moving heaven and earth to get it all done; it would be done at the earliest possible moment.”
“Deadlines” so v našem poslu bolj “livelines”.
In pa, niso vsega krivi tvoji accounti, Gregorg - brez nerealnih rokov se žal ne da prodajti projektov.
3 Boštjan // Jan 18, 2006 at 20:44
Se povsem strinjam z napisanim, pa vendar … kolikokrat si prišel do zadnje točke, ki je dala realno osnovo za oceno stroškov izvedbe?
Ne rečem, ko gre za lastne aplikacije, pri naših domačih naročnikih pa se mi še ni zgodilo, da ne bi bilo potrebno, pred vsakim resnejšim načrtovanjem, postaviti ceno, ki večinoma ni dopuščala kakih odstopanj, tudi če se je izkazalo da je bil projekt že v osnovi zgrešen.
Mogoče pa premalo delamo na izobraževanju naročnikov? Če prav pomislim imam v bistvu najslabše izkušnje z vodji projektov na oglaševalskih agencijah, ki v zadnjem času ne ločijo več med flash minisite-om in predstavitvenim cd-jem. Na koncu je izvedba in funkcionalnost izdelka povsem drugotnega pomena, saj imamo toliko več opraviti z vsem ostalim.
4 Blaž // Jan 19, 2006 at 8:58
e, vidiš, nekaj svetlih misli. naročnike JE treba izobrazit. tud tko je: več kot vejo, več lahko naročijo. zato jim tud pravimo naročniki :)
5 Zoran // Jan 19, 2006 at 14:16
Fajn. Zdaj moraš to samo še naročnikom dopovedat, pa smo zmagali:) Se pa bojim, da se s tem ponavlja 50 let stara zgodba konflikta med agencijsko kreativo in naročnikom, pa kakor koli se s tem, kar si napisal, lahko strinjam.
6 jure // Jan 19, 2006 at 19:17
Ne vem - tole izobraževanje naročnikov. Malo sem tega že sit. OK, leta 1999 je bilo normalno, da naročniki nič ne razumejo, saj tudi trg še ni bil razvit. Danes bi pričakoval, da vsaj poznajo svojo konkurenco in sami vedo, kako se v njihovi panogi uporablja internet. Naša naloga pa je narediti kreativni in aplikativni presežek ter izdelati sajt/aplikacijo, ki ustreza potrebam in resursom naročnika… ne pa, da moramo odkrivati zadeve, ki bi nam jih naročniki morali podati v brifu..
No, ampak mene naročniki niti ne jezijo preveč. Pa tudi vodje projektov ne - vem, da ne moreš prodati izdelka, če kupcu ne poveš, koliko stane, kaj dela in kdaj ga bo dobil. Kritika je bila bolj usmerjena na produkcijske in kreativne ekipe, ki nekako ne najdejo pravega jezika za medsebojno komunikacijo in ne razumejo, da dobri izdelki nastanejo samo, če se obe polji tesno prepletata… to pa neizbežno pomeni več usklajevanja, improviziranja, poskusov in napak ter pogosto dejstvo, da je treba kakšno stvar narediti dvakrat - na primer: najprej sprogramirati funkcionalni prototip zaradi načrtovanja in potem, bolj ali manj, še enkrat iz nič postaviti isto stvar, da deluje tako kot je treba. Na tej točki največkrat naletim na odpor - enkrat z ene, drugič z druge strani.
7 Gregorg // Jan 19, 2006 at 23:03
No no, dejmo že enkrat presečt to zgovarjanje na naročnike. Naročniki niso (ponavadi) čisto nič krivi, če le ni vmes predmenstrualni sindrom ali pomanjkanje sexa.
Kaj hočem reči? Če bi meni kdo tako bulšitiral, kot je spletna industrija to počela zadnjih šest let in po večini to počne še sedaj, se ne bi weba “ni remote kontrolerjem taknil”. Dejstvo, da imamo pred sabo prestrašene in nesamozavestne kliente, zaradi česar se potem stvari res znajo neznansko zaplesti, lahko pripišemo zgolj in samo temu, da jim NIKAKOR nismo znali našega biznisa pojasniti tako preprosto, kot v resnici je. Raje smo se zapletali v neke novotvore tipa baze, CM-ji, kode, skripte in podobne brezvezarije. Kot da bi se print dizajnerju dalo ukvarjati s tem, kako klientu pojasniti principe tiskanja - in kot da bi bilo to kakorkoli pomembno…
Drugo je dejansko to, o čemer govori Vižintinov, bolj odnos med funkcijami v projektnih ekipah in odvečno dokumentacijo in specifikacijami, ki jih nekateri dojemajo kot “opravičilo”, s katerim bodo lahko klientu pojasnili cifre na računu. Pa tudi o tem bi se dalo debatirati - dokumentacija kljub temu ima določene funkcije, solata jih nima, zato je ključno vprašanje, kaj je dokumentacija in kaj solata?!
8 Zoran // Jan 23, 2006 at 14:09
Odgovor na Gregorgovo vprašanje je preprost: polije z nečim mastnim in nečim kislim, pa poskusi in je vse jasno:)
Strinjam se z obema, Juretom in Gregorgom. Na eni strani imamo praviti s problemom, ki ga cela komunikacijska industrija ni uspela zares rešit in že pred 20 leti so v Angliji uvedli osebo, ki se mu reče Account planner ali Strategic account planner, njegova naloga pa je ugotoviti, kaj lahko zares agencija prispeva k rešitvi naročnikovega problema. In najprej mora ugotoviti, kaj je njegov problem. Potem naredi brif, za oba.
Da kreativna ekipa potem upošteva okvire brifa in budžeta je že bolj samoumevno, pri nas pa ne še povsem, zato nastanejo dodatni problemi.
9 Gregorg // Jan 23, 2006 at 15:02
Jp, točno na to temo sva imela z Juretom v soboto (po Vižintinovi odlični škarpini v soli :)) eno dolgo debato, katere osnovna misel je bila, da ima slovenski advertising in skupaj z njim spletna industrija percepcijo projektnih, ne pa produktnih ali client vodij, kar ustvarja povsem neustrezno organizacijo dela med resorji in funkcijami na ravni podjetja.
To stanje pa verjetno ni povezano samo s vprašanjem neke slabe ali neustrezne organizacije dela, ampak verjetno tudi s specifičnimi karakteristikami celotnega segmenta account managerstva v naši ljubki državici, kjer je kvaliteta storitve, produkta, sodelovanja ipd. v najboljšem primeru šele sekundarnega pomena.
Ekola, tale debata mi je prav všeč.
10 Zoran // Jan 23, 2006 at 21:06
E, tudi meni, še raje bi jo imel (debato) skupaj s škarpeno:) Težava ima po mojem en del korenin v slo advertisingu in njegovemu načinu vodenja klientov, drugi del pa v tem, da je spletna industrija od advertisinga ravno toliko različna, da je bias še večji, vse skupaj pa nadgradi IT komponenta, in sicer na eni strani z njenim (projektnim) načinom vodenja, na drugi strani pa z nerazumevanjem vsebine (problema agencija, dela naročnik). Advertising vsaj približno govori isti jezik. In smo na začetku, kot se klobasi spodobi:)
11 jure // Jan 25, 2006 at 11:05
Bila je orada in ne škarpena. Naslednjič pa se lahko dobimo v večjem številu in pripravim klobase v solati :)
12 Gregorg // Jan 25, 2006 at 20:22
Škampe na buzaro!
13 IceBreakr // Feb 13, 2006 at 14:06
In… katere specifikacije so vam bolj všeč, tiste na eni A4 strani ali 50 takih straneh? :)
14 Tomasz // Feb 14, 2006 at 14:59
Kar se mene tiče, problem s specifikacijami izhaja iz tega, ker se projekte še vedno vidi skozi skupek opravil (taskov), ki jih lahko uporabnik izvede, ne pa - kot bi to moralo biti -s kakšnim namenom oseba sploh uporablja to “orodje”. Zato jaz zadnje čase poskrbim pretežno za to, da je vsem vpletenim jasno, kaj je “point” tega in pripravljam samo osnovno specifikacijo (tri A4 liste). Potem pa samo še testing&tweaking.
Itak potem, ko pripraviš specifikacijo, naročnik spremeni 40%, programerji 25%, ko pa pride vsebina, pa od specifikacije ostane bore malo.
15 jure // Feb 14, 2006 at 15:11
Ha, ne morem verjeti, da ta post še vedno dviguje prah. Definitivno najuspešnejši v moji kratki zgodovini strokovnega bloganja.
Leave a Comment