
Jak definovat rozsah webové aplikace s AI: Řetězec 6 promptů, který používáme (od nápadu po SOW)
U našich posledních pěti projektů pro klienty se část, která dříve zabírala 12 až 16 hodin discovery hovorů, snížila zhruba na 3 hodiny práce s AI plus 1 hodinu lidské kontroly. Celý proces spouštíme v rámci jednoho projektu Claude, aby se kontext přenášel dál. Háček? AI pokaždé udělala tři věci špatně. Proto jsme před odesláním čehokoli klientovi přidali kontrolní bránu.
Toto je skutečný řetězec 6 promptů, který používáme, artefakt, který každý prompt vytváří, jeden kompletní zpracovaný příklad a režimy selhání, které musíte odhalit sami.
Dokáže AI definovat rozsah projektu webové aplikace? Ano. AI dokáže vytvořit návrh celého rozsahu (definice problému, uživatelské příběhy, funkce, priority MoSCoW a návrh rozsahu prací) během několika hodin místo dnů. Co nedokáže, je tento návrh ověřit. Vymýšlí si požadavky a podceňuje náročnost, takže lidská kontrola před podpisem je nezbytná.
Klíčová zjištění
- AI vytvoří návrh celého rozsahu webové aplikace během hodin, ne dnů, ale nedokáže ověřit vlastní výstup.
- Řetězec tvoří šest promptů: problém, uživatelské příběhy, funkce, MoSCoW, odhad, SOW.
- AI si vymýšlí integrace a podceňuje okrajové případy, proto vždy proveďte lidskou kontrolu.
- Pro tento řetězec používejte Claude Projects nebo ChatGPT Projects; agenti přicházejí na řadu až po podpisu rozsahu.
AI dokáže napsat první návrh vašeho rozsahu během jednoho odpoledne. Jen vám neřekne, kdy se mýlí.
Co je to scoping s pomocí AI (a co to NENÍ)?
Scoping s pomocí AI znamená použití série promptů pro velké jazykové modely (LLM) k proměně hrubého nápadu ve strukturované artefakty rozsahu: požadavky, uživatelské příběhy, seznam funkcí, priority a návrh rozsahu prací (SOW). AI provádí drafting a strukturování. Člověk stále rozhoduje, vede rozhovory se stakeholdery a provádí validaci.
Takže za vás AI přemýšlí? Ne tak docela. Je rychlá v ai sběru požadavků, tedy v té části, kdy zíráte na prázdnou stránku a snažíte se převést „chci aplikaci na rezervace“ na něco, co může developer ocenit. Špatně však rozpoznává, co klient skutečně potřebuje, oproti tomu, co jen zní věrohodně.
Pár věcí, kterými scoping s pomocí AI není: není autonomní, nenahrazuje rozhovory se skutečnými stakeholdery a nezaručuje přesnost. Model s radostí napíše sebevědomou, dobře naformátovanou specifikaci pro funkci, o kterou nikdo nežádal.
Tento článek předpokládá, že již rozumíte samotnému procesu definování rozsahu. Pokud chcete základy, náš průvodce krok za krokem prochází underlying non-AI proces, 7 kroků a plnou strukturu dokumentu o rozsahu. Zde se držíme vrstvy AI: který prompt, v jakém pořadí a kde se to kazí.
Přehled řetězce promptů pro scoping s AI
Řetězec tvoří šest promptů spuštěných sekvenčně, přičemž výstup každého z nich slouží jako vstup pro další. V pořadí: (1) problém a cíle, (2) uživatelské příběhy, (3) seznam funkcí, (4) prioritizace MoSCoW, (5) odhad úsilí, nákladů a časového harmonogramu a (6) návrh SOW. Spouštějte je v rámci jednoho projektu, aby přetrvával kontext.
To nejlepší na tom je: protože každý prompt navazuje na předchozí, nemusíte svou aplikaci vysvětlovat šestkrát. Model již zná problém, když píše uživatelské příběhy, a již zná příběhy, když prioritizuje funkce.
- Problém a cíle: promění hrubý nápad v definici problému a SMART cíle.
- Uživatelské příběhy: převede cíle na uživatelské příběhy s kritérii přijetí.
- Seznam funkcí: odvodí konkrétní inventář funkcí z příběhů.
- Prioritizace MoSCoW: rozdělí funkce do kategorií Must (Musí mít), Should (Mělo by mít), Could (Mohlo by mít), Won't (Nebude mít).
- Odhad: vytvoří odhad úsilí, rozmezí nákladů a časový harmonogram.
- Návrh SOW: spojí vše do návrhu rozsahu prací.

Jedná se také o čistý soubor ai promptů pro projektové řízení obecně, ale každý prompt jsme vyladili specificky pro webové aplikace (technologický stack, integrace, okrajové případy). Právě toto vyladění odděluje použitelný rozsah od toho generického.
Trik není v jednom magickém promptu. Je v šesti promptech, které si předávají své výstupy.
Jak spustit řetězec krok za krokem?
Řetězec spouštíte shora dolů v rámci jednoho projektu Claude Project nebo ChatGPT Project, vkládáte každý prompt v pořadí a necháváte předchozí odpověď v kontextu. Níže najdete šest jednoduchých kroků s přesnými prompty, které používáme. Každý je záměrně specifický pro webové aplikace, protože generické prompty pro business analýzu produkují generické rozsahy.
Poznámka před začátkem: nahraďte zástupné symboly v hranatých závorkách svými vlastními detaily a nikdy nepřijímejte první výstup jako finální. Profesionální postup je přečíst si každý výsledek, opravit ho a poté spustit další prompt.
Prompt 1: Definice problému a cíle
You are a senior product manager scoping a web application.
Here is the rough idea: [describe the app in 2-4 sentences].
The target users are [who]. The business wants [outcome].
Write:
1. A one-paragraph problem statement.
2. 3-5 SMART goals with success metrics.
3. 3 assumptions you are making that I should confirm.
Flag anything that is unclear instead of guessing.Tím získáte sekci přehledu a cílů. Prof tip: řádek „3 předpoklady“ odvádí těžkou práci. Odhaluje mezery, které by AI jinak zametla pod koberec.
Prompt 2: Uživatelské příběhy
Acting as the same product manager, turn the goals above into
user stories for a web app. Use the format:
"As a [role], I want [action], so that [benefit]."
Cover every user role. For each story, add 2-3 acceptance
criteria. Group stories by feature area.Nyní máte funkční požadavky. Toto je čistý krok ai generátoru uživatelských příběhů. Pozor: má tendenci zapomínat na administrátory a role v okrajových případech, takže ji znovu vyzvěte: „nyní přidej příběhy pro adminy, neúspěšné platby a prázdné stavy.“
Prompt 3: Seznam funkcí
Based on the user stories above, produce a flat feature
inventory for this web app. Group features into: core, account
and auth, admin, integrations, and notifications. Note any
feature that requires a third-party service or API.Toto je váš kandidátský seznam funkcí v rozsahu. Sledujte tento krok pečlivě, protože zde AI začíná vymýšlet integrace (více o tom později).
Prompt 4: Prioritizace MoSCoW
Prioritize the feature list using MoSCoW (Must, Should, Could,
Won't) for a first release (MVP). For each feature give a
one-line reason. Assume a 3-month MVP budget and be ruthless:
most features should NOT be "Must."Tím označíte položky v rozsahu a mimo rozsah. Instrukce „buďte nemilosrdní“ je důležitá; bez ní model označí téměř vše jako Must (Musí mít).
Prompt 5: Odhad úsilí, nákladů a časového harmonogramu
Estimate effort, cost, and timeline for the Must-have features
only. Assume a stack of [e.g. Next.js, Supabase, Stripe] and a
team of [N] developers. Break the estimate down by feature in
days. State every assumption. Give a cost RANGE, not a single
number, and flag the 3 riskiest estimates.Toto je vstup pro váš ai generátor rozsahu prací týkající se rozpočtu a harmonogramu. Vždy vyžadujte rozmezí a předpoklady, protože jediné sebevědomé číslo je nejnebezpečnější výstup, který vám AI dá.
Prompt 6: Návrh SOW
Assemble everything above into a draft statement of work for a
client. Include: overview, goals and success metrics, in-scope
features, explicit out-of-scope items, timeline, budget range,
deliverables, assumptions, and a sign-off section. Mark any
section where you are uncertain with [REVIEW].Značky [REVIEW] se stanou vaším kontrolním seznamem pro lidskou bránu. Tento krok sestavuje celý span od nápadu po SOW, který celý řetězec sliboval.
Mapování Prompt → Sekce rozsahu
Každý prompt nejen odpovídá na otázku, ale vyplňuje konkrétní sekci dokumentu, který předáte klientovi. Toto mapování nahrazuje obvyklou 11sekční šablonu: místo memorování kostry spustíte řetězec a dokument se sestaví sám. Zde je uvedeno, který prompt produkuje který deliverable.
| Prompt | Produkuje | Sekci dokumentu o rozsahu, kterou vyplňuje |
|---|---|---|
| 1. Problém a cíle | Definice problému + SMART cíle | Přehled, Cíle a metriky úspěchu |
| 2. Uživatelské příběhy | Uživatelské příběhy + kritéria přijetí | Funkční požadavky |
| 3. Seznam funkcí | Inventář funkcí | Funkce v rozsahu |
| 4. MoSCoW | Prioritizované Must/Should/Could/Won't | V rozsahu (označeno) + Mimo rozsah |
| 5. Odhad | Úsilí, rozmezí nákladů, harmonogram | Harmonogram, Rozmezí rozpočtu |
| 6. Návrh SOW | Sestavený návrh rozsahu prací | Celý SOW + deliverables + podpis |
Do doby, než dokončíte Prompt 6, máte kompletní první návrh dokumentu, který si klient může skutečně přečíst a podepsat, nikoli hromadu nesouvisejících poznámek.
Každý prompt nejen odpovídá na otázku. Vyplňuje konkrétní sekci dokumentu, který předáte klientovi.
Kompletní příklad: Definice rozsahu SaaS pro rezervaci termínů
Zde je řetězec spuštěný od začátku do konce na jednom konkrétním případě: SaaS pro rezervaci termínů pro malý řetězec zubních ordinací. Jedná se o ilustrativní příklad, nikoli o skutečný deliverable pro klienta, a ano, zachytili jsme dvě chyby ve výstupu AI, které opravujeme v sekci lidské kontroly níže.
Výstup Promptu 1 (problém a cíle). Problém: třílokacní řetězec zubních ordinací ztrácí rezervace kvůli telefonním honičkám a nedostavení se pacientů. Cíle: snížit nedostavení o 30 % prostřednictvím připomínek, umožnit pacientům self-booking online a poskytnout personálu na recepci jeden sdílený kalendář. Označené předpoklady: jedno časové pásmo, pouze angličtina, žádné fakturace pojišťovnám.
Výstup Promptu 2 (ukázkové uživatelské příběhy).
- Jako pacient chci rezervovat termín online, abych nemusel volat.
- Jako pacient chci SMS připomenutí, abych nezapomněl na svůj termín.
- Jako personál recepce chci vidět všechny tři lokace v jednom kalendáři, abych mohl spravovat překryvy.
Výstup Promptu 3 (seznam funkcí, zkráceně). Online rezervace, synchronizace kalendáře, SMS a e-mailové připomenutí, účty pacientů, administrace více lokací, základní reportování a platební krok (tento poslední byl vymyšlen; nikdo o něj nežádal).
Výstup Promptu 4 (mřížka MoSCoW).
| Priorita | Funkce |
|---|---|
| Must | Online rezervace, kalendář pro více lokací, SMS připomenutí, účty pacientů |
| Should | E-mailová připomenutí, základní reportování |
| Could | Self-rescheduling pacientů |
| Won't (v1) | Platby, fakturace pojišťovnám, nativní mobilní aplikace |

Výstup Promptu 5 (odhad, zkráceně). Za předpokladu Next.js, Supabase a Twilio se dvěma developery: funkce Must-have zhruba 45 až 60 developer-days, rozmezí nákladů kolem 35 000 $ až 55 000 $ a harmonogram 8 až 10 týdnů. Nejrizikovější odhad označen: logika kalendáře pro více lokací.
Výstup Promptu 6 (úryvek SOW). „V rozsahu: online rezervace, sdílený kalendář pro více lokací, SMS připomenutí (Twilio), účty pacientů. Mimo rozsah: platby, pojištění, nativní mobilní aplikace. Harmonogram: 8–10 týdnů. Rozmezí rozpočtu: 35 000 $–55 000 $. [REVIEW] Potvrďte s klientem Twilio vs alternativní poskytovatel SMS.“
Prohlédněte si to a uvidíte, že skutečný, podepsatelný rozsah nabral tvar během jednoho sezení. Pokud plánujete později přidat chytré funkce, náš průvodce jak přidat AI funkce do vaší aplikace navazuje tam, kde tento končí.
Jak odhadnout náklady a harmonogram s AI?
Vyzvete model, aby rozložil odhad podle funkcí ve dnech, předpokládal specifický technologický stack, uvedl každý předpoklad a vrátil rozmezí namísto jednoho čísla. Poté toto rozmezí sanity-checknete proti známým tržním hladinám, protože AI se téměř vždy příliš optimisticky kotví v úsilí.
Berte odhady AI jako starting point, nikdy jako quote. Nejužitečnější instrukcí je „označ tři nejrizikovější odhady“, což vám přesně řekne, kde máte vynaložit vlastní úsudek. Zde jsou hladiny, proti kterým kontrolujeme každý odhad AI.
| Složitost webové aplikace | Typické rozmezí nákladů | Typický harmonogram |
|---|---|---|
| Jednoduché MVP | 10 000 $–50 000 $ | 1–3 měsíce |
| Střední (auth, platby, dashboard) | 50 000 $–100 000 $ | 3–6 měsíců |
| Komplexní (více rolí, integrace, škálování) | 75 000 $–150 000 $+ | 6–12 měsíců |
Tato rozmezí odpovídají publikovaným benchmarkům agentur a tržišť; výzkum nákladů na vývoj aplikací od Clutch je rozumným veřejným referenčním bodem. Pokud váš odhad AI spadne hluboko pod příslušnou hladinu, pravděpodobně přehlédla okrajové případy. To je také moment, kdy si položit větší otázku: build vs buy. Rozsah, který nafoukne nad komplexní hladinu, někdy argumentuje pro koupi místo stavby.
Jaký AI nástroj použít pro každou práci?
Pro celý řetězec používejte Claude Projects nebo ChatGPT Projects, protože oba uchovávají kontext napříč prompty, takže se výstup přenáší dál bez opětovného vkládání. Samostatného agenta použijte až po podpisu rozsahu, kdy generujete opakovatelné artefakty. Pro jednorázový scoping vítězí Projects nad agentem pokaždé.
Řetězec spouštíme v Claude Projects pro kroky s dlouhým kontextem (uživatelské příběhy, sestavení SOW) a saháme po ChatGPT, když chceme druhý názor na odhad. Podle dokumentace Anthropic Projects Projekt udržuje sdílený kontext a instrukce napříč konverzací, což je přesně to, co workflow claude projects for requirements se šesti prompty potřebuje. Projekty OpenAI fungují stejně pro chatgpt prompts software development.
Jedna technika, kterou stojí za to ukrást: rozdělte roli AI podle kroku. Řekněte jí „jednej jako product manager“ pro uživatelské příběhy a „jednej jako senior engineer“ pro odhad. Změna role mění způsob, jakým uvažuje, a persona inženýra je znatelně konzervativnější v odhadu úsilí.
Jakmile je rozsah hotov a stavba začíná, otázka nástrojů se posouvá k AI coding agents, což je zcela jiné rozhodnutí.
Kde AI při scoping selhává? Brána lidské validace
AI selhává ve scoping předvídatelnými způsoby: halucinuje integrace, o které nikdo nežádal, podceňuje okrajové případy a chybové stavy a buď si vymýšlí compliance požadavky, nebo tiše vynechává ty skutečné. Také příliš optimisticky kotví odhady nákladů. Nic z toho není vzácné; stává se to prakticky při každém běhu, proto je lidská brána nepostradatelná.
Špatné požadavky jsou drahé, ať je píše člověk, nebo model. Výzkum PMI Pulse of the Profession zjistil, že nepřesný sběr požadavků je hlavní příčinou selhání projektu v přibližně 37 % neúspěšných projektů, takže cílem brány je zachytit tyto nedostatky dříve, než se dostanou do quote, ne až poté.
Řešením je krátký kontrolní seznam, který člověk provede, než se jakýkoli rozsah dostane ke klientovi:
- Smažte vymyšlené funkce: odstraňte vše (platby, exporty, integrace), o co klient nikdy nežádal.
- Přidejte chybějící okrajové případy: neúspěšné platby, prázdné stavy, oprávnění, zpracování chyb.
- Ověřte každou integraci: potvrďte, že každá pojmenovaná third-party služba je reálná, potřebná a zahrnutá v rozpočtu.
- Zkontrolujte tvrzení o compliance: potvrďte nebo opravte jakýkoli požadavek na auth, soukromí nebo regulaci, který AI uvedla.
- Navýšte odhad: upravte optimistická čísla podle vlastní velocity, zejména ta označená jako riziková.
AI sebevědomě definuje rozsah platebního toku, který si vymyslela. Vaším úkolem je smazat části, o které nikdo nežádal.
Co jsme se naučili při používání tohoto postupu na skutečných projektech klientů
V našich posledních několika projektech pro klienty se discovery, které dříve trvalo zhruba 12 až 16 hodin hovorů a zapisování, nyní změní na první návrh SOW za asi 2 až 3 hodiny práce s AI plus 1 hodinu lidské kontroly. Jedná se o upřímná rozmezí z našich vlastních běhů, nikoli o přesnou headline statistiku, a ona lidská hodina je ta, kterou nikdy neškrtáme.
Řetězec spouštíme v Claude Projects, s ChatGPT jako sanity-checkem odhadů. Ušetřený čas je reálný, ale hodnota spočívá v zachycení stejných tří selhání pokaždé:
- Vymýšlí si integrace. Platební krok v příkladu se zubařem, o který nikdo nežádal. Téměř každý rozsah měl alespoň jednu fantomovou funkci.
- Podceňuje okrajové případy. Chybové stavy, prázdné stavy a admin flow jsou konzistentně chybějící nebo podceněné, což je místo, kde skutečné rozpočty explodují.
- Špatně zachází s compliance a auth. Někdy si halucinuje požadavek, někdy vynechá ten skutečný. Tomuto nikdy nedůvěřujeme.
Proto jsme výše uvedenou lidskou bránu přidali jako pevný krok. Řetězec rychle napíše návrh; brána je to, co činí jeho odeslání bezpečným. Přeskočte bránu a pouze odesíláte sebevědomý, dobře naformátovaný odhad.
Jak Techsy přistupuje k scoping s pomocí AI
Tento řetězec plus lidská brána je přesně workflow, které spouštíme pro klienty budující webové aplikace. Rychle draftujeme s AI, poté člověk, který má za sebou skutečné builds, validuje každý řádek, než se stane quotou. Pokud raději předáte rozsah týmu, který to dělá denně, to je to, co děláme. Získáte obhajitelný SOW bez placení za dva týdny discovery hovorů předem.
O autorovi
Mert Batur Gurbuz je spoluzakladatelem Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o LLM tooling stacku, který tým Techsy skutečně používá v produkci.
Spoluzakladatel, Techsy.io — University of Birmingham. Spoďte se na LinkedIn.
Často kladené otázky
Může AI napsat projektový scope nebo SOW?
Ano, AI dokáže vytvořit návrh kompletního projektového scope nebo návrhu rozsahu prací, včetně problému, uživatelských příběhů, funkcí, priorit, harmonogramu a rozmezí rozpočtu. Spusťte řetězec šesti promptů v rámci projektu Claude nebo ChatGPT. Návrh je spolehlivý jako starting point, ale člověk jej musí před podpisem validovat.
Jaký je nejlepší AI nástroj pro definici rozsahu softwarového projektu?
Claude Projects a ChatGPT Projects jsou nejlepšími nástroji pro scoping, protože oba uchovávají kontext napříč řetězcem promptů, takže každý výstup napájí další. Používáme Claude Projects pro kroky s dlouhým kontextem, jako jsou uživatelské příběhy a sestavení SOW, a ChatGPT jako druhý názor na odhady. Agenti jsou lépe vhodní pro práci po definici rozsahu.
Jak používat ChatGPT nebo Claude ke sběru požadavků?
Spusťte řetězec promptů v pořadí: požádejte o definici problému a cíle, poté uživatelské příběhy s kritérii přijetí, poté seznam funkcí, poté priority MoSCoW. Udržujte vše v jednom Projektu, aby se kontext přenášel dál. Výstup každého promptu se stává vstupem pro další, což činí ai sběr požadavků rychlým.
Může AI odhadnout náklady a harmonogram softwarového projektu?
Ano, ale pouze jako starting point. Vyzvěte model, aby rozložil odhad podle funkcí ve dnech, předpokládal specifický stack, uvedl své předpoklady a vrátil rozmezí. Poté proveďte sanity-check proti tržním hladinám: 10 000 $–50 000 $ pro jednoduché MVP, až 150 000 $+ pro komplexní aplikace. AI má tendenci kotvit příliš optimisticky.
Je scope generovaný AI skutečně spolehlivý?
Spolehlivý pro první návrh, ne pro podpis. AI rychle vytvoří dobře strukturovaný scope, ale téměř při každém běhu si vymýšlí integrace, podceňuje okrajové případy a špatně zachází s compliance. Berte výstup jako rychlý návrh, poté spusťte bránu lidské validace, abyste smazali vymyšlené funkce a přidali chybějící okrajové případy, než kdokoli podepíše.
Jak proměnit hrubý nápad ve specifikaci s AI?
Začněte Promptem 1: vložte svůj nápad ve dvou až čtyřech větách a požádejte AI, aby napsala definici problému, SMART cíle a předpoklady, které činí. Poté spusťte dalších pět promptů v sekvenčním pořadí. Do Promptu 6 máte návrh SOW. Celý řetězec zabere několik hodin místo dnů.
Nahrazuje scoping s pomocí AI fázi discovery?
Ne, komprimuje discovery, nikoli ji nahrazuje. Stále potřebujete skutečné rozhovory se stakeholdery, abyste věděli, co klient skutečně chce. AI zpracovává drafting a strukturování, promění vaše poznámky v požadavky a SOW během hodin. Lidé stále validují, prioritizují a činí konečná rozhodnutí o rozsahu.
Jak dlouho trvá definice rozsahu webové aplikace s AI?
Podle našich zkušeností trvá první návrh SOW zhruba 2 až 3 hodiny práce s AI plus asi 1 hodinu lidské kontroly, oproti 12 až 16 hodinám manuálního discovery a zapisování. Čas AI je rychlý; hodina review je nepostradatelná, protože právě zde zachytíte funkce, které si AI vymyslela, a okrajové případy, které přehlédla.