Analýza zadání a nacenění vývoje softwarového projektu

Běžně se mě stává, že poptávající potencionální zákazník mě pošle nějaký dokument a očekává, že na základě toho udělám cenový odhad. Viděl jsem, ve firmách, že nějaký obchodník si asi hodí kostkou a poptávajícímu řekne nějakou částku, aby potencionální zákazník byl spokojen. Ovšem já dělám pouze kvalifikované odhady a na ty je potřeba mít dostatek podkladů a promyslet další věci... Nikde jsem nenašel jasně popsaný postup jak udělat dobrou analýzu a necenění projektu. Takže o informace jak řeším analýzu a cenový odhad já, se s vámi podělím v tomto článku.

Prvně je si třeba říci o čem se tu bavíme. Řeší jak kvalifikovaně odhadnout softwarového projektu, který je vyvíjen na míru. Nikoli prodej hotové věci/softwaru jako je prodej housek/telefonů/licenčních klíčů.

Určení ceny

Velice dobře jdou oceňovávat například stavby. Samozřejmě za předpokladu, že se nemění trh a tedy cena materiálu a práce. Například pokud si objednáte realizaci ústředního topení dá se velice přesně po prohlídce a proměření domu určit množství materiálu (to je analýza potřebného materiálu) a zkušený člověk na základě předchozích zkušeností z realizace podobného projektu odhadne cenu, která se odvíjí primárně od ceníků materiálu a potřebného pracovního času. Takový odhad přičte nějaké riziko a zisk a výsledkem udělá cenovou nabídku poptávajícímu.

Vývoj na míru

V případě vývoje softwaru na míru je však každý projekt jiný, kdyby byl stejný nebo i podobný, tak se na to dá použít již hotové řešení nebo předpřipravený základ. Typickým příkladem jsou eshopy. Vezme se již předpřipravené řešení, upraví se nastavení, změní vzhled a doprogramují minoritní funkce.
Nebo se dá pronajmout eshop formou služby, kdy máte k dispozici stejné funkce jako ostatní. Nic však není možné upravovat na míru.

V dnešní době je optimální způsob řízení vývoje projektu na míru: Agilní vývoj, kde cenové odhady třeba ani nemusíte řešit nebo jsou orientační.
V případě požadavku na fix-price nějaký odhad však musíte dát. Odhad ať už cenový, časový nebo náročnost se může hodit i u agilního vývoje. Typicky pokud vyvíjíte velký projekt, na kterém závisí další fungovaní firmy nebo orientační odhad na implementaci nějaké velké zásadní funkčnosti v aplikaci.

Kroky kvalifikovaného odhadu

Někdo dělá cenové odhady asi z křišťálové koule. Kvalifikovaný odhad ceny se však dá udělat lépe, jen to dá práci. Stačí postupovat v několika krocích. Zároveň tyto kroky zajišťují, že výsledný produkt bude odpovídat potřebám zákazníka.

Čím je projekt větší tím bude komplexnější a tím roste pravděpodobnost rizika a velikost rizika, že se něco odhadlo špatně, něco se udělalo špatně nebo se dokonce i na něco zapomnělo. A s větším projektem to jsou pak i větší úpravy, aby se to dodělalo nebo napravilo. S větším projektem proto zásadně roste nutnost provést úvodní analýzu a je nutné ji provést i detailněji a pečlivěji.

Seznam kroků, který je třeba udělat, aby byly informace, které jasně specifikují zadání:

1. Sběr a analýza požadavků
2. Zpracování a zdokumentování požadavků
3. Vytvoření technického zadání
4. Revize a schválení

Sběr a analýza požadavků

Sejděte se se zákazníkem a diskutujte o jeho potřebách. Zjistěte, jaké problémy chce řešit, jaké jsou jeho cíle a očekávání. V této fázi je důležité klást mnoho otázek, abyste pochopili kontext a důvody pro vznik aplikace.

Pokud je projekt větší a zahrnuje více stran, může být vhodné uspořádat hromadné setkání, kde budou všichni zainteresovaní moci vyjádřit své potřeby a nápady. Krom vedoucích by se měl zúčastnit i řadový zaměstnanec firmy, který osobně zná činnost, kterou aplikace bude řešit a tedy je to často člověk, který bude danou funkcionalitu aplikace používat.

Analyzujte existující řešení ve firmě a na trhu. Pokud již existuje nějaký systém, který bude nová aplikace nahrazovat nebo doplňovat, analyzujte jeho funkčnost a identifikujte problémy či oblasti ke zlepšení.
Prozkoumejte, zda na trhu existují podobné aplikace, a jaké funkce nebo vlastnosti by mohly být pro váš projekt přínosem.
Můžete i zjistit, že aplikace s požadovanou funkčností již existuje a není třeba plýtvat zdroji (utrácet peníze, trávit čas) na realizaci nového řešení od nuly, ale bude možno pořídit existující řešení a to upravit pro vaše konkretní potřeby. To ušetří výrazně peníze, zkrátí dobu spuštění a sníží rizika spojení s vývojem softwaru na míru.

Analýza je vědecká metoda založená na dekompozici celku na elementární části, je to metoda zkoumání složitějších skutečností rozkladem (dissolution) na jednodušší, základní celky. Cílem analýzy je identifikovat podstatné a nutné vlastnosti elementárních částí celku, poznat jejich podstatu a zákonitosti. Analýza je také způsob výkladu, jestliže oddělujeme jednotlivé jevy a zkoumáme je izolovaně. (Opačný postup k analýze se nazývá syntéza. Výsledkem syntézy je vytvoření nových celků.)
Výsledkem analýzy u informačních systémů je zejména pochopení logiky. A tím pádem získání výchozích předpokladů pro realizaci systému nebo optimalizaci existujícího systému.

Najděte kritické body!
Kritické body v projektu jsou klíčové momenty, kdy mohou vzniknout závažné problémy nebo kdy je zásadní rozhodnout, jak se projekt bude dále vyvíjet. Jejich identifikace a řízení zvyšuje úspěšnost projektu. Zmapujte si časovou osu projektu a identifikujte nejdůležitější termíny (např. dokončení určité fáze, schválení klientem).
Analýza závislostí mezi úkoly. Každý úkol může být závislý na jiných úkolech. Pokud jeden úkol zaostává, může to ovlivnit celý projekt. Používejte Ganttův diagram nebo kritickou cestu (Critical Path Method - CPM), což jsou nástroje pro vizualizaci, jak jsou jednotlivé aktivity propojeny a které z nich mají minimální flexibilitu v termínech.

Zpracování a dokumentace požadavků

Funkční požadavky

Definujte, co má aplikace dělat – tedy její funkce. Ty mohou zahrnovat konkrétní operace, které uživatelé mohou provádět, např. „uživatel se může přihlásit pomocí emailu a hesla“, „systém automaticky upozorní na nadcházející události“ apod.
TIP: Zapište si i funkce, které v aplikaci nebudou, ať je jasné co aplikace dělat nebude. Zapište si funkce, které plánujete v budoucnu, protože podle toho pak už můžeme dopředu směřovat vývoj a připravit tak aplikaci na pozdější jednoduché přidání těchto funkcí.

Nefunkční požadavky

Určete požadavky na výkon, bezpečnost, použitelnost, škálovatelnost, údržbu apod. Tyto požadavky se nezaměřují na konkrétní funkce, ale na to, jakým způsobem má aplikace fungovat.

Prioritizace požadavků

Ve spolupráci se zákazníkem určete prioritu jednotlivých požadavků. Pomůže vám to při plánování vývoje určit, které funkce musí být hotové v první fázi a které mohou počkat.

TIP: Vytvořte skupinu požadavků, které jsou nutností pro první smysluplnou verzi aplikace. Tuto verzi aplikace předejte do provozu k používání. Další funkce přidávejte následně postupně.
Toto je koncem realizace tzv. minimal value product (MVP), což má tu výhodu, že máte rychle odezvu na vaši aplikaci a můžete získávat již první zákazníky.

Vytvoření technického zadání

Vzhledem k tomu, že jazyk uživatele a zákazníka je jiný než jazyk vývojáře informačního systému, je dobré si vytvořit slovníček pojmů a každý neznámý výraz tam zapsat. Typicky slova z programátorského oboru a nebo z firemního slangu.

Úvod a popis projektu

Začněte dokument jednoduchým shrnutím, co je cílem aplikace a jaké problémy má řešit.

Specifikace funkčnosti

Podrobně popište jednotlivé funkční požadavky, včetně scénářů užití (use cases), diagramů toků, user stories, atd.

Architektura systému

Navrhněte, jak bude systém strukturován. Může to zahrnovat návrh databáze, API rozhraní, moduly aplikace, a jak budou jednotlivé komponenty spolupracovat.

Pro zápis (zakreslení) tříd, DB struktury a usecase použijte ideálně jazyk UML. Efektivněji tak můžete vytvářet, upravovat a číst podklady pro vývoj aplikace.

Technologický stack

Zvolte technologie a nástroje, které budou použity – programovací jazyky, frameworky, databáze, servery, atd. Při výběru technologií berte v potaz jejich vhodnost pro daný úkol. Často se i bere v potaz množství dostupných vývojářů, kteří znají danou technologii.

Vyzkoušejte technologie a API, které používáte prvně, ať víte co vás čeká a jestli je to vůbec použitelné. Díky tomu nebudete vstupovat do neznáma a dělat odhady z neznáma. Zároveň si tak připravíte i vývojové/testovací prostředí.

Bezpečnostní požadavky

Specifikujte, jak budou řešeny otázky bezpečnosti, včetně autentizace, autorizace, šifrování, atd. Pokud je nestanovíte neočekávejte, že na ně bude výrazně brán ohled.

Testování

Definujte, jak bude probíhat testování aplikace – jaké typy testů budou prováděny (jednotkové, integrační, uživatelské), kdo je bude provádět a jaké jsou akceptační kritéria. Kdo od zákazníka bude schvalovat, že daná funkčnost byla dodána v pořádku.

Plán vývoje

Na závěr vytvořte časový harmonogram vývoje s milníky, které budou postupně dosaženy. Zahrňte také plán na řešení rizik a změnové řízení.

Revize a schválení

Předejte zákazníkovi technické zadání k revizi. Projděte s ním všechny klíčové body a ujistěte se, že všemu rozumí a se vším souhlasí. Získejte zpětnou vazbu a případně proveďte úpravy. Je důležité, aby zákazník s technickým zadáním plně souhlasil před zahájením vývoje. Jakmile je vše odsouhlaseno, nechte zákazníka formálně schválit technické zadání. To zajistí, že obě strany mají jasně definované očekávání.

Proč dělat analýzu a technické zadání?

Tento systematický a strukturovaný přístup pomůže minimalizovat nedorozumění a zajistit, že vývoj aplikace bude probíhat podle plánu a v souladu s požadavky zákazníka. Jak dodavatel, tak zákazník má vetší jistotu, že vše bude probíhat podle jejich představ.

Platit za analýzu?

Často se stává, že poptávající očekává, že analýza a cenová nabídka bude zdarma. A někdo na takový požadavek přistupuje, ovšem pak dostane nabídku, která není ničím podložena. Následně potom co se stal z poptávajícího zákazník, se tento zákazník diví, když dostane výsledek později za větší cenu a někdy se i stává, že dostane něco co funkčně neodpovídá jeho představám. Dobrá analýza a dobré technické zadání zároveň zajišťuje kontrolu nad celým procesem vývoje a přispívá tak k úspěchu projektu.
A právě proto by si měl poptávající zaplatit analýzu. Zaplacení analýzy má i mnoho dalších výhod...

Platit za analýzu zadání je pro zákazníka výhodné z těchto mnoha důvodů:

• Jasná definice cílů a požadavků.
• Minimalizace rizik a nákladů.
• Přesný odhad nákladů a času.
• Zajištění kvality.
• Předcházení nedorozuměním.
• Lepší rozhodovací proces.
• Flexibilita a adaptace.
• Základ pro budoucí rozvoj.

Jasná definice cílů a požadavků

Analýza zadání pomáhá zákazníkovi přesně formulovat, co od aplikace očekává. Často se stává, že zákazníci mají obecnou představu o tom, co chtějí, ale nemají detailní specifikaci. Analýza pomáhá tuto představu konkretizovat, což zajišťuje, že konečný produkt bude skutečně vyhovovat jejich potřebám.

Minimalizace rizik a nákladů

Investice do důkladné analýzy na začátku projektu může ušetřit peníze v dlouhodobém horizontu. Bez pečlivé analýzy se může stát, že během vývoje vyvstanou nečekané problémy nebo bude nutné provádět zásadní změny, což může projekt prodražit a zpozdit.

Přesný odhad nákladů a času

Díky detailní analýze lze odhadnout náklady na vývoj a časový harmonogram. To pomáhá zákazníkovi plánovat rozpočet a očekávat reálné termíny dokončení projektu. Bez této analýzy jsou odhady velmi nepřesné, což vede k nespokojenosti na obou stranách.

Zajištění kvality

Technické zadání vytvořené na základě důkladné analýzy poskytuje vývojovému týmu jasné pokyny a specifikace, což vede k vyšší kvalitě výsledného produktu. Když vývojáři mají přesné a detailní informace, mohou se lépe soustředit na realizaci, což snižuje počet chyb a nedostatků.

Předcházení nedorozuměním

Detailní analýza a následné technické zadání slouží jako reference pro celý projekt. To zajišťuje, že obě strany – zákazník i vývojový tým – mají jasnou a jednotnou představu o tom, co se má vytvořit. To snižuje riziko nedorozumění a následných konfliktů.

Lepší rozhodovací proces

Během analýzy často vznikají otázky a nápady, které zákazník původně nezvážil. To pak vede k lepšímu (včasnému) rozhodovacímu procesu a optimalizaci funkcionalit aplikace. Zákazník tak může získat cenný vhled do toho, jaké funkce jsou pro něj skutečně prioritní a jaký technologický přístup bude nejvhodnější.

Flexibilita a adaptace

Pokud během analýzy dojde ke změnám v požadavcích nebo objevení nových potřeb, je snazší provést úpravy v této fázi, než během samotného vývoje. Díky analýze lze pružněji reagovat na změny, což je pro zákazníka přínosem.

Základ pro budoucí rozvoj

Dobře provedená analýza a technické zadání slouží jako dokumentace, která může být využita i v budoucnosti. Pokud se zákazník rozhodne pro další rozvoj aplikace nebo její rozšíření, bude mít k dispozici pevný základ, na kterém lze stavět.
Technické zadání může i vzít s touto komplexní informací může požádat o realizaci u jiného dodavatele.

Dodání a spuštění hotového projektu

Pokud projekt stavíte na technologiích, které znáte a vyzkoušeli jste si dopředu neznámé technologie a API, promysleli jste kritické body v projektu, tak jste odstranili největší rizika a máte velkou šanci, že projekt dobře dopadne.

Domluvte se dopředu kde bude aplikace provozována a jestli se počítá s následným dohledem a údržbou provozované aplikace.
Po spuštění projektu ideálně proveďte post-implementační analýzu.
Dodělejte a aktualizujte dokumentaci!