← Všechny články
Postavte správný produkt
Jak napsat jednostránkové produktové zadání, které se skutečně používá
Od týmu FabricLoop · Květen 2026 · 4 minuty čtení
Většina produktových zadání sdílí stejný osud: pečlivě se napíší před startem projektu, jednou se probere na kickoff schůzce a pak už je nikdo neotevře. Když je tým uprostřed vývoje, je zadání historickým artefaktem — občas se na něj někdo odvolá ve sporu o rozsah, ale jen výjimečně slouží jako živý průvodce rozhodováním.
To je selhání procesu, ne formátu. Zadání se nepoužívá, protože nebylo napsáno, aby se používalo. Vzniklo proto, aby vyhovělo procesu — aby se dalo odškrtnout „požadavky jsme definovali“ — ne aby týmu skutečně pomáhalo rozhodovat se lépe v nejistotě.
Zadání, které se používá, je krátké, má jasný názor a je postavené kolem otázek, které si tým skutečně bude klást uprostřed vývoje: co řešíme, pro koho a jak poznáme, že to zabralo?
„Zadání není dokument s požadavky. Je to opora pro rozhodování — jedna stránka, ke které se tým může vrátit, kdykoli si není jistý, zda je designové rozhodnutí nebo rozhodnutí o rozsahu správné.“
Pět sekcí, na kterých záleží
Cokoli v produktovém zadání by mělo odpovídat na jednu z pěti otázek. Pokud sekce na žádnou z nich neodpovídá, do jednostránkového zadání pravděpodobně nepatří — patří do samostatné, podrobnější specifikace.
Problém
Uživatelům unikají důležité aktualizace, protože nedokážou rozlišit mezi oznámeními s vysokým signálem (někdo jim přidělil úkol) a s nízkým signálem (komentář ve vlákně, které sledují). Výsledek: buď ignorují všechna oznámení, nebo je úplně vypnou. Tikety podpory typu „nevěděl jsem to“ tvoří 18 % všech stížností na produkt v tomto čtvrtletí.
Uživatelé
Primární: vedoucí týmů a vlastníci projektů, kteří jsou často zmiňováni a nestíhají objem. Sekundární: jednotliví přispěvatelé, kteří chtějí mít ve výchozím stavu klid, ale potřebují zachytit kritická přidělení úkolů. Necílíme na administrátory — jejich potřeby oznámení řeší administrátorský panel.
Metrika úspěchu
Primární Vstupenky podpory související s oznámeními se sníží o 40% do 60 dnů od spuštění.
Sekundární Týdenně aktivní uživatelé, kteří si přizpůsobili předvolby, se zvýší z 12% na 35%.
Vedoucí indikátor Sazba odhlášení (uživatelé, kteří vypnout všechna oznámení) klesne z 23% na méně než 15%.
Mimo rozsah
- Předvolby e-mailových oznámení (samostatná položka práce — jiná infrastruktura)
- Nastavení oznámení pro jednotlivé pracovní prostory (v budoucnu; toto vydání je jen pro jednotlivé uživatele)
- Plánování oznámení / hodiny nerušení (ověřená potřeba, roadmapa na 3. čtvrtletí)
- Podrobné nastavení mobilních push oznámení (nejdřív web; mobil bude následovat, pokud se potřeba ověří)
Otevřené otázky
Blokující Máme rozdělit oznámení do 2 úrovní (kritické / všechno ostatní) nebo umožnit granulární kontrolu na typ? Pohovory s uživateli naznačují 2 úrovně, ale inženýrství upřednostňuje granulární flexibilitu. Rozhodnutí potřebné před zahájením návrhu.
Neblokující Měly by se změny předvoleb vztahovat zpětně na stávající oznámení? Lze se rozhodnout během stavby na základě technických nákladů.
Proč je „mimo rozsah“ nejdůležitější sekce
Týmy tráví spoustu času psaním toho, co postaví. Psaním toho, co nepostaví, tráví jen velmi málo času — a právě tato asymetrie způsobuje většinu rozbujení rozsahu (scope creep). Když designér přidá přepínač „tiché hodiny“, protože se to zdá samozřejmé, nebo vývojář přidá nastavení pro jednotlivé pracovní prostory, protože už je poblíž, bývá důvod obvykle ten, že nikdo výslovně nerozhodl, že to je mimo rozsah.
Sepsání položek mimo rozsah vynutí rozhovor o hranicích, který by jinak proběhl uprostřed vývoje, kdy je změna kurzu mnohem dražší. Také dává produktovému manažerovi jasný, zdokumentovaný podklad pro odmítnutí dodatků: „V zadání jsme rozhodli, že to je mimo rozsah — a tady je proč.“
Jak psát dobré položky mimo rozsah
Nevypisujte jen to, co nebudete stavět — stručně uveďte i proč. „E-mailové předvolby (samostatná infrastruktura)“ čtenáři sděluje, že rozhodnutí bylo záměrné a odůvodněné, ne přehlédnutí. Zabrání se tak tomu, aby se stejná otázka rozsahu během sprintu vynořila třikrát.
Otevřené otázky: sekce, kterou většina zadání vynechává
Každý projekt začíná s nevyřešenými otázkami. Většina zadání předstírá opak — jsou psaná, jako by všechna rozhodnutí padla, i když autor ví, že nepadla. Výsledkem je, že tým otevřené otázky objeví uprostřed vývoje, kdy dělají nejvíc škody.
Výslovné vypsání otevřených otázek dělá dvě věci. Za prvé odliší otázky, které je třeba vyřešit před zahájením práce (blokující), od těch, které lze rozhodnout během vývoje (neblokující). Za druhé dává týmu najevo, že zadání je pracovní dokument, ne hotová specifikace — takže je pravděpodobnější, že se k němu bude vracet a aktualizovat ho, jakmile se rozhodnutí přijmou.
Past délky
Zadání, které přeroste jednu stránku, už není zadání — je to specifikace. Specifikace mají své místo, ale slouží jinému účelu. Pokud zjistíte, že potřebujete víc než jednu stránku, přesuňte detaily do odkazované přílohy a zadání nechte u pěti základních sekcí.
Jak FabricLoop udržuje zadání při životě
Zadání zůstane užitečné, jen když ho tým dokáže najít a aktualizovat. FabricLoop připne zadání do vlákna projektu, takže je vždy na jedno kliknutí — a konverzace kolem něj (přijatá rozhodnutí, vyřešené otevřené otázky, změny rozsahu) je hned po ruce v kontextu, ne roztroušená po e-mailech a Slacku.
10 poznatků z tohoto článku
- Většina produktových zadání se píše proto, aby vyhověla procesu, ne aby týmům pomáhala rozhodovat se lépe. Proto se k nim nikdo nevrací.
- Zadání je opora pro rozhodování, ne dokument s požadavky. Mělo by odpovídat na otázky, které vznikají uprostřed vývoje.
- Pět sekcí, na kterých záleží: Problém, Uživatelé, Metrika úspěchu, Mimo rozsah, Otevřené otázky. Vše ostatní je specifikace.
- Sekce o problému by měla popisovat bolest uživatele konkrétně — pokud možno s daty — a ne jen pojmenovat oblast, které se věnujeme.
- Pojmenovat, pro koho nestavíte, je stejně důležité jako pojmenovat, pro koho stavíte. Nejasnost ohledně uživatelů způsobuje rozbujení rozsahu už v designu.
- Metriky úspěchu musí být měřitelné, časově ohraničené a odsouhlasené před zahájením vývoje — ne dodatečně odvozené z dat o používání.
- Sekce mimo rozsah je nejdůležitější. Nezapsané hranice rozsahu se během vývoje spolehlivě rozšíří.
- U položek mimo rozsah stručně uveďte důvody, aby se stejné otázky nevynořovaly znovu během sprintu.
- Otevřené otázky by měly být výslovně označeny jako blokující (rozhodnout před vývojem) nebo neblokující (rozhodnout během vývoje).
- Zadání, které přesáhne jednu stránku, se stalo specifikací. Detaily přesuňte do přílohy a zadání udržte stručné.
