Kdy dává vývoj softwaru na míru smysl

Tabulka, do které každý pátek kopírují data tři lidé. E-maily mezi obchodem, provozem a účetnictvím. Hotový systém, který umí většinu práce, ale právě v nejdůležitějším kroku nutí tým improvizovat. Tady obvykle začíná debata, zda má vývoj softwaru na míru smysl.

Ne každá nepříjemnost si zaslouží vlastní aplikaci. Někdy stačí správně nastavit existující nástroj, propojit dvě služby nebo upravit interní postup. Jindy ale firma narazí na proces, který je přímo součástí jejího know-how, růstu nebo obchodního modelu. V takové chvíli univerzální software přestává pomáhat a začíná diktovat, jak má firma fungovat.

Vývoj softwaru na míru není náhrada za tabulku

Tabulky, formuláře a běžné online nástroje nejsou problém samy o sobě. Pro ověření nového procesu nebo pro menší objem práce jsou často nejrychlejší cestou. Problém vzniká ve chvíli, kdy se kolem nich začne stavět ruční provoz: kontrola duplicit, přepisování údajů, dohledávání správné verze dokumentu a rozhodování podle informací, kterým nikdo úplně nevěří.

Vlastní software má smysl tehdy, když neřeší jen nepohodlí, ale konkrétní opakovanou ztrátu. Může jít o pomalé zpracování poptávek, chyby při fakturaci, složité schvalování, špatnou práci s kapacitou nebo neschopnost nabídnout zákazníkům funkci, kterou očekávají. U SaaS produktu je situace ještě přímočařejší: aplikace je samotná služba, kterou firma prodává.

Dobré zadání proto nezačíná větou „potřebujeme aplikaci“. Začíná otázkou, co dnes nefunguje, kdo to řeší a co se stane, když se objem práce zdvojnásobí. Teprve pak dává smysl rozhodovat o obrazovkách, technologiích a integracích.

Čtyři signály, že hotové řešení nestačí

Nejsilnější důvod pro vlastní produkt nebývá seznam funkcí. Je to opakující se situace, kterou tým každý den obchází. Poznáte ji obvykle podle těchto signálů:

• Klíčová data se ručně přepisují mezi více systémy a chyby se odhalují až zpětně.
• Proces vyžaduje vlastní pravidla, role nebo schvalování, které běžný nástroj neumí bez komplikovaných obcházek.
• Firma prodává službu, pro kterou je digitální workflow součástí hodnoty pro zákazníka.
• Stávající řešení omezuje růst, například nezvládá více klientů, poboček, jazyků, oprávnění nebo napojení na další systémy.

Ani jeden z těchto bodů sám o sobě automaticky neznamená, že je nutné stavět systém od nuly. Pokud je problém v jednom formuláři nebo v chybějícím napojení, plnohodnotná aplikace by byla zbytečně drahá a složitá. Pokud se ale body skládají dohromady, je čas proces popsat a rozhodnout, co má být vlastní.

Nejdřív pracovní postup, potom funkce

Zakázky se zbytečně prodražují, když se řeší funkce bez kontextu. „Potřebujeme správu uživatelů“ neříká, kdo uživatele zakládá, co smí vidět, kdo změny schvaluje ani co se má stát při chybě. Stejně tak „potřebujeme dashboard“ neříká, jaké rozhodnutí má člověk po otevření dashboardu udělat.

Na začátku s klienty procházíme skutečný tok práce. Od okamžiku, kdy do systému vstoupí požadavek nebo data, až po výsledek pro zákazníka, kolegu či účetnictví. Hledáme místa, kde se rozhoduje, kde se informace mění a kde vzniká odpovědnost. Z toho vzniká zadání, podle kterého lze software postavit i provozovat, ne jen vizuálně ukázat.

U interní aplikace může být jádrem například založení zakázky, přiřazení odpovědnosti, kontrola podkladů a export do účetního systému. U zákaznického SaaS zase registrace, přihlášení, práce s vlastními daty, administrace a jasně definovaný hlavní workflow. Právě tento funkční řetězec rozhoduje, zda produkt přináší hodnotu. Vedlejší funkce mohou počkat.

Co má být v první verzi

První produkční verze nemusí obsahovat vše, co firma bude potřebovat za dva roky. Musí ale samostatně vyřešit konkrétní problém od začátku do konce. U skutečného MVP to znamená vlastní databázi, přihlášení, potřebná oprávnění, administraci a funkční workflow pro reálné uživatele. Prezentace nápadu nebo klikací obrazovky mohou pomoci při diskuzi, ale nenahradí produkt, na kterém lze ověřit provoz.

Rozsah první verze se vybírá podle rizika. Pokud nevíme, zda budou uživatelé ochotni vyplňovat určitý typ dat, ověříme nejdřív právě tento krok. Pokud je největší nejistotou integrace se starším firemním systémem, řešíme ji dřív než kosmetické úpravy rozhraní. Tím se vyhneme situaci, kdy je hotová velká část aplikace, ale její nejrizikovější část stále stojí na předpokladu.

Co rozhoduje o ceně a termínu vývoje

Cena vývoje na míru není odměna za počet obrazovek. Dvě aplikace se stejným počtem stránek mohou mít úplně jinou náročnost. Rozdíl dělají hlavně pravidla na pozadí, uživatelské role, importy a exporty dat, propojení na externí služby, požadavky na bezpečnost a očekávaný objem provozu.

Například jednoduchý interní systém může mít několik obrazovek, ale složité schvalování a audit změn. Naopak zákaznická aplikace s větším počtem formulářů může být technicky přímočará, pokud pracuje s jednoduchými daty a bez návaznosti na další systémy. Proto nedává smysl stanovovat rozpočet jen podle názvu typu projektu.

Pomáhá rozdělit práci na dvě rozhodnutí. První je produktové: co musí první verze umět, aby ji lidé opravdu použili. Druhé je technické: jak ji postavit tak, aby šla bezpečně rozvíjet. U důležitých procesů nešetříme na základech, jako je správa přístupů, zálohy, monitoring, testování kritických scénářů nebo rozumná datová struktura. Naopak neinvestujeme předčasně do funkcí, pro které zatím není ověřený důvod.

Technologie má sloužit provozu, ne prezentaci

Technologický výběr má být vysvětlitelný i člověku, který neprogramuje. Webová aplikace bývá vhodná, pokud lidé pracují z kanceláře, z domu nebo na různých zařízeních a potřebují vždy aktuální verzi. Mobilní aplikace dává větší smysl tam, kde je práce v terénu, potřeba fotoaparátu, polohy, notifikací nebo častého používání na telefonu.

AI funkce mají hodnotu tam, kde zkracují opakovanou práci s textem, dokumenty, klasifikací nebo vyhledáváním v datech. Samy o sobě ale neopraví chaotický proces ani nekvalitní vstupy. Pokud firma neví, kdo data vlastní, odkud přicházejí a zda jsou správná, přidání AI problém spíš zviditelní. Nejdřív musí fungovat workflow a oprávnění, pak má smysl automatizovat vybrané kroky.

Technologie také ovlivňuje budoucí údržbu. Software po spuštění nezůstává hotový navždy. Mění se pravidla firmy, externí API, prohlížeče, bezpečnostní požadavky i očekávání uživatelů. Proto stavíme produkty tak, aby bylo možné změny dělat průběžně, ne až při další kompletní přestavbě.

Spuštění není předání projektu

Nejvíc se o kvalitě systému dozvíte ve chvíli, kdy s ním začnou pracovat skuteční lidé. Objeví se nečekané vstupy, výjimky v procesu, otázky k oprávněním i části, které uživatelé chápou jinak než zadavatel. To není selhání, ale běžná součást zavádění produktu do provozu.

Proto má být součástí spolupráce i provoz po spuštění: řešení chyb, sledování důležitých částí aplikace, aktualizace závislostí a plánování dalšího rozvoje podle reálného používání. Klient nepotřebuje tým, který odevzdá zdrojový kód a zmizí. Potřebuje partnera, který rozumí tomu, co bylo postaveno, a dokáže za tím stát i při další změně.

V Nextrey pracujeme přímo se seniorními vývojáři, kteří produkt navrhují, staví a následně udržují. Díky tomu se rozhodnutí neztrácejí mezi obchodem, analýzou a realizací. Pokud něco nedává smysl, řekneme to předem. A pokud je vhodnější upravit existující nástroj než stavět novou aplikaci, řekneme to také.

Nejlepší první krok nebývá poptávka na „aplikaci s deseti moduly“. Sepište jeden konkrétní proces, který dnes firmu stojí nejvíc času, chyb nebo příležitostí. Popište, kdo v něm pracuje, jaká data potřebuje a jak vypadá dobrý výsledek. Z takového základu se dá navrhnout software, který nebude jen další položkou v systému, ale skutečným pracovním nástrojem.