Jednou z nejčastějších příčin selhání softwarových projektů není vývojový tým. Je to moment, kdy si majitel firmy sedne a pokusí se vysvětlit, co potřebuje — a zjistí, že si není jistý, jak to říct.
To není selhání znalostí. Majitelé firem rozumí svým provozním procesům lépe než kdokoliv jiný. Problém spočívá v překladu: přeměnit to, co o svém byznysu víte, do popisu dostatečně jasného, aby ho externí tým dokázal realizovat.
Tento průvodce vám pomůže tento problém překonat.
Proč jsou požadavky důležitější, než si myslíte
Mnoho majitelů firem předpokládá, že vývojový tým si detaily vyřeší sám. Popíší hrubou představu a očekávají, že odborníci doplní zbytek.
Tento přístup téměř vždy způsobuje problémy. Vývojové týmy jsou specialisté na tvorbu softwaru, ne na vedení vašeho byznysu. Nemohou vědět, které výjimky jsou důležité, které procesy jsou klíčové nebo které situace vaši zaměstnanci aktuálně řeší ručně. Bez těchto informací dělají předpoklady — a předpoklady, byť dobře míněné, se velmi často minou cílem.
Čas investovaný do dokumentace požadavků před zahájením vývoje se mnohonásobně vrátí. Jasné požadavky snižují nedorozumění, spory o rozsah, náklady na pozdní změny a výrazně zvyšují pravděpodobnost, že to, co bude dodáno, skutečně odpovídá tomu, co jste potřebovali.
Začněte problémem, ne řešením
Nejčastější chybou při psaní požadavků je přímý přechod k popisu toho, co software má dělat — bez vysvětlení proč.
Než popíšete jakoukoli funkci, napište problém, který řeší. Ne „software má posílat automatické připomínky" — ale „naši zaměstnanci stráví tři hodiny týdně ručním kontaktováním klientů s blížícím se termínem schůzky a přibližně patnáct procent těchto hovorů zmešká, což způsobuje zrušení termínů na poslední chvíli."
Tento popis problému dává vývojovému týmu kontext. Pomáhá jim navrhnout lepší řešení, pokud existuje. Zároveň vám dává způsob, jak later vyhodnotit, zda to, co bylo vytvořeno, problém skutečně řeší — protože problém je jasně popsán.
U každé funkce, kterou chcete zahrnout, si položte otázku: jaký konkrétní problém tato funkce řeší? Pokud na ni nedokážete odpovědět, možná tato funkce ani nemusí být součástí projektu.
Popište, kdo bude software používat
Užitečné požadavky pojmenovávají osoby, které budou se systémem pracovat, a popisují, čeho se snaží dosáhnout.
Začněte výpisem všech typů uživatelů, kteří budou se softwarem interagovat. Mohou to být vaši zaměstnanci (různé kategorie s různými povinnostmi), vaši klienti nebo zákazníci, váš management nebo dokonce automatizované systémy, které se potřebují s novým softwarem propojit.
Pro každý typ uživatele popište:
- Čeho se snaží dosáhnout při používání dané části systému
- Jaké informace potřebují ke své práci
- Jaká omezení nebo pravidla platí pro to, co mohou vidět nebo dělat
- Jak často budou systém používat a v jakém kontextu
Tyto popisy uživatelů se v terminologii vývoje nazývají „user stories" a jsou mnohem užitečnější než abstraktní seznamy funkcí, protože popisují reálné chování, ne vymyšlené funkcionality.
Popisujte procesy, ne jen funkce
Nejcennější příspěvek, který do dokumentu požadavků můžete vnést, je popis toho, jak váš byznys dnes skutečně funguje — a jak chcete, aby fungoval s novým softwarem.
Projděte každý klíčový proces od začátku do konce. Co spouští proces? Kdo je zapojen v každém kroku? Jaká rozhodnutí jsou přijímána a na základě čeho? Jaké informace se předávají mezi kroky? Co se stane, když něco nejde podle plánu nebo nastane výjimka?
Tyto popisy procesů nemusí být technické. Mohou být napsány jako přímočaré příběhy nebo ilustrovány jednoduchými ručně nakreslenými vývojovými diagramy. Důležité je, aby byly úplné a přesné.
Věnujte zvláštní pozornost výjimkám a hraničním případům. Normální průběh je obvykle snadné popsat. To, co vývojáři často přehlédnou, jsou neobvyklé situace, které vaši zaměstnanci řeší každý den bez přemýšlení — objednávka se třemi různými dodacími adresami, klient s dvěma účty, platba, která přijde pozdě. Pokud tyto výjimky nejsou popsány, software je nedokáže zpracovat.
Buďte konkrétní ohledně dat
Vágní požadavky vedou k vágnímu softwaru. Čím konkrétnější budete ohledně dat, se kterými váš byznys pracuje, tím přesněji může být software vytvořen.
Pro každý typ informace, kterou bude systém spravovat, popište:
- Jaká pole nebo atributy má (například pro záznam klienta: jméno, adresa, kontaktní údaje, číslo účtu, kreditní limit, platební podmínky)
- Která pole jsou povinná a která volitelná
- V jakém formátu jsou data (telefonní čísla, data, měnové částky)
- Jaká pravidla platí (kreditní limit nesmí být záporný; rezervace nesmí být v minulosti)
- Jak dlouho mají být data uchovávána a kdo je může smazat
Nepotřebujete vědět nic o databázích ani technické implementaci. Stačí popsat informace, se kterými váš byznys pracuje, co nejpřesněji — vývojový tým dostane vše, co potřebuje.
Popište, co nechcete
Dokumenty požadavků mají tendenci soustředit se na to, co by systém měl dělat. Je stejně užitečné poznamenat, co by dělat neměl — nebo čemu musí zabraňovat.
Může to zahrnovat:
- Kdo by neměl mít přístup k určitým informacím (zaměstnanci, kteří by neměli vidět mzdové údaje; klienti, kteří by neměli vidět záznamy jiných klientů)
- Akce, které by neměly být možné za určitých podmínek (fakturu nelze smazat po přijetí platby)
- Integrace, kterým se chcete vyhnout, nebo systémy, se kterými nechcete, aby se software propojoval
- Data, která by nikdy neměla opustit vaše servery nebo být sdílena s třetími stranami
Tato omezení a restrikce jsou součástí požadavků a snadno se přehlédnou, když je pozornost zaměřena na funkce.
Popište, jak vypadá úspěch
Než vývojový tým může dodat něco, s čím budete spokojeni, musí obě strany souhlasit s tím, co znamená „hotovo".
Pro každou hlavní část systému napište, jak budete hodnotit, zda funguje správně. Nemusí to být technická testovací kritéria — může to být vyjádřeno v byznys pojmech:
„Zaměstnanec se může přihlásit, najít záznam klienta do deseti sekund a aktualizovat jeho kontaktní údaje bez nutnosti volat IT podporu."
„Systém odešle připomínku každému klientovi, jehož schůzka je do čtyřiceti osmi hodin, bez jakékoliv manuální akce ze strany zaměstnanců."
„Manažer může vygenerovat měsíční přehled příjmů pro libovolné datové rozmezí za poslední tři roky a exportovat jej do Excelu."
Tato přijímací kritéria se stávají základem pro formální testování a dávají vám jasný, jednoznačný způsob, jak software vyhodnotit před podpisem předávacího protokolu.
Prioritizujte bez slitování
Ne každý požadavek má stejnou váhu. Některé funkce jsou nezbytné — bez nich software nesplní svůj účel. Jiné jsou užitečné, ale ne kritické. Další jsou příjemné, ale přidaly by čas a náklady bez úměrné hodnoty.
Před předáním požadavků vývojovému týmu kategorizujte každou položku:
- Musí mít: projekt selže, pokud toto chybí
- Mělo by mít: důležité, ale systém může bez toho zpočátku fungovat
- Bylo by hezké mít: žádoucí, ale může být odloženo na pozdější fázi
Tato prioritizace slouží dvěma účelům. Za prvé pomáhá vývojovému týmu soustředit úsilí tam, kde to nejvíc záleží. Za druhé vám dává flexibilitu: pokud se rozpočet nebo čas omezí, přesně víte, které funkce lze odložit a které ne.
Běžnou pastí je považovat vše za nezbytné. Když je vše kritické, nic nelze škrtnout — a pak omezení rozpočtu nebo časového harmonogramu stejně vynutí škrty, ale bez jasného základu pro rozhodnutí, co obětovat. Poctivá prioritizace tomu zabraňuje.
Co dělat, když si nejste jistí
Je běžné začít psát požadavky a uvědomit si, že máte otázky, na které sami nemůžete odpovědět. Jaké platební metody má systém přijímat? Jak se má systém chovat, pokud dva zaměstnanci zkouší aktualizovat stejný záznam současně? Co se stane s historickými daty, když klient zruší smlouvu?
To jsou dobré otázky — a je mnohem lepší je vznést před zahájením vývoje, než je objevit v jeho průběhu. Možnosti zahrnují:
Poznamenejte je jako otevřené otázky. Dokument požadavků s jasným seznamem nevyřešených otázek je užitečnější než dokument, který předstírá, že je vše rozhodnuto. Vývojový tým vám může pomoci tyto otázky systematicky vyřešit.
Zapojte lidi, kteří to vědí. Vaši provozní zaměstnanci, finanční tým, zaměstnanci pracující se zákazníky — mnohé z těchto otázek mají odpovědi, protože každý den řeší situace, na nichž jsou tyto otázky postaveny. Psaní požadavků je často kolektivní cvičení, ne sólová záležitost.
Zapojte vývojový tým brzy. Mnoho vývojových partnerství začíná fází analýzy a požadavků právě proto, že společné zpracování požadavků je efektivnější než jejich samostatné psaní. Dobrý vývojový partner bude klást otázky, které vám pomohou ujasnit si myšlení — ne jen čekat na hotový dokument.
Praktický výchozí bod
Pokud jste požadavky nikdy nepsali a nevíte, kde začít, začněte zde:
- Zapište všechny procesy, které má nový software podporovat, v běžném jazyce
- Pro každý proces popište, kdo ho provádí, s čím začíná, jaké kroky následuje a co z toho vzejde
- Poznamenejte každou výjimku nebo neobvyklý případ, na který si vzpomenete
- Vypište každý typ informace, který bude systém potřebovat ukládat nebo spravovat
- Zapište svá omezení: kdo může vidět co, co systém nikdy nesmí dělat, s čím se musí propojit
- Popište, jak vypadá úspěšný výsledek pro každou oblast
Tento výchozí bod nebude dokonalý ani úplný. Ale dá vývojovému týmu něco reálného, s čím může pracovat — a zahájí konverzaci, která vede k mnohem lepšímu softwaru, než jaký by kdy mohl vzejít z vágního zadání.
Nevíte, jak strukturovat požadavky, nebo hledáte pomoc s přeměnou potřeb svého byznysu do jasného projektového briefu? Ozvěte se nám. Společné zpracování požadavků je jednou z nejcennějších věcí, které s novými klienty děláme — a často tím formujeme celý projekt k lepšímu.