Agilné naceňovanie v IT

Prístupov k naceňovaniu projektov v IT môže byť viacero. Nám sa po mnohých rokoch práce na rôznych väčších, aj menších projektov osvedčil ako najlepší a pre obe strany najvýhodnejší tento prístup:

Nie vždy je v tejto chvíli známe celé zadanie, alebo celý produkt, ale to nie je pre projekt až natoľko potrebné. Hlavne preto, že produkt a nápady sa menia v čase a zároveň s tým, ako sa posúva aj vývoj.

Tu môžu nastať rôzne situácie:

Odhadovaný čas na základe zadania

1. Je dodané kompletné zadanie vrátane wireframov, na základe ktorého je možné vypracovať detailnú biznis a technickú analýzu na našej strane a projekt pomerne presne naceniť. Za takúto analýzu si klient platí podľa rozsahu projektu a požiadaviek na presnosť dodaného odhadu.
2. Výstupom tejto analýzy je high level zadanie, ktoré je možné využiť aj v procese vývoja, ujasnia sa nejasnosti v projekte, ktoré neboli došpecifikované, alebo zvalidujú, či sú správne pochopené/interpretované. Taktiež na základe takto detailne pripravenej analýzy, je možné pripraviť pomerne presnejšie časové odhady a plán vývoja. Doba na prípravu takejto analýzy je od 1 mesiaca a viac (opäť v závislosti od daného projektu)
3. Na základe takto vypracovanej analýzy sa môže klient rozhodnúť, či je cena vysoká/nízka a či sa chce do projektu s nami pustiť. Ak sa rozhodne, že spolupracovať nechce, vypracovaná analýza je mu dodaná ako vstup pre ďalšiu analýzu s inou firmou alebo v rámci jeho interného vývoja.
4. Aj v takto pripravených odhadoch je treba rátať so zmenami, ktoré môžu počas vývoja nastať, ktoré môžu budget navýšiť. Medzi také zmeny patria napríklad zmeny v zadaní, zmeny v dizajne, väčšie zmeny vo frameworku, alebo technológii, v ktorej sa projekt vyvíja a je potrebné všetko počas vývoja updatovať.
5. Takýto prístup je však vhodný len pre menšie alebo pre vývoj MVP projektu, ktoré by nemalo presiahnuť viac ako 4–6 mesiacov.
6. Ak nie je vopred dodaný finálny dizajn, odhady a nacenenie sa môže na základe dizajnu upraviť, lebo mnoho krát, to, čo dokreslia dizajnéri, môže vývoj mnohonásobne predĺžiť

Agilný cenník

1. Čas sa na projekte neodhaduje ako celok, ale začne sa analýzou projektu, ktorá je hradená klientom, kedy sa navrhne high level architektúra, štruktúra kódu, knižnice, technológie a ostatné.
2. Následne sa určia na projekte priority a tie sa rozdelia do 30 dňových alebo 14 dňových agilných sprintov.
3. Pred každým sprintom prebieha s tímom naceňovanie buď pomocou story pointov alebo v hodinách, kedy sa odhaduje náročnosť sprintu. V 14 dňovom sprinte by nikdy nemala byť viac ako 1 funkcionalita. Toto nacenenie sa následne konzultuje s klientom vždy na začiatku sprintu.
4. Takto pripravené odhady a náročnosť sú oveľa presnejšie, ako spraviť odhad na celý projekt na začiatku, aj keď už je hotová komplexná analýza, lebo vedia lepšie reflektovať aktuálny stav vývoja, stav tímu, stav dodaných podkladov a zamerajú sa na 1/2 konkrétne funkcionality, ktoré sa rozoberú pri naceňovaní do hĺbky.

Predplatené hodiny

1. Naceňovanie, ktoré funguje podobne ako agilný cenník, kedy si klient povie, že si na mesiac predplatí u nás napríklad 80 hodín v dohodnutej sume. Je možné si nastaviť aj maximálne ročné predplatné, napríklad 800 tisíc.
2. Na základe tohto predplatného sa dohodnú funkcie — opäť agilne, ktoré sa v danom sprinte za daný čas urobia.
3. Ak sa dojde na limit mesačného/ročného predplatného, tak sa vývoj pozastavuje, alebo sa komunikuje navýšenie budgetu.

Súčasťou každej formy vývoja sú ešte hodiny potrebné na operatívu, ktoré z mojich skúseností nie je vhodné dávať ku každej hodine vývojára. Na základe data analýzy nad projektami je možné pomerne presne vydefinovať, koľko s ktorým klientom a tímom trvá komunikácia, manažment a ostatné a tieto hodiny fakturovať navyše k dohodnutej dobe vývoja — napríklad 20 hodín mesačne na operatívu. Berie sa zo skutočne natrekovaného času — čiže tento čas nie je fixný, ale je tam známa priemerná hodnota.

Zároveň je cena vysoká aj preto, že sa nejedná len o čas vývojára, ale sú v tom aj hodiny:

• niekto to musí tomu vývojárovi zadať
• niekto musí funkciu zanalyzovať
• niekto musí kód skontrolovať
• niekto to musí otestovať aspoň priebežne počas vývoja
• náklady na kancelárie a ostatné povinné položky

Bola by som rada, keby sa tie odhady zrušia úplne, lebo v IT nie je možné vyvíjať a odhadovať nič fixne, ako cenu rožkov v obchode, ale je lepšie postupovať agilne už od prvého dňa a vedieť, na čom sme.

Vďaka tomuto nastaveniu je možné predchádzať problémom ako:

• posúvanie deadlinov, lebo na menší agilný sprint sa dá presnejšie plánovať, ako na vývoj na rok/mesiac dopredu
• posúvanie a navyšovanie budgetov, kedy sa klienti zafixujú na tú 1 sumu a nechápu, že sú to iba odhady a potom sa tam vedú namiesto vývoja a riadenia projektu neustále komunikácie o budgete a jeho zvyšovaní
• hádanie sa, čo malo a nemalo byť dodané, keďže na menší agilný sprint sa to dá taktiež pomerne presne naplánovať a vie sa, čo bude dodané
• nenavyšijú sa fiktívne ceny potom na change requesty, tie príbehy firiem, už všetci poznajú, keď potom aj výmena loga v aplikácii sa nacení na 8 hodín a klient už je zviazaný k danej firme a len tak ľahko s hotovým polonaprogramovaným riešením k inej firme neprejde a je nútený tú sumu za tieto mini tasky hradiť, čím si firmy vykompenzujú podhodnotené odhady, aby získali zákazku

Viac informácií, ako funguje naceňovanie u nás, nájdete na mojom webe — https://kompilator.cz/pricing.php

Máme tam viacero balíčkov, ktorými chceme klientov motivovať k dlhodobej spolupráci:

a rôzne formy cenníkov: