Zákazník potřebuje znát cenu předem. Jednak je to určitá zvyklost, jednak potřebuje vědět, zda jeho rozpočet na realizaci stačí. V neposlední řadě potřebuje srovnávat mezi různými nabídkami. Z výše uvedeného to vypadá, že jediná rozumná volba je pevná cena. Nemusí tomu ale tak být vždy. Čtěte dále.
Vývojáři mají pohled na věc ale přesně opačný. Objem práce není totiž jasný a navíc víme, že se často vyskytují různé technické potíže, jejichž řešení může vzít nemalé množství neplánovaného času. Pevná cena se tak může jevit jako loterie. Vývojář ji může chápat jako bianko smlouvu, kde se za nějakou cenu upíše k neomezenému množství práce.
Výhody pro klienta | Jasný rozpočet předem, snadné porovnání nabídek, motivace dodavatele k efektivitě. |
Nevýhody pro klienta | Riziko vyšší ceny (dodavatel si započítá buffer na rizika), menší flexibilita při změnách, potenciální kompromisy v kvalitě, pokud je odhad podceněn. |
Výhody pro dodavatele | Možnost vyšší marže při efektivní práci, jasně definovaný cíl. |
Nevýhody pro dodavatele | Riziko ztráty při podcenění rozsahu nebo neočekávaných problémech, nutnost detailní specifikace a řízení změn. |
Výhody pro klienta | Platí pouze za odvedenou práci, větší flexibilita při změnách a nejasném zadání, často rychlejší start projektu. |
Nevýhody pro klienta | Nejistota ohledně konečné ceny, riziko neefektivity dodavatele, nutnost důvěry a kontroly. |
Výhody pro dodavatele | Pokrytí veškerého odpracovaného času, menší riziko ztráty u projektů s nejasným zadáním, flexibilita. |
Nevýhody pro dodavatele | Nutnost pečlivého sledování a reportování času, potenciální tlak klienta na rychlost na úkor kvality, nejistota příjmu. |
Ve skutečnosti mají pravdu oba, zákazník i vývojář. Co nám ale v rovnici řešení chybí je architekt a jeho práce. Vzpomeňte si, že zedník Vám nepostaví dům, když nemáte projekt. Ve skutečnosti jediná možnost jak zjistit cenu je rozpitvat projekt na dílčí malé úkoly. Jedině ty se pak dají nacenit a výsledky, jak jinak, sečíst.
Když požadavky na funkčnost sepíšeme do programu určeného pro projektové řízení (JIRA) a následně ji rozpitváme na jednotlivé úkoly, dostaneme ideální podklady pro projektové řízení. Nejenže zjistíme odpověď na základní zákazníkovu otázku ohledně ceny. Budeme vědět jak dlouho projekt potrvá a dokonce kdykoli v průběhu projektu budeme vědět, jak se nám daří plnit plán. V neposlední řadě budeme mít i podklady pro testera. Jeho práce totiž spočívá zejména ve srovnání stavu zjištěného při testech se stavem definovaným v dokumentaci.
Jednoduše neví, že je to práce, která je u středních a větších projektů nutná. Neuvědomují si, že je to jako stavět dům bez projektu, často považují svůj prvotní popis projektu za dostatečný. Práci na projektu považují za zbytečnou. To je hrozný omyl!
Projekt bez řízení je b...l. Nejenže nebudete vědět, kdy to bude a kolik to bude stát, ale navíc si připravíte nepříjemné chvilky diskusemi jak to vlastně mělo fungovat. Věřte tomu, že s nejasným zadáním udělá programátor neznalý zákazníkův business vždy něco “jinak”. Právě tohle způsobuje častější nutnost něco předělávat. Projekt se prodražuje, nervozita stoupá. Nakonec, až už je většinou pozdě, se zjistí, že zdražení projektu je daleko větší, než je cena sepsání požadavků do JIRA.
Na začátku jsme řešili, zda je lepší pevná cena nebo hodinová sazba. Nyní už víme jak to bylo pošetilé! To co ve skutečnosti potřebujeme je projektové řízení.
Když připustíte, že projektové řízení potřebujete, koukněte na povídání fixní ceně projektu. Pokud by jste chtěli vidět mé sazby pro spolupráci s pevným časovým úsekem , uvidíte je v mém ceníku sazeb.