Fiksna cijena ili naplata po satu? Kako ugovoriti izradu softvera, a ne platiti dvaput

Na stolu su vam dvije ponude za isti sustav. U prvoj piše 60.000 €, fiksno. U drugoj 95 € po satu, uz procjenu od 500 do 700 sati, dakle negdje između 47.500 i 66.500 €. Prva djeluje sigurnije, jer znate broj.

Često nije. Fiksna cijena ne uklanja rizik pogrešne procjene. Samo odlučuje tko ga snosi i kako ga plaćate.

Što koji model stvarno znači

Fiksna cijena: izvođač obećava definirani rezultat za definiranu cijenu. Ako posao potraje dulje od procjene, plaća izvođač. Zato u cijenu dodaje rezervu i čuva dogovoreni opseg: svaka izmjena postaje zahtjev za izmjenom s vlastitom ponudom.

Naplata po satu (time and materials): plaćate stvarno odrađeno vrijeme po dogovorenoj satnici. Ako posao potraje dulje, plaćate vi. Zauzvrat možete u bilo kojem trenutku promijeniti smjer, bez ponovnog pregovaranja ugovora.

	Fiksna cijena	Po satu
Tko snosi rizik procjene	Izvođač, uračunat kao rezerva	Vi
Izmjene tijekom projekta	Zahtjev za izmjenom i nova ponuda	Novi prioritet na popisu posla
Što treba prije početka	Detaljna specifikacija	Jasan cilj i prioriteti
Kontrola budžeta	Jedan broj, dok se ništa ne mijenja	Mjesečni limit i redoviti pregledi
Za što je izvođač plaćen	Dogovoreni opseg u što manje sati	Posao koji vam se isplati plaćati i dalje
Najbolje odgovara	Malom, jasno omeđenom poslu	Svemu što će se usput mijenjati

Zašto fiksna cijena često ispadne skuplja

Procjena softvera je teška, svima. Istraživanje McKinseyja i Sveučilišta u Oxfordu na više od 5.400 IT projekata pokazalo je da veliki projekti u prosjeku prekorače budžet za 45 %, a rok za 7 %, uz 56 % manje vrijednosti od očekivane. Fiksna cijena procjenu ne čini lakšom. Samo prebacuje raspravu o procjeni u ugovor.

U praksi se to vidi na četiri načina:

1. Rezerva. Izvođač koji jamči broj dodaje maržu za nepoznanice. Plaćate je i kad sve prođe glatko.
2. Zahtjevi za izmjenama. Poslovni softver se gotovo uvijek mijenja kad ga korisnici vide. “U izvještaju treba još jedan stupac” je dva dana posla, a u projektu s fiksnom cijenom to je nova ponuda, novo odobrenje i novi račun.
3. Uštede tamo gdje ih ne vidite. Kad sati ponestaje, štedi se ondje gdje nitko ne gleda na primopredaji: testovi, dokumentacija, sigurnost.
4. Rasprava na kraju. Je li ovo greška ili izmjena? Svaka nejasna rečenica u specifikaciji postaje rasprava baš kad želite krenuti u produkciju.

Postoji i pravna razlika. U Njemačkoj je projekt s fiksnom cijenom obično Werkvertrag (§ 631 BGB): izvođač duguje rezultat, a vi ga formalno preuzimate (Abnahme, § 640 BGB). Naplata po satu obično je Dienstvertrag (§ 611 BGB): izvođač duguje rad, a ne određeni rezultat. To mijenja jamstvo i to tko snosi koji rizik. Slično razlikovanje postoji i u drugim zemljama. Ovo nije pravni savjet, ugovor neka pogleda odvjetnik.

Kada fiksna cijena ima smisla

• Mali, jasno omeđen posao. Jedna integracija, jedan izvještaj, nadogradnja s .NET-a 8 na .NET 10 kad je opseg poznat.
• Specifikacija koja se neće mijenjati. Na primjer, sučelje koje propisuje regulator ili drugi sustav.
• Analiza na početku. Nekoliko tjedana da se razumiju procesi, napišu zahtjevi i procijeni ostatak. To je najsigurnije mjesto za fiksnu cijenu.

Kada naplata po satu ima smisla

• Zahtjevi će se mijenjati kad korisnici vide prvu verziju. Kod poslovnog softvera to je gotovo uvijek.
• Dugoročni razvoj i održavanje, gdje posao zapravo nikad ne završava.
• Preuzimanje postojećeg sustava, gdje nitko ne zna koliko se krije u kodu. Više o tome u članku o preuzimanju .NET aplikacije.

Kombinacija koja u praksi radi najbolje

1. Korak 1Analiza po fiksnoj cijeni
2. Korak 2Prva verzija, mjesečni limit
3. Korak 3Demo svaka dva tjedna
4. Korak 4Razvoj u mjesečnim blokovima

Prva odluka ima poznatu cijenu: analiza od jednog do tri tjedna, nakon koje imate zahtjeve, grubu arhitekturu i procjenu u rasponima. Od tada posao ide po satu s mjesečnim limitom, a svaka dva tjedna vidite softver koji radi. Nikad niste vezani za više od mjesec dana, a ako suradnja ne funkcionira, odlazite s analizom i kodom.

Kako se zaštititi kod naplate po satu

• Mjesečni limit napismeno. Izvođač vas upozori na 80 % budžeta, a ne kad ga potroši.
• Demo svaka dva tjedna. Softver koji radi, a ne izvještaji o statusu.
• Sati po zadatku. Svaki sat vezan uz zadatak koji možete otvoriti.
• Kod u vašem repozitoriju od prvog dana.
• Mjesečni otkazni rok. Ako ne ide, možete stati.
• Procjene u rasponima, redovito osvježene. “Tri do pet tjedana” je pošteno. “Točno 27 dana” nije.

Crvene zastavice u ponudi s fiksnom cijenom

• Cijena bez detaljne specifikacije. Izvođač je procijenio vlastite pretpostavke, a ne vaš sustav.
• “Izmjene se naplaćuju posebno” bez satnice i bez postupka.
• Nema kriterija prihvaćanja. Nitko ne zna kad je posao gotov.
• Ni riječi o testovima, dokumentaciji i primopredaji.
• Cijena daleko ispod ostalih. Razlika se obično vrati kroz zahtjeve za izmjenama.

Realne raspone cijena pronaći ćete u članku koliko košta izrada poslovne aplikacije, a dnevne cijene u članku o satnici .NET programera.

Kako napisati specifikaciju koju dobavljači mogu pošteno procijeniti, pišemo u članku o specifikaciji softvera.

Kako mi radimo

Upravo ovako radimo. ProCoding je .NET studio iz Splita, a gradimo i održavamo poslovne aplikacije u .NET-u i Blazoru. Obično počinjemo kratkom analizom po dogovorenoj cijeni, a zatim radimo u mjesečnim blokovima s limitom, s demom svaka dva tjedna i kodom u vašem repozitoriju od prvog dana, uz mogućnost otkaza iz mjeseca u mjesec. Za veće projekte možete dobiti i freelance .NET developera na puno radno vrijeme dok traje projekt. Prvi korak je besplatan razgovor od 30 minuta, u kojem pogledamo vaš projekt i ponude koje već imate.

Izvori

• Delivering large-scale IT projects on time, on budget, and on value, McKinsey, 1. listopada 2012.
• § 631 BGB, Werkvertrag, § 640 BGB, Abnahme i § 611 BGB, Dienstvertrag, Gesetze im Internet