Co ovlivňuje rozsah a náročnost vývoje softwaru na míru

Dva projekty působí na první pohled stejně – „potřebujeme aplikaci na správu objednávek" nebo „chceme portál pro klienty". Přesto jeden tým odhadne rozsah práce poměrně rychle a s vysokou jistotou, zatímco u druhého se odhad mění při každé další schůzce. Rozsah vývoje softwaru na míru totiž nezávisí jen na tom, co aplikace navenek dělá, ale především na tom, s čím vším se musí vypořádat uvnitř – od stavu vstupních dat přes počet systémů, se kterými má komunikovat, až po to, jak rychle se dokáže klient rozhodovat. V tomto článku se podíváme na faktory, které náročnost projektu reálně určují, a proč je důležité o nich mluvit dřív, než padne jakékoli číslo.

Zadání typu „potřebujeme systém na evidenci smluv" může v praxi znamenat jednoduchou databázovou aplikaci se třemi formuláři, nebo komplexní systém s desítkami rolí, workflow schvalování, propojením na účetní software a archivací podle legislativních požadavků. Rozdíl mezi oběma scénáři není vidět z jedné věty zadání – projeví se až při detailní analýze. Proto seriózní příprava projektu vždy začíná rozkladem požadavků na jednotlivé funkční celky a identifikací toho, co bude technicky náročné, ne jen toho, co bude „vidět" na obrazovce.

Největší vliv na náročnost vývoje softwaru má často to, jak dobře je zadání promyšlené ještě před začátkem vývoje. Pokud firma umí přesně popsat procesy, výjimky a okrajové případy, tým dokáže navrhnout architekturu, která požadavky pokryje na první pokus. Pokud se naopak požadavky průběžně mění nebo se objevují až při testování hotových částí, roste počet úprav a s ním i celková náročnost – ne proto, že by se něco dělalo špatně, ale proto, že se mění samotný cíl.

Osvědčený způsob, jak toto riziko snížit, je detailní fáze analýzy před samotným programováním. O tom, jak tato příprava a následující kroky vypadají, píšeme podrobněji v článku Jak probíhá vývoj softwaru na míru: fáze projektu krok za krokem.

Software na míru jen zřídka funguje izolovaně. Propojuje se s účetnictvím, ERP, CRM, platebními branami, docházkovými systémy nebo externími registry. Každá taková integrace přináší vlastní nejistotu – záleží na tom, zda má cílový systém moderní a zdokumentované API, nebo jde o starší řešení bez rozhraní, kde je třeba data exportovat a zpracovávat náhradním způsobem. Čím více systémů je třeba propojit a čím horší je jejich dokumentace, tím vyšší je pravděpodobnost komplikací, které nelze odhadnout předem.

Pokud projekt zahrnuje propojení více firemních systémů, vyplatí se podívat i na článek Systémová integrace: propojení ERP, CRM a e-shopu – popisuje, na co si dát při takovém propojování pozor.

Graf ilustruje obecný princip – s přibývajícími integracemi a klesající kvalitou rozhraní roste i náročnost řešení. Konkrétní čísla se liší projekt od projektu.

Množství a struktura dat, se kterými má systém pracovat, ovlivňují návrh databáze, validace i výkon aplikace. Jednoduchá evidence s pár desítkami záznamů denně si vystačí se standardním návrhem. Systém, který zpracovává velké objemy transakcí, historická data z více zdrojů nebo potřebuje složité výpočty a reporty v reálném čase, vyžaduje promyšlenější architekturu už od začátku – včetně způsobu, jakým se data ukládají, indexují a zálohují.

Podobně i procesní logika – počet kroků schvalování, výjimky, paralelní větve procesu – přímo prodlužuje analýzu i testování, protože každá větev musí být ověřena samostatně.

Aplikace s jedním typem uživatele je z pohledu návrhu jednodušší než systém, kde mají různé role – administrátor, manažer, externí partner, klient – rozdílná oprávnění a vidí jiná data. S každou další rolí přibývají kombinace, které je třeba navrhnout, implementovat a otestovat, včetně toho, co se stane, když se role překrývají nebo mění v průběhu používání systému.

Pokud software pracuje s osobními údaji, platebními informacemi nebo daty podléhajícími regulaci v daném odvětví, náročnost roste i mimo samotnou funkcionalitu. Přibývají požadavky na šifrování, audit logy, řízení přístupů, bezpečné ukládání a v některých případech i externí bezpečnostní testování. Tyto vrstvy nejsou vidět v uživatelském rozhraní, ale jsou nezbytnou součástí rozsahu práce a je třeba s nimi počítat už při návrhu architektury, ne až dodatečně.

Systém navržený pro desítky uživatelů se architektonicky liší od systému, který má od začátku počítat s růstem na tisíce uživatelů nebo s vysokou zátěží ve špičkách. Pokud firma ví, že plánuje růst, rozšiřovat se na nové trhy nebo přidávat další moduly, je racionální zahrnout tuto perspektivu do návrhu už na začátku – dodatečná přestavba architektury kvůli škálování bývá náročnější než její promyšlení předem.

Náročnost projektu neurčuje jen technologie, ale i proces rozhodování na straně objednatele. Pokud má firma jasně určenou zodpovědnou osobu, která umí rychle schvalovat návrhy a poskytovat zpětnou vazbu, projekt postupuje plynule. Pokud se rozhodnutí musí schvalovat napříč více odděleními nebo se priority mění v průběhu vývoje, roste počet iterací – což se přímo projeví na celkovém rozsahu práce, i když se funkční zadání na papíře nezměnilo.

Přesný odhad náročnosti nevzniká odhadem „od oka", ale rozborem výše uvedených faktorů pro konkrétní projekt. Pomáhá si předem připravit odpovědi na otázky: kolik systémů má řešení propojovat, jaké typy uživatelů bude mít, jaká data bude zpracovávat a jaké nároky na bezpečnost z toho vyplývají.

Pro firmy, které zvažují, zda je software na míru vůbec vhodnou cestou, nebo by jim lépe posloužilo hotové řešení, může být užitečné nejprve porovnání v článku Software na míru vs. SaaS: co se firmě vyplatí víc. Pokud už víte, že směřujete k řešení na míru, podívejte se i na naše řešení v oblasti vývoje softwaru, kde najdete přehled přístupu, který u podobných projektů používáme.

Protože každý projekt má jinou kombinaci výše uvedených faktorů, nejspolehlivější způsob, jak získat reálnou představu o rozsahu konkrétního zadání, je probrat ho s někým, kdo umí položit správné otázky. Pokud zvažujete vývoj softwaru na míru a chcete si ujasnit, co všechno bude vaše řešení zahrnovat, domluvte si nezávaznou konzultaci.