Stručný popis žádosti
Jak informovat o vlastní aplikaci bez zápisu technické specifikace.
Příprava užitečné aplikace stručný s uživateli, workflow, ukázkové záznamy, závislostí a příklady přijetí, bez psaní technické specifikace.
Development stručný nemusí začínat s databázovým diagramem. Musí vysvětlit práci, kterou by někdo měl být schopen dokončit a výsledek vaše podnikání potřebuje z něj.
Cílem první zprávy je, aby se projekt diskutoval. Můžete nechat technická rozhodnutí otevřená a zároveň být přesní o práci, kterou musí aplikace podporovat.
Začněte s uživatelem a úlohou
"Vybudovat portál" označuje typ softwaru. "Nechte schváleného zákazníka předložit žádost o službu a uvidíte jeho pokrok" popisuje užitečný první pracovní postup.
Jmenujte uživatele, akci a výsledek. Pak identifikujte, kdo se stará o druhou stranu procesu. V tomto případě musí zaměstnanec žádost přezkoumat a aktualizovat její stav. To znamená, že stručná zpráva již obsahuje dvě různé role a sdílený záznam.
Vyhněte se začínajícím "app for everyone". Různé uživatelé mohou potřebovat různá oprávnění, obrazovky a informace. Rozhodněte se, která role je nejdůležitější v prvním vydání.
Vysvětli mi, co se dnes stane.
Popište aktuální kroky v běžném jazyce. Možná zákazník e-mailem informace, zaměstnanec zkopíruje do tabulky a další osoba pošle pokrok aktualizace. Stav, kde zmatek nebo opakované úsilí dochází, aniž by předpokládal, že software vyřeší každý okolní problém.
Upravený příklad aktuálního formuláře nebo záznamu může být užitečnější než leštěná prezentace. Odstraňte osobní údaje a důvěrné údaje před jejich sdílením.
Popište jednu kompletní cestu
Následujte reprezentativní záznam od začátku do konce. Co to začíná? Které informace je třeba? Kdo učiní další rozhodnutí? Co znamená, že je kompletní?
Zahrňte jednu nebo dvě důležité výjimky. Žádost může být neúplná, recenzent může odmítnout nebo uživatel může muset opravit chybu. Tyto případy pomáhají rozlišit pracovní aplikaci od demonstrace ideální cesty.
Nemusíte si vymýšlet každou vzácnou událost v této fázi. Soustřeďte se na výjimky, které by zabránily tomu, aby byl hlavní pracovní proud užitečný.
Název údajů a závislostí
Seznam důležitých záznamů: uživatelé, žádosti, produkty, rezervace, soubory nebo jiný soubor informací. Vysvětlete, odkud pocházejí a kdo je zodpovědný za jejich údržbu.
Pro integraci pojmenujte druhou službu a poskytněte její dokumentaci, pokud je k dispozici. "Připojte se k našemu CRM" nechává otevřené hlavní otázky. Užitečný detail je, který záznam by se měl pohybovat, v jakém směru a po které události.
Určete, zda jsou návrhy, obsah produktu, přístup k účtu nebo obchodní pravidla již k dispozici. Chybějící materiály nejsou automaticky blokátory, ale potřebují vlastníka a místo v plánu.
Definovat první použitelnou verzi
Oddělte jádro dodávky od pozdějších myšlenek. První portál by mohl podpořit vytvoření požadavku, přezkum a zobrazení stavu. Zprávy, pokročilé hlášení a mobilní aplikace by mohly být pozdější diskuse spíše než nevyřčené požadavky na první stavět.
To není návod k vytvoření něčeho neúplného. Zvolený pracovní postup by měl fungovat od začátku do konce. Hranice je mezi kompletní pracovní toky, ne mezi atraktivní obrazovku a logiku, kterou stále potřebuje.
Napište příklad přijetí
Zkus větu, kterou by někdo mohl otestovat:
Schválený zákazník může podat žádost, po podepsání se podívat na svůj status a prohlédnout si pouze své vlastní požadavky. Schválený zaměstnanec může stav aktualizovat a zákazník to vidí.
To je ilustrativní požadavek, ne popis stávajícího klientského projektu. To dělá očekávané chování mnohem jasnější než "moderní, bezpečný portál". Případný rozsah může vylepšit oprávnění a hrany případy.
Přidat praktická omezení
Uveďte své požadované načasování, ať už se jedná o přednostní nebo pevné externí datum, a rozpočtové rozpětí, pokud je známo. Jmenujte osobu, která může schválit rozhodnutí a vysvětlit, jak budou návrhy nebo zpětnou vazbu dodány.
Popište uvolnění a předání očekávání příliš. Kdo bude vlastnit hosting a účty? Má jiný vývojář musí přijmout kód? Tyto otázky ovlivňují dodání i když se neobjeví na obrazovce.
Krátký, který můžete použít.
Chceme stavět: aplikace nebo pracovní postup. Hlavními uživateli jsou: Lidem a rolím. Musí: hlavní úkol a dokončený výsledek. Dnes se to děje skrz: současný proces. První verze musí obsahovat: základní kompletní pracovní postup. Musí se připojit k: známých systémů a dokumentace. Už máme: návrhy, obsah, účty nebo ukázková data. Stále nerozhodnutá: Otázky k vyřešení. Časování, rozpočet a rozhodčí: praktická omezení.
Použít několik jasných vět pro každou část. Stručný bod je výchozí bod pro definování projektu, ne test, který je třeba projít, než mluvit s vývojářem.
Diskuse o vlastní webové aplikaci nebo odešlete zadání projektu.

