Fiksna cena ili cena po satu?

Ova dilema zadaje dosta muka kako frilenserima, tako i dev kompanijama, ali i klijentima. U ovom postu pokušaću da podelim sa vama svoje iskustvo u vezi sa ovim problemom.

Kada pregovaramo u vezi sa projektom, imamo 3 opcije plaćanja:

• fiksna cena
• cena po satu
• mešovita opcija

Fiksna cena

Ovo je najčešći oblik plaćanja. Obe strane se dogovore koliko resursa (vremena i troškova) je potrebno da bi se projekat završio i potpisuje se ugovor nakon čega kompanija ili frilenser preuzima odgovornost da uradi projekat na vreme. Ipak, postoje dva velika nedostatka sa ovim aranžmanom kada govorimo o projektima srednje ili velike kompleksnosti: predviđanje i pregovaranje promena u ugovoru.

“Teško je praviti predviđanja, pogotovo o budućnosti” -­ Nils Bor

U IT sektoru ova izreka je vrlo primenljiva. Što je veći obim projekta koji se procenjuje, tj. što je duži period koji pokušavamo da predvidimo, veća je verovatnoća da će se napraviti greška. A ako predviđanje obavlja neko ko ne poseduje odgovarajuće iskustvo ili znanje, ako ne postoji dovoljno informacija o projektu ili u slučaju da se procena vrši na projektu koji je već započet, onda je mogućnost pravljenja greške još veća.

Loše predviđanje najčešće se odnosi na potcenjen obim posla. A kada se desi loša predviđanje i projekat izađe iz okvira procenjenog vremena, sve ide dođavola: imate nazadovoljnog klijenta zato što nije dobio na vreme ono za šta je platio a pored toga imate nezadovoljnog a samim tim i manje produktivnog frilensera ili kompaniju jer mora da troši dodatno vreme na projektu iako za to dodatno vreme neće biti plaćen.

Drugi nedostatak je pregovaranje oko promena u ugovoru i specifikaciji koje su neminovne ako projekat traje duže vreme. Klijent će nakon nekog vremena uvideti da želi neke druge funkcionalnosti koje nisu prvenstveno pokrivene, a samo pregovaranje o troškovima izrade ovih funkcionalnosti oduzima dodatno vreme i pomera fokus obe strane sa konkretnog projekta.

Prednosti:

• klijent zna koliko ga projekat košta, kada će se završiti i stoga ima više poverenja
• frilenser ili kompanija preuzima više odgovornosti za svoj rad. Na primer, ako naprave grešku u arhitekturi, moraju da je isprave bez ikakvih dodatnih troškova za klijenta.

Nedostaci:

• rizik lošeg predviđanja i nerealne ponude
• čak i kada je predviđanje dobro, potrebno je dosta vremena da bi se napravilo
• funkcionalnosti su definisane u početnom ugovoru i svaka dodatna stavka mora biti ispregovarana i ugovor se mora menjati
• problem sa “lošim” klijentima (npr. kada klijent ne razume svoju ulogu dobro) koji predstavljaju svaki dodatni zahtev kao mali dodatak, bez obzira na to koliko ih ima i koje resurse zahtevaju. Takođe tumače sve što nedostaje u aplikaciji kao bag, čime izbegavaju sopstvenu odgovornost pri definisanju funkcionalnosti.
• na kraju, neretko se ovakvi aranžmani završe bez urađenog projekta ili sa neadekvatno plaćenim pružaocem usluga

Šta uraditi kako bi ova opcija bila prihvatljivija (iz ugla pružaoca usuga)?

• kada procenjujete projekat, podelite ga na funkcionalnosti čije procenjeno vreme ne premašuje dva radna dana
• povećajte svoje početno predviđanje za 30-­40% i osigurajte se za sve nepredviđene situacije koje će se neminovno desiti
• ako se radi na već postojećem projektu, prvo tražite da vidite kod (nekada loša arhitektura može da vas duplo uspori u radu)
• budite sigurni da klijent zna koje funkcionalnosti tačno dobija
• ne ulazite u ovaj aranžman ukoliko treba da uđete u već formiran tim gde će vaš rad zavisiti od nekog drugog

Cena po satu

Ako klijent ima poverenje i ako su kompanija ili frilenser pošteni, iskusni i odgovorni u svom radu, onda je ovo verovatno najbolja opcija. Ugovorite vrednost radnog sata, potpišite ugovor kako bi se obe strane zaštitile i fokusirajte se nadalje na sam projekat. Ne dozvolite ni u jednom trenutku da pregovaranje o ugovoru bude u fokusu više nego sam projekat.

Ali, kao i uvek, dobri i pošteni ispaštaju zbog loših i nepoštenih. Ako je programer nemaran, što nije retkost, onda je ovakav aranžman čisto gubljenje novca za klijenta. Zbog ovoga klijenti teže ka unapred ugovorenim, fiksnim aranžmanima koji će više odgovornosti postaviti na stranu pružaoca usluga.

Prednosti:

• uvek radite na stvarima koje imaju najviši prioritet za vaš projekat i ne morate da se brinete o ispunjenju ugovora
• ne postoji pregovaranje oko toga koje funkcionalnosti su pokrivene ugovorom, a koje nisu
• nema dugih pregovora pred početak projekta
• plaća se za ono što je urađeno

Nedostaci:

• problem nastaje ako programer lažira svoj posao i klijent onda ne plaća fer cenu za ono što dobija
• kompanija/frilenser može praviti mnogo grešaka u svom radu, npr. pogrešna interpretacija zahteva klijenta, pravljenje prevelikog broja bagova, postavljanje pogrešne arhitekture sistema i sl. a u ovom slučaju ne mora preuzeti odgovornost za to niti se potruditi da poboljša svoj način rada. Klijent će opet platiti ovu vrstu nemarnosti pružaoca usluga.

Kako da učinite ovo bezbednom opcijom?

Učinite stvari visoko transparentnim tako da klijent može da vidi na čemu programer radi i šta će biti urađeno u narednom periodu. Ukoliko postoje greške u vašem radu (pogrešna interpretacija zahteva, loše postavljena arhitetktura…), uvek težite da popravite svoj rad i uklonite sve prepreke. Scrum i Kanban će vam pomoći da ovo postignete. I prestanite da lažirate! :) Klijenti, prihvatite transparentnost, ukažite poverenje ali i raskinite ugovor ako niste zadovoljni.

Mešovita opcija

Ovo je dobra opcija ukoliko klijent nije spreman na cenu po satu. U tom slučaju, frilenser/kompanija daje procenu i obavezuje se da je neće preći više od određenog procenta (npr. 25%). Ovo će učiniti da frilenser/kompanija bude sigurniji u svoju procenu, a klijent će znati otprilike koliko će ga projekat koštati. Takođe, ovaj scenario rešava u dobroj meri problem oko pregovaranja promena u ugovoru i beskonačne rasprave o tome šta je bag, a šta unapređenje.

Prednosti:

• klijent zna tačno koliko će ga otprilike projekat koštati
• frilenser/kompanija ne mora da se plaši da neće moći da adekvatno naplati svoj rad

Nedostaci:

• opet moramo da se bavimo predviđanjima na duži vremenski period iako je mogućnost pravljenja greške znatno manja
• dosta vremena se utroši na definisanje uslova početnog ugovora