Treba li tražiti fiksnu ili varijabilnu cijenu kad se javljate na natječaj za IT projekt?
U našoj industriji sasvim je uobičajena jedna praksa za koju smatram da je loša i šteti uspješnosti IT projekata. Radi se o tome da za veće projekte naručioci obično otvaraju natječaje u kojima se traže ponude s već formiranim cijenama. Ovakav pristup je sasvim logičan jer kako planirati budžet ako vam izvođač ne može unaprijed reći koliko posao košta? Problem je, naravno, u tome što se tu ne radi o narudžbi npr. građevinskog materijala. Kad naručujete kamion čeličnih vijaka vi točno znate koliko vijaka trebate, koje su im dimenzije i koje karakteristike materijal od kojeg su napravljeni mora imati. Firme koje se jave na vaš natječaj, s druge strane, znaju točno koliko im materijala i vremena treba da bi proizveli te vijke. U IT svijetu praksa je pokazala da naručitelji redovno ne znaju što zapravo žele i tipična je pojava da se zahtjevi počinju kristalizirati tek nakon što kupac ugleda prvu verziju vašeg softverskoj rješenja. Problem izvođača je pak što materijale i alate u IT svijetu ne poznajemo tako dobro kao materijale i alate potrebne za izradu čeličnih vijaka. Naša civilizacija sa željezom radi već preko 2000 godina dok se informatika pojavila u zadnjih 50 godina. Osim ako već niste radili na vrlo sličnom projektu, za vaš novi projekt bit će jako teško procijeniti resurse, vrijeme i na kraju cijenu projekta.
Kako pristupamo ovom problemu? Često izvođač svjestan da ne može kvalitetno procijeniti potrebno vrijeme i resurse napravi neku grubu procjenu potrebnog vremena i novca pa te brojke jednostavno pomnoži s nekim faktorom koji mu ulijeva sigurnost. Na taj način, u slučaju da projekt bude izveden na vrijeme, zapravo vara kupca. S druge strane, smanjuje vlastiti rizik ako se projekt oduži (što je vrlo čest slučaj). Jedan od tipičnih pristupa je i pisanje ugovora po kojima se skupo naplaćuje svaka promjena nakon što je dizajn sustava završen i započeta je implementacija. Na taj način se tjera kupca da što preciznije definira zahtjeve. Kao što sam spomenuo, kupac često zapravo ne zna što želi ali je prisiljen prihvatiti isporučeni sustav prema svojim prvobitnim zahtjevima. Rezultat može biti i da se svježe kupljeni sustav niti ne koristi. Istina je ipak negdje u sredini. Neke statistike (poznati i kontroverzni "Chaos Report") pokazuju da se u organizaciji koja kupuje sustav oko 50 posto funkcionalnosti isporučenog sustava ne koristi.
A sad, evo i malo vedrijih vijesti. Agilne medotodogije ("Agile methods") koje su se pojavile u zadnjih 10 godina mi se čine kao rješenje koje je u ovom trenutku najbolje što imamo. Ima ih raznih ali zajedničke karakteristike su im prihvaćanje da su promjene u planovima neizbježne, kratki ciklusi isporuke u kojima se isporučuje potpuno funkcionalni sustav, te, možda najvažnije, aktivno sudjelovanje kupca u stvaranju novog sustava. Osnovna ideja je da se kupcu isporučuje sustav koji je njemu vrijedan. Zbog toga kupac mora biti stalno prisutan i sudjelovati u izradi sustava. Kratki ciklusi isporuke garantiraju da kupac vrlo rano počinje skupljati praktično iskustvo sa svojim novim sustavom i može stvarati jasniju sliku o tome što mu zapravo treba. S druge strane, mnogo kratkih ciklusa olakšava praćenje performansi tima, a time i omogućuje sve kvalitetnije procjene trajanja cijelog projekta. Ako se ispostavi da nema dovoljno vremena za implementaciju svih traženih svojstava sustava jedno od rješenja je da kupac odluči od kojih elemenata sustava će odustati. To ne znači da će ostati s neupotrebljivim sustavom jer u svakom ciklusu mu je isporučen sustav koji radi (naravno, sa smanjenom funkcionalnošću). Krajnji rezultat bi ipak trebalo biti veće zadovoljstvo kod kupca jer je sudjelovao u svim važnim odlukama, a zbog pristupa dizajnu i implementaciji ima sustav koji mu je koristan.
Agilni pristup IT projektima nije za svakoga. Potrebno je puno energije i volje s obje strane, i kupca i izvođača. To je vrlo intenzivan proces koji jednostavno ne odgovara svačijem mentalitetu bez obzira da li govorimo o naručiteljima ili izvođačima projekta. No, ako se desi kombinacija kupca i izvođača koji su spremni aktivno sudjelovati u svim fazama projekta da bi stvorili što veću vrijednost za kupca tada je ovaj skup metodologija vrlo zanimljiv kao pristup organizaciji IT projekta.
Na kraju, odgovorit ću na pitanje s početka članka: osim ako nisam prisiljen drugačije, ja naplaćujem po satu. Veće projekte je lako razlomiti na manje cjeline pa je za takve cjeline onda lakše napraviti procjenu trajanja odnosno cijene. Kupac tako ipak može dobiti neku sliku o vrijednosti cijelog projekta ali mora biti spreman na promjene. Ako se nakon prvih nekoliko iteracija ispostavi čak i da je cijeli projekt nepotreban ili neizvediv lakše je, i po kupca jeftinije, odustati ranije nego čekati kraj projekta da bi se to otkrilo.
Korisni linkovi:
http://en.wikipedia.org/wiki/Agile_software_development
http://it-project-failures.blogspot.com/
Why technology projects fail
Standish Group Chaos Reports Revisited
