Jak określić zakres projektu aplikacji webowej z AI: Łańcuch 6 promptów, którego używamy (od pomysłu do SOW)

Jak określić zakres projektu aplikacji webowej z AI: Łańcuch 6 promptów, którego używamy (od pomysłu do SOW)

W przypadku naszych ostatnich pięciu projektów dla klientów, część procesu, która kiedyś pochłaniała 12–16 godzin spotkań discovery, skróciła się do około 3 godzin pracy z AI plus 1 godzina ludzkiej weryfikacji. Cały proces przeprowadzamy w ramach jednego projektu Claude, dzięki czemu kontekst jest zachowywany. Jest jednak haczyk: AI za każdym razem myliło się w trzech kwestiach. Dlatego dodaliśmy etap bramki kontrolnej, zanim cokolwiek trafi do klienta.

Oto rzeczywisty łańcuch 6 promptów, którego używamy, artefakt wytwarzany przez każdy prompt, jeden pełny przepracowany przykład oraz tryby awarii, które musisz wyłapać samodzielnie.

Czy AI może określić zakres projektu aplikacji webowej? Tak. AI może stworzyć szkic pełnego zakresu (opis problemu, user stories, funkcje, priorytetyzację MoSCoW oraz Statement of Work) w ciągu kilku godzin zamiast dni. Czego nie potrafi zrobić, to zwalidować ten szkic. AI wymyśla wymagania i niedoszacowuje nakładu pracy, dlatego ludzka weryfikacja jest obowiązkowa przed finalizacją.

Kluczowe wnioski

• AI tworzy szkic pełnego zakresu aplikacji webowej w godziny, a nie dni, ale nie potrafi zwalidować własnych wyników.
• Łańcuch składa się z sześciu promptów: problem, user stories, funkcje, MoSCoW, szacunek, SOW.
• AI wymyśla integracje i niedoszacowuje przypadki brzegowe, więc zawsze stosuj ludzką weryfikację.
• Używaj Claude Projects lub ChatGPT Projects do realizacji łańcucha; agenci są potrzebni dopiero po podpisaniu zakresu.

AI może napisać pierwszy szkic zakresu w jedno popołudnie. Po prostu nie powie Ci, kiedy się myli.

Czym jest wspomaganie AI w określaniu zakresu (a czym NIE jest)?

Wspomaganie AI w określaniu zakresu oznacza użycie serii promptów LLM do przekształcenia zgrubnego pomysłu w uporządkowane artefakty zakresu: wymagania, user stories, listę funkcji, priorytety oraz Statement of Work. AI zajmuje się szkicowaniem i strukturyzowaniem. Człowiek nadal podejmuje decyzje, prowadzi rozmowy z interesariuszami i dokonuje walidacji.

Czyli czy AI myśli za Ciebie? Nie do końca. Jest szybkie w zbieraniu wymagań z ai, czyli w tej fazie, gdy gapisz się w pustą stronę i próbujesz przetłumaczyć „chcę aplikację do rezerwacji” na coś, co developer będzie mógł wycenić. Jest jednak słabe w rozróżnianiu tego, czego klient naprawdę potrzebuje, od tego, co brzmi wiarygodnie.

Kilka rzeczy, którymi wspomaganie AI w określaniu zakresu nie jest: nie jest autonomiczne, nie zastępuje rozmów z rzeczywistymi interesariuszami i nie gwarantuje dokładności. Model z radością napisze pewny siebie, dobrze sformatowany specyfikację funkcji, o którą nikt nie prosił.

Ten artykuł zakłada, że rozumiesz już sam proces określania zakresu. Jeśli chcesz poznać podstawy, nasz przewodnik krok po kroku po określaniu zakresu omawia podstawowy proces bez AI, 7 kroków oraz pełną strukturę dokumentu zakresu. Tutaj skupiamy się na warstwie AI: który prompt, w jakiej kolejności i gdzie proces się łamie.

Łańcuch promptów AI do określania zakresu w skrócie

Łańcuch to sześć promptów uruchamianych sekwencyjnie, gdzie każdy przekazuje swój wynik do następnego. W kolejności: (1) problem i cele, (2) user stories, (3) lista funkcji, (4) priorytetyzacja MoSCoW, (5) szacunek nakładu, kosztu i harmonogramu oraz (6) szkic SOW. Uruchamiaj je w ramach jednego projektu, aby zachować kontekst.

Oto najlepsza część: ponieważ każdy prompt buduje na poprzednim, nie tłumaczysz swojej aplikacji sześć razy. Model zna już problem, gdy pisze user stories, i zna już historie, gdy priorytetyzuje funkcje.

1. Problem i cele: przekształca zgrubny pomysł w opis problemu oraz cele SMART.
2. User stories: przekształca cele w user stories z kryteriami akceptacji.
3. Lista funkcji: wyprowadza konkretny wykaz funkcji ze stories.
4. Priorytetyzacja MoSCoW: sortuje funkcje na Must (musi być), Should (powinno być), Could (mogłoby być), Won't (nie będzie).
5. Szacunek: produkuje szacunek nakładu, przedział kosztowy i harmonogram.
6. Szkic SOW: składa wszystko w Statement of Work.

Jest to również czysty zestaw promptów ai do zarządzania projektami ogólnie, ale dostrojiliśmy każdy prompt specyficznie pod aplikacje webowe (stos technologiczny, integracje, przypadki brzegowe). To dostrojenie odróżnia użyteczny zakres od generycznego.

Trikiem nie jest jeden magiczny prompt. To sześć promptów, które przekazują sobie nawzajem wyniki.

Jak uruchomić łańcuch krok po kroku?

Uruchamiasz łańcuch od góry do dołu w jednym projekcie Claude Project lub ChatGPT Project, wklejając każdy prompt po kolei i pozwalając, aby poprzednia odpowiedź pozostała w kontekście. Poniżej znajdziesz sześć prostych kroków z dokładnymi promptami, których używamy. Każdy z nich jest celowo specyficzny dla aplikacji webowych, ponieważ generyczne prompty analityczne biznesowe generują generyczne zakresy.

Uwaga przed startem: zamień nawiasowe placeholdery na swoje dane i nigdy nie przyjmuj pierwszego wyniku jako ostatecznego. Profesjonalnym ruchem jest przeczytanie każdego wyniku, poprawienie go, a następnie uruchomienie następnego promptu.

Prompt 1: Opis problemu i cele

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.

To generuje sekcję przeglądu i celów. Wskazówka: linijka „3 założenia” wykonuje ciężką pracę. Wyświetla luki, które AI inaczej by zamazało.

Prompt 2: User stories

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.

Masz teraz wymagania funkcjonalne. To czysty krok generatora user stories ai. Pułapka: model tenduje do zapominania o rolach administratora i przypadkach brzegowych, więc ponownie poproś go: „dodaj teraz historie dla adminów, nieudanych płatności i stanów pustych”.

Prompt 3: Lista funkcji

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.

To jest Twoja kandydacka lista funkcji w zakresie. Uważnie obserwuj ten krok, ponieważ tutaj AI zaczyna wymyślać integracje (więcej na ten temat później).

Prompt 4: Priorytetyzacja 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."

To oznacza elementy w zakresie i poza zakresem. Instrukcja „bądź bezlitosny” ma znaczenie; bez niej model oznaczy prawie wszystko jako Must.

Prompt 5: Szacunek nakładu, kosztu i 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.

To jest wejście dla twojego generatora zakresu prac ai dotyczące budżetu i harmonogramu. Zawsze żądaj przedziału i założeń, ponieważ pojedyncza, pewna liczba to najniebezpieczniejszy wynik, jaki daje AI.

Prompt 6: Szkic 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].

Tagi [REVIEW] stają się Twoją listą kontrolną ludzkiej bramki. Ten krok składa całość, od pomysłu do SOW, obiecującą przez cały łańcuch.

Mapowanie Prompt → Sekcja Zakresu

Każdy prompt nie tylko odpowiada na pytanie, ale wypełnia konkretną sekcję dokumentu, który przekazujesz klientowi. To mapowanie zastępuje zwykły 11-sekcyjny szablon: zamiast memorować szkielet, uruchamiasz łańcuch, a dokument składa się sam. Oto, który prompt produkuje które deliverable.

Do czasu ukończenia Promptu 6 masz kompletny pierwszy szkic dokumentu, który klient może faktycznie przeczytać i podpisać, a nie stos luźnych notatek.

Każdy prompt nie tylko odpowiada na pytanie. Wypełnia konkretną sekcję dokumentu, który przekażesz klientowi.

Pełny przepracowany przykład: Określanie zakresu SaaS do rezerwacji wizyt

Oto łańcuch uruchomiony od początku do końca na jednym konkretnym przypadku: SaaS do rezerwacji wizyt dla małej sieci dentystycznej. Jest to przykład ilustracyjny, a nie rzeczywiste deliverable dla klienta, i tak, wyłapaliśmy dwa błędy w wyniku AI, które naprawiamy w sekcji ludzkiej weryfikacji poniżej.

Wynik Promptu 1 (problem i cele). Problem: trzyoddziałowa sieć dentystyczna traci rezerwacje przez „telefonową ping-ponga” i niepojawianie się pacjentów. Cele: zmniejszenie niepojawień o 30% dzięki przypomnieniom, umożliwienie pacjentom samoobsługowej rezerwacji online i danie personelowi recepcji jednego wspólnego kalendarza. Oznaczone założenia: jedna strefa czasowa, tylko język angielski, brak fakturowania ubezpieczeń.

Wynik Promptu 2 (przykładowe user stories).

• Jako pacjent, chcę umówić wizytę online, abym nie musiał dzwonić.
• Jako pacjent, chcę otrzymać przypomnienie SMS, abym nie zapomniał o wizycie.
• Jako personel recepcji, chcę widzieć wszystkie trzy lokalizacje w jednym kalendarzu, abym mógł zarządzać nakładkami.

Wynik Promptu 3 (lista funkcji, skrócona). Rezerwacja online, synchronizacja kalendarza, przypomnienia SMS i e-mail, konta pacjentów, administracja wielolokalizacyjna, podstawowe raportowanie i krok płatności (ten ostatni został wymyślony; nikt o to nie prosił).

Wynik Promptu 4 (siatka MoSCoW).

Wynik Promptu 5 (szacunek, skrócony). Zakładając Next.js, Supabase i Twilio z dwoma developerami: funkcje Must-have to około 45–60 dni roboczych developera, przedział kosztowy około 35–55 tys. USD i harmonogram 8–10 tygodni. Najbardziej ryzykowny szacunek oznaczony: logika kalendarza wielolokalizacyjnego.

Wynik Promptu 6 (fragment SOW). „W zakresie: rezerwacja online, wspólny kalendarz wielolokalizacyjny, przypomnienia SMS (Twilio), konta pacjentów. Poza zakresem: płatności, ubezpieczenia, natywna aplikacja mobilna. Harmonogram: 8–10 tygodni. Przedział budżetowy: 35–55 tys. USD. [REVIEW] Potwierdź z klientem wybór Twilio vs alternatywnego dostawcy SMS.”

Przejrzyj to, a zobaczysz, że realny, możliwy do podpisania zakres ukształtował się podczas jednej sesji. Jeśli planujesz później dodać inteligentne funkcje, nasz przewodnik po tym, jak dodać funkcje AI do swojej aplikacji, kontynuuje tam, gdzie ten kończy.

Jak oszacować koszt i harmonogram z AI?

Prosisz model o rozbicie szacunku według funkcji w dniach, przyjęcie konkretnego stosu technologicznego, wymienienie wszystkich założeń i zwrócenie przedziału, a nie jednej liczby. Następnie sanity-checkujesz ten przedział względem znanych rynkowych tierów, ponieważ AI prawie zawsze kotwiczy się zbyt optymistycznie na nakładzie pracy.

Traktuj szacunki AI jako punkt wyjścia, nigdy jako ofertę. Najbardziej przydatną instrukcją jest „oznacz trzy najbardziej ryzykowne szacunki”, co mówi Ci dokładnie, gdzie wydać własny osąd. Oto tiery, z którymi porównujemy każdy szacunek AI.

Te przedziały pokrywają się z opublikowanymi benchmarkami agencji i marketplace’ów; badania Clutch dotyczące kosztów developmentu aplikacji są rozsądnym publicznym punktem odniesienia. Jeśli Twój szacunek AI wypadnie znacznie poniżej odpowiedniego tieru, prawdopodobnie pominął przypadki brzegowe. To także moment, aby zadać większe pytanie: budować czy kupować. Zakres, który puchnie powyżej tieru złożonego, czasem przemawia za kupnem zamiast budowania.

Jakie narzędzie AI wybrać do każdego zadania?

Do pełnego łańcucha używaj Claude Projects lub ChatGPT Projects, ponieważ oba utrzymują kontekst między promptami, więc wynik przenosi się dalej bez konieczności ponownego wklejania. Używaj samodzielnego agenta dopiero po podpisaniu zakresu, gdy generujesz powtarzalne artefakty. Do jednorazowego określania zakresu Projects zawsze wygrywa z agentem.

Uruchamiamy łańcuch w Claude Projects dla kroków wymagających długiego kontekstu (user stories, składanie SOW) i sięgamy po ChatGPT, gdy chcemy drugiej opinii dotyczącej szacunku. Według dokumentacji Anthropic Projects, Projekt utrzymuje współdzielony kontekst i instrukcje w całej konwersacji, co jest dokładnie tym, czego potrzebuje przepływ pracy projekty claude do wymagań z sześcioma promptami. Projekty OpenAI działają w ten sam sposób dla promptów chatgpt do developmentu oprogramowania.

Technika warta skradzenia: podziel rolę AI na etapy. Powiedz mu „działaj jako product manager” dla user stories i „działaj jako senior engineer” dla szacunku. Zmiana roli zmienia sposób rozumowania, a persona inżyniera jest zauważalnie bardziej konserwatywna w kwestii nakładu pracy.

Gdy zakres zostanie wysłany, a budowa ruszy, pytanie o narzędzia przesuwa się w stronę agentów kodujących AI, co jest zupełnie inną decyzją.

Gdzie AI myli się w określaniu zakresu? Ludzka Bramka Walidacyjna

AI myli się w określaniu zakresu w przewidywalny sposób: halucynuje integracje, o które nikt nie prosił, niedoszacowuje przypadki brzegowe i stany błędów oraz albo wymyśla wymagania compliance, albo cicho pomija te rzeczywiste. Kotwiczy też szacunki kosztów zbyt optymistycznie. Żadne z tego nie jest rzadkie; dzieje się to praktycznie przy każdym uruchomieniu, dlatego ludzka bramka jest nie do negocjacji.

Złe wymagania są drogie, niezależnie od tego, czy pisze je człowiek, czy model. Badania PMI Pulse of the Profession wykazały, że niedokładne zbieranie wymagań jest główną przyczyną niepowodzenia projektów w około 37% przypadków, więc celem bramki jest wyłapanie tych braków przed wystawieniem oferty, a nie po.

Rozwiązaniem jest krótka lista kontrolna, którą człowiek uruchamia, zanim jakikolwiek zakres trafi do klienta:

• Usuń wymyślone funkcje: usuń wszystko (płatności, eksporty, integracje), o co klient nie prosił.
• Dodaj brakujące przypadki brzegowe: nieudane płatności, stany puste, uprawnienia, obsługa błędów.
• Zweryfikuj każdą integrację: potwierdź, że każda nazwana usługa zewnętrzna jest realna, potrzebna i uwzględniona w budżecie.
• Sprawdź twierdzenia compliance: potwierdź lub popraw każde wymaganie auth, prywatności lub regulacyjne, które AI zasugerowało.
• Zwiększ bufor szacunku: dostosuj optymistyczne liczby do własnej velocity, szczególnie tych oznaczonych jako ryzykowne.

AI z pewnością określi zakres przepływu płatności, który samo wymyśliło. Twoim zadaniem jest usunięcie części, o które nikt nie prosił.

Czego nauczyliśmy się, stosując to w rzeczywistych projektach klientów

W przypadku naszych ostatnich kilku projektów klientów, discovery, które kiedyś zajmowało około 12–16 godzin rozmów i opracowań, teraz kończy się pierwszym szkicem SOW w około 2–3 godziny pracy z AI plus 1 godzina ludzkiej weryfikacji. Są to uczciwe przedziały z naszych własnych uruchomień, a nie precyzyjna statystyka nagłówkowa, a ta godzina ludzka to element, którego nigdy nie pominiemy.

Uruchamiamy łańcuch w Claude Projects, z ChatGPT jako sanity-check dla szacunków. Oszczędność czasu jest realna, ale wartość polega na łapaniu tych samych trzech błędów za każdym razem:

1. Wymyśla integracje. Krok płatności w przykładzie dentystycznym, o który nikt nie prosił. Prawie każdy zakres miał co najmniej jedną fantomową funkcję.
2. Niedoszacowuje przypadki brzegowe. Stany błędów, stany puste i flow administracyjne są konsekwentnie pomijane lub niedoliczone, a to właśnie tam realne budżety wybuchają.
3. Źle radzi sobie z compliance i auth. Czasami halucynuje wymaganie, czasami pomija prawdziwe. Nigdy mu nie ufamy w tej kwestii.

Dlatego dodaliśmy powyższą ludzką bramkę jako stały krok. Łańcuch szybko pisze szkic; bramka sprawia, że jest on bezpieczny do wysłania. Pomiń bramkę, a wysyłasz jedynie pewny siebie, dobrze sformatowany zgadywanie.

Jak Techsy podchodzi do określania zakresu wspomaganego AI

Ten łańcuch plus ludzka bramka to dokładnie ten workflow, który prowadzimy dla klientów budujących aplikacje webowe. Szkicujemy szybko z AI, a następnie osoba, która dostarczyła rzeczywiste buildy, waliduje każdą linię, zanim stanie się ona ofertą. Jeśli wolisz przekazać zakres zespołowi, który robi to codziennie, właśnie tym się zajmujemy. Otrzymujesz obronny SOW bez płacenia wcześniej za dwa tygodnie rozmów discovery.

O autorze

Mert Batur Gurbuz jest Współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline’y voice/SDR dla klientów B2B. Studiuje na University of Birmingham i pisze o stosie narzędzi LLM, z którego zespół Techsy faktycznie korzysta w produkcji.

Współzałożyciel, Techsy.io — University of Birmingham. Połącz się na LinkedIn.

Często Zadawane Pytania

Czy AI może napisać zakres projektu lub SOW?

Tak, AI może stworzyć szkic pełnego zakresu projektu lub Statement of Work, w tym problem, user stories, funkcje, priorytety, harmonogram i przedział budżetowy. Uruchom łańcuch sześciu promptów wewnątrz projektu Claude lub ChatGPT. Szkic jest wiarygodny jako punkt wyjścia, ale człowiek musi go zwalidować przed akceptacją.

Jakie jest najlepsze narzędzie AI do określania zakresu projektu software'owego?

Claude Projects i ChatGPT Projects to najlepsze narzędzia do określania zakresu, ponieważ oba utrzymują kontekst w całym łańcuchu promptów, dzięki czemu każdy wynik zasila następny. Używamy Claude Projects do kroków wymagających długiego kontekstu, takich jak user stories i składanie SOW, a ChatGPT jako drugiej opinii przy szacunkach. Agenci lepiej sprawdzają się w pracach budowlanych po określeniu zakresu.

Jak używać ChatGPT lub Claude do zbierania wymagań?

Uruchom łańcuch promptów po kolei: poproś o opis problemu i cele, następnie user stories z kryteriami akceptacji, potem listę funkcji, a na końcu priorytetyzację MoSCoW. Trzymaj wszystko w jednym Projekcie, aby kontekst był przenoszony. Wynik każdego promptu staje się wejściem dla następnego, co sprawia, że zbieranie wymagań z AI jest szybkie.

Czy AI może oszacować koszt i harmonogram projektu software'owego?

Tak, ale tylko jako punkt wyjścia. Poproś model o rozbicie szacunku według funkcji w dniach, przyjęcie konkretnego stosu, wymienienie założeń i zwrócenie przedziału. Następnie sprawdź go sanity-checkiem względem tierów rynkowych: 10–50 tys. USD za proste MVP, do 150 tys. USD+ za złożone aplikacje. AI tenduje do zbyt optymistycznego kotwiczenia się.

Czy zakres generowany przez AI jest naprawdę wiarygodny?

Wiarygodny dla pierwszego szkicu, nie do akceptacji. AI szybko produkuje dobrze ustrukturyzowany zakres, ale wymyśla integracje, niedoszacowuje przypadki brzegowe i źle radzi sobie z compliance przy niemal każdym uruchomieniu. Traktuj wynik jako szybki szkic, a następnie uruchom ludzką bramkę walidacyjną, aby usunąć wymyślone funkcje i dodać brakujące przypadki brzegowe, zanim ktokolwiek podpisze.

Jak przekształcić zgrubny pomysł w specyfikację z AI?

Zacznij od Promptu 1: wklej swój pomysł w dwóch do czterech zdaniach i poproś AI o napisanie opisu problemu, celów SMART oraz założeń, jakie przyjmuje. Następnie uruchom kolejne pięć promptów sekwencyjnie. Do Promptu 6 masz szkic SOW. Cały łańcuch zajmuje kilka godzin zamiast dni.

Czy określanie zakresu wspomagane AI zastępuje fazę discovery?

Nie, kompresuje discovery, a nie je zastępuje. Nadal potrzebujesz rzeczywistych rozmów z interesariuszami, aby wiedzieć, czego klient naprawdę chce. AI zajmuje się szkicowaniem i strukturyzowaniem, przekształcając Twoje notatki w wymagania i SOW w ciągu godzin. Ludzie nadal walidują, priorytetyzują i podejmują ostateczne decyzje dotyczące zakresu.

Ile czasu zajmuje określenie zakresu aplikacji webowej z AI?

Według naszego doświadczenia, pierwszy szkic SOW zajmuje około 2–3 godziny pracy z AI plus około 1 godzina ludzkiej weryfikacji, w przeciwieństwie do 12–16 godzin ręcznego discovery i opracowań. Czas AI jest szybki; godzina weryfikacji jest nie do negocjacji, ponieważ to wtedy łapiesz funkcje wymyślone przez AI i przypadki brzegowe, które przeoczyło.