Specifikace požadavků pro B2B aplikaci bez mlhy

Obchodní tým řekne, že zákazníci potřebují „schvalování objednávek“. Vývoj začne a po několika týdnech se ukáže, že schvalovat může jiný člověk než ten, kdo objednávku založil, limity se liší podle pobočky a účetní potřebuje uzavřené objednávky exportovat do ERP. Právě tady rozhoduje specifikace požadavků pro B2B aplikaci. Ne jako formální dokument do složky, ale jako společně ověřený popis toho, co má produkt dělat v reálném provozu.

U B2B systémů nestačí seznam obrazovek. Aplikace obvykle pracuje s organizacemi, rolemi, smluvními pravidly, výjimkami a daty z jiných systémů. Zdánlivě malá nejasnost pak může znamenat, že hotová funkce řeší jen ideální scénář, zatímco běžná práce uživatelů zůstává mimo ni.

Co má specifikace požadavků pro B2B aplikaci vyřešit

Dobrá specifikace není přepisem přání do technického jazyka. Má pomoct rozhodnout dřív, než se z nejasnosti stane drahá změna v hotovém systému. Popisuje problém, uživatele, pravidla, očekávaný výsledek a hranice první verze.

Rozdíl je vidět na jednoduchém požadavku: „Zákazník si stáhne fakturu.“ Pro koho je faktura dostupná? Jen pro účetní, nebo pro každého uživatele firmy? Je možné stáhnout opravený doklad? Co se stane po zrušení účtu? Odkud aplikace fakturu bere a jak pozná, že jde o správnou verzi? Bez odpovědí nevzniká specifikace, ale prostor pro dohady.

Neznamená to, že před prvním řádkem kódu musí být známý každý detail. Některé věci dává smysl ověřit až na funkčním základě. Musí ale být jasné, které otázky jsou otevřené, kdo je rozhodne a jestli odpověď může změnit architekturu, bezpečnost nebo rozsah první verze.

Začněte pracovním procesem, ne seznamem funkcí

B2B aplikace obvykle nenahrazuje jednu izolovanou činnost. Vstupuje do procesu, který dnes lidé řeší v e-mailech, tabulkách, účetním systému nebo po telefonu. Proto se nejdřív ptáme, co se děje před použitím aplikace, během něj a po dokončení úkolu.

U platformy pro správu zakázek může být skutečným procesem přijetí poptávky, přiřazení odpovědné osoby, kontrola smluvních podmínek, schválení ceny, realizace a fakturace. Teprve z tohoto toku vyplyne, jestli potřebujete frontu úkolů, notifikace, auditní historii, export dat nebo napojení na interní systém.

Uživatel není jen jedna osoba

V B2B prostředí pracujete hlavně s firmami a jejich vztahy. Jeden zákazník může mít několik poboček, víc kontaktních osob a různá oprávnění. Dodavatel může pracovat pro víc zákazníků. Interní administrátor může vidět všechno, zatímco manažer zákazníka uvidí jen svůj tým.

Specifikace proto musí pojmenovat, kdo je vlastníkem organizace, kdo zve další uživatele a jak se přístup odebere při odchodu zaměstnance. Je dobré popsat i méně časté situace: slučování firem, změnu fakturačních údajů nebo převod rozpracovaného případu na jiného řešitele. Ne proto, aby se vše stavělo hned, ale aby systém od začátku neměl slepá místa.

Stavový model je často důležitější než obrazovka

Každý proces má stavy a přechody. Objednávka může být rozpracovaná, odeslaná, vrácená k doplnění, schválená, zamítnutá nebo uzavřená. U každého přechodu potřebujete vědět, kdo jej smí udělat, jaké podmínky platí a jestli se má změna uložit do historie.

To platí i u zdánlivě jednoduchých modulů. Když uživatel upraví údaj, má se přepsat původní hodnota, nebo se má změna evidovat? Může schvalovatel schválit vlastní požadavek? Zůstane záznam dostupný po archivaci? Odpovědi mají přímý dopad na datový model i uživatelské rozhraní.

Data, integrace a odpovědnost za pravdu

Hodně B2B aplikací není jediným zdrojem dat. Ceník může být v ERP, informace o zákazníkovi v CRM a stav platby v účetním systému. Specifikace musí určit, který systém je pro kterou informaci rozhodující a co se stane, když se data mezi systémy rozjedou.

Nestačí napsat „napojení na ERP“. Potřebujeme znát konkrétní data, směr přenosu, frekvenci aktualizace a chování při chybě. Jestli se například objednávka propíše až po schválení, aplikace musí uživateli srozumitelně ukázat, jestli je odeslaná, čeká na zpracování, nebo skončila chybou. Skrytá chyba integrace je v provozu horší než viditelný stav, který jde řešit.

Jak specifikaci připravujeme v praxi

Nejlíp funguje krátká, soustředěná fáze, ve které se společně díváme na skutečnou práci lidí, ne na hypotetické menu aplikace. Zakladatel nebo product owner přináší znalost byznysu. My do rozhovoru přinášíme zkušenost s tím, kde se požadavky při vývoji typicky rozpadnou: v oprávněních, datech, výjimkách, výkonu a provozu po spuštění.

Výstupem nemusí být tlustý dokument plný obecné terminologie. Pro produkt, který teprve hledá správný rozsah, je užitečnější jasně seřazený backlog, procesní scénáře, popis klíčových entit a klikací návrh hlavních toků. U modernizace interního systému zase často potřebujeme doplnit mapu stávajících dat, závislostí a rizik migrace.

U každé důležité funkce chceme umět říct: kdo ji používá, jaký problém řeší, jaký je běžný postup, co jsou výjimky a podle čeho poznáme, že je hotová. Kritérium hotovosti nemá být „obrazovka existuje“. Lepší je například: vedoucí může schválit požadavek v rámci svého oddělení, žadatel vidí výsledek a systém uloží, kdo rozhodl a kdy.

Když je součástí projektu AI funkce, specifikace musí být ještě přesnější. Je nutné určit, z jakých dat model vychází, jak se ověří výstup, kdo za něj nese odpovědnost a co se stane, když si systém není jistý. AI může dobře urychlit třídění dokumentů nebo návrh odpovědi, ale bez kontrolního kroku nemusí být vhodná pro rozhodnutí s finančním nebo právním dopadem.

Kolik detailu je správně

Příliš stručná specifikace vede k tomu, že zásadní produktová rozhodnutí vznikají až během implementace. Příliš podrobná specifikace může naopak zabetonovat řešení dřív, než se ověří, jestli lidem skutečně vyhovuje. Správná míra závisí na riziku a na tom, jak draho by stálo rozhodnutí později vzít zpět.

Přístupová práva, struktura organizací, práce s osobními údaji, cenová pravidla nebo napojení na další systémy se mění obtížně. Tady má smysl jít do detailu předem. Textace tlačítka, pořadí sekundárních polí nebo podoba méně používaného reportu se můžou upravovat průběžně, pokud stojí na správném základě.

Stejně tak se liší nový produkt a přepis existujícího systému. U nového SaaS produktu obvykle hledáme nejmenší funkční tok, který zahrnuje přihlášení, data, administraci a skutečnou hodnotu pro uživatele. U náhrady starého systému je nutné řešit i přechodové období, migraci dat a souběh starého a nového provozu.

Signály, že zadání ještě není připravené

Varovným signálem není to, že máte otevřené otázky. Ty má každý projekt. Problém nastává, když se odpovědi odkládají, přestože mění základ řešení.

Pozor si dejte zejména tehdy, když se mluví o „uživatelích“, ale nikdo neumí popsat jejich role; když se integrace označí za jednoduchou bez znalosti dostupného rozhraní; nebo když se administrace bere jako něco, co se doplní později. Administrace není vedlejší obrazovka. Je to místo, odkud někdo spravuje účty, data, oprávnění, výjimky a provozní problémy.

Dalším signálem je požadavek formulovaný jen jako funkce. „Potřebujeme dashboard“ není zadání. Potřebujeme vědět, kdo se podle něj rozhoduje, jaká data potřebuje vidět, jak aktuální musí být a co udělá, když zjistí problém.

Změna požadavku není selhání

Po spuštění aplikace se dozvíte věci, které ve workshopu nezazní. Uživatelé si najdou jiný pracovní postup, zákazník požádá o specifickou roli nebo se ve firmě změní pravidla. Smyslem specifikace není změny zakázat. Má zajistit, aby bylo vidět, co změna ovlivní a proč dostane přednost před jinou prací.

Když má projekt jasně popsané výchozí předpoklady, lze změnu posoudit věcně: zasahuje jen jednu obrazovku, nebo mění datový model, oprávnění a integraci? Patří do nejbližší verze, nebo nejdřív potřebujeme ověřit, jestli ji využije dost lidí? Takové rozhodování chrání rozpočet i tempo vývoje líp než snaha předstírat, že se produkt po první specifikaci už nikdy nezmění.

Dobrá specifikace nakonec nevypadá jako smlouva proti změnám. Je to společná mapa pro lidi, kteří aplikaci objednávají, staví a budou ji používat. Když je čitelná pro byznys i vývoj, můžete se soustředit na práci, která má pro zákazníka skutečný dopad, místo opravování domněnek, které šlo vyjasnit na začátku.