Alchymie nacenění vývoje softwaru aneb co se skrývá za šestimístnými ciframi

„Kolik to bude stát,“ je klasickou otázkou na začátku každého vývoje softwaru (tedy i mobilních aplikací). Odpověď není jednoduchá, a proto se vždy pouštíme do nacenění.

Možnosti jsou dvě - rámcový odhad, kdy ale může nastat mrzení během spolupráce kvůli případným vícepracím nebo rozdílnému očekávání od výsledného produktu. Nebo je nacenění detailní a obě strany tak mají lepší přehled o tom, co je čeká. V SYNETECHu volíme druhou variantu a nyní transparentně odhalujeme, co se za ní ukrývá.

Jak probíhá nacenění, jedná-li se o FTFP projekt?

(V tomto článku budeme mluvit jen o naceňování fixed time fixed price projektů, což představuje pořád většinu poptávek, které řešíme. Agilní vývoj má svá značná specifika, která představíme příště.)

Proces naceňování z podstaty věci musí být vždy individualizovaný, mobilní aplikace je pokaždé uzpůsobena potřebám a přáním klienta. Přijde-li poptávka, nejde tedy po otevření e-mailu od oka říci výslednou částku, naopak.

Na tom, jak takový vývoj mobilní aplikace, webu nebo systému správně nacenit, pracují v SYNETECHu minimálně 3 seniorní lidé (projekt manager, senior developer a solution architekt) několik dní.

Specifikace

Ideální cesta pro co nejpřesnější nacenění (pro obě strany) je pokud za námi klient přijde s finálním návrhem designu, včetně popisu funkcí, které má aplikace umět (alespoň do rozumné úrovně detailu).

Taková je však jen zhruba jedna poptávka z deseti. Nejčastěji dorazí buď jen strohý soupis funkcí, nebo naopak 80 stránek textu…

A jsou i případy, kdy klient přijde s tím, že chce například e-shop a zajímá ho pouze rámcová cena, ideálně co nejnižší - přitom vágní definice je nejčastější chybou při vývoji software.

To je bez jakýchkoliv dalších specifikací trochu jako řešit záhadu hlavolamu. To může vést k frustraci zákazníka nadhodnocenou nabídkou, protože se nacenila složitější varianta než si představuje. Nebo naopak k nepříjemné spolupráci po tom, co se nabídka nepochopením zadání pro vývojářské studio naopak podhodnotí.

Jednověté zadání nevadí, pokud…

Kvitujeme i situaci, kdy klient přijde s reálným problémem, i když nemá vůbec vymyšleno, jak jej řešit. Pokud je otevřený návrhům a zároveň není svázán malým rozpočtem, nemusí být vývoj ani v takovéto situaci nemožný, a především ne drahý (takto jsme vyvíjeli například pro Oriflame či Jablotron).

V takovém případě analyzujeme ideální technologická řešení, ukazujeme možné varianty i s jejich naceněním. Klient si mezi nimi vybírá a postupně se posouváme dále.

50-700 tisíc

Pokud máme za úkol vytvořit samotnou specifikaci – technické zadání k danému business case, se kterým klient přichází, začínáme analýzou problému a návrhem vhodného technologického řešení. A zde je nutno mít na mysli, že právě tato část může stát 50-700 tisíc (a to se ještě nezačalo vyvíjet) Nicméně tato přípravná fáze vývoje je pro úspěch výtvoru klíčová a její nespornou výhodou je to, že můžeme být mnohem přesnější v odhadech ceny, jsme sladění v očekáváních od výsledného produktu a celý proces je mnohem efektivnější.

Estimace

V momentě, kdy podklady pro nacenění přijdou, dostává se ze sales oddělení na project managery. Jeden z nich pak detailně zkoumá zadání a rozděluje zakázku na menší funkční celky, zpravidla jednotlivé obrazovky nebo menší funkce (použití Firebase pro analytika, push notifikace, ovládání mapy nebo třeba sekce AR)… Vždy je totiž přesnější naceňovat aplikaci takto po detailech než jako jeden velký celek. Poté toto nacenění putuje za software analitiky, kteří přidávají zpětnou vazbu.

Následně pak přichází na řadu tzv. estimační meeting, na kterém prochází minimálně tři seniorní vývojáři specifikaci položku po položce, koukají do designů a kladou otázky k nesrovnalostem a předpokladům funkčnosti. To je ošemetná část, která zahrnuje mnoho domýšlení, bez detailního briefu je totiž velmi těžké odhadnout představy klienta (například chce-li rozšířenou realitu, má být spuštěna objektem, letákem či něčím úplně jiným?). Poté, co mezi sebou naši vývojáři dospějí k návrhu řešení, rozdělí aplikaci do menších celků a na nich pak aplikují tzv. tříčíselný odhad.

Expertní odhad vývoje aplikací v praxi

Reálně tato metodika vypadá tak, že ke každé obrazovce či funkci vzniknou 3 odhady – minimální, maximální a nejpravděpodobnější (nikoliv průměrný). Očekáváme-li totiž vývoj neznámé funkce, musíme udělat odhad, kolik její vytvoření zabere času - když všechno půjde krásně, budeme mít všechno připravené a zvolíme nejlehčí technologii. V takovém případě bude platit cena pro minimální odhad.

Když ale všechno bude špatné, API nepojede, zákazník neřekne preferovanou technologii, bude platit maximální možná cena. Nejlepší odhad pak platí pro ideální situace, kdy jsme již podobnou věc programovali, existuje k tomu knihovna (tedy pravděpodobně budeme u minimálního času a ceny), zkrátka nejreálnější odhad.

Části této metodiky jsou vážené, přičemž právě nejlepší odhad má tu nejvyšší váhu a minimální a maximální odhady jsou krajní meze.Čím více je však požadovaná funkce pro nás "neznámá", tím je rozsah vyšší. Pokud například chce klient registraci, kterou jsme dělali 100x, rozptyl bude pravděpodobně jen 1 MD (man day). Pokud budeme dělat něco zbrusu nového, například zpřístupnění pro neslyšící, může být rozptyl klidně 20 MD.

Tolik k teorii. V praxi si na estimačním meetingu rozdělí zadání 3 seniorní vývojáři, přičemž jeden vystupuje jako optimista, druhý jako pesimista a třetí se snaží mít co nejpřesnější odhad. Poté se vedou diskuse, zda jsme třeba již něco podobného neprogramovali, proč by věc měla či neměla být takto drahá a podobně, až se dostaneme k ideálnímu tříčíselnému odhadu. Nikdy z takové schůzky neodcházíme, že bychom se neshodli.

S čím jdeme za klientem?

S tříčíselným naceněním nakonec jdeme za málokým (pokud si to klient vyloženě nepřeje), tento postup slouží k odhadu času vývoje, ke kterému přidáváme management, testing, fixní položky jako založení projektu a z toho vzniká celkové nacenění, které prezentujeme klientovi. Sto lidí, sto chutí, a tak někomu stačí cena rámcově, někteří chtějí detailní popis.

Například jednomu z našich aktuálních klientů jsme ukazovali specifikaci o 500 řádcích. Rádi pro naše zákazníky připravíme naproprosto detailní rozpad ceny a trpělivě vysvětlujeme, proč která položka stojí to, co stojí. Nicméně ještě nikdy se nám nestalo, že by někdo nějakou částku zpochybňoval, což je vlastně pozitivní skutečnost – oborová edukace funguje a už si nikdo v Česku nemyslí, že se mobilní aplikace vyvine za 40 tisíc a jeden MD.

Právě proto, že věnujeme tolik času analýze a nacenění zakázky, je z naší zkušenosti spolupráce o mnoho příjemnější, protože jsou z obou stran od začátku nastavena reálná očekávání. A v příjemné atmosféře vznikají ty nejlepší mobilní aplikace – třeba tu příští úspěšně vytvoříme právě s vámi a správným odhadem vše zdárně odstartujeme.

Přemýšlíte o vývoji mobilní aplikace? Určitě se nám ozvěte, rádi s vámi vše probereme.