Як оцінити обсяг веб-проєкту за допомогою ШІ: ланцюжок із 6 промптів, який ми використовуємо (від ідеї до SOW)
У наших останніх п’яти проєктах етап, який раніше займав 12–16 годин дослідницьких дзвінків, скоротився приблизно до 3 годин роботи зі штучним інтелектом плюс 1 година людської перевірки. Ми запускаємо весь процес всередині одного проєкту Claude, щоб контекст зберігався між кроками. Але є нюанс: ШІ щоразу помилявся у трьох речах. Тому ми додали обов’язковий етап перевірки людиною перед тим, як будь-що надіслати клієнту.
Це реальний ланцюжок із 6 промптів, який ми використовуємо, артефакт, який створює кожен промпт, один повний робочий приклад, а також режими збою, які вам доведеться виявляти самостійно.
Чи може ШІ оцінити обсяг веб-проєкту? Так. ШІ може підготувати повний опис обсягу робіт (формулювання проблеми, користувацькі історії, функції, пріоритети за MoSCoW та технічне завдання) за кілька годин замість днів. Чого він не може зробити — це валідувати цей чернетку. Він вигадує вимоги та недооцінює зусилля, тому людський контроль перед затвердженням є обов’язковим.
Ключові висновки
- ШІ готує повний обсяг робіт для веб-додатка за години, а не дні, але не може перевірити власний результат.
- Ланцюжок складається з шести промптів: проблема, користувацькі історії, функції, MoSCoW, оцінка, SOW.
- ШІ вигадує інтеграції та недооцінює крайні випадки, тому завжди проводьте людську перевірку.
- Використовуйте Claude Projects або ChatGPT Projects для цього ланцюжка; агенти потрібні вже після підписання обсягу робіт.
ШІ може написати першу чернетку вашого обсягу робіт за один день. Просто він не скаже вам, коли помиляється.
Що таке оцінка обсягу за допомогою ШІ (і чим вона НЕ є)?
Оцінка обсягу за допомогою ШІ означає використання серії промптів для великих мовних моделей (LLM), щоб перетворити сиру ідею на структуровані артефакти: вимоги, користувацькі історії, список функцій, пріоритети та технічне завдання (SOW). ШІ виконує чернетку та структурування. Людина все ще приймає рішення, спілкується зі стейкхолдерами та проводить валідацію.
То чи думає ШІ за вас? Не зовсім. Він швидко справляється із збором вимог за допомогою ШІ — тією частиною, де ви дивитеся на порожню сторінку й намагаєтеся перекласти «хочу додаток для бронювання» на мову, зрозумілу розробнику для оцінки. Але він погано розрізняє те, що клієнту дійсно потрібно, і те, що просто звучить правдоподібно.
Кілька речей, якими оцінка обсягу за допомогою ШІ не є: це не автономний процес, це не заміна спілкуванню з реальними стейкхолдерами, і це не гарантія точності. Модель із задоволенням напише впевнену, добре оформлену специфікацію для функції, яку ніхто не замовляв.
Ця стаття передбачає, що ви вже розумієте сам процес оцінки обсягу. Якщо вам потрібні основи, наш покроковий посібник з оцінки обсягу розповідає про базовий процес без ШІ, 7 кроків та повну структуру документа обсягу робіт. Тут же ми зосереджуємось на шарі ШІ: який промпт, у якому порядку та де виникають проблеми.
Ланцюжок промптів для оцінки обсягу за допомогою ШІ оглядом
Ланцюжок складається з шести промптів, які виконуються послідовно, причому кожен передає свій результат наступному. По порядку: (1) проблема та цілі, (2) користувацькі історії, (3) список функцій, (4) пріоритизація за MoSCoW, (5) оцінка зусиль, вартості та термінів, і (6) чернетка SOW. Запускайте їх всередині одного проєкту, щоб зберігався контекст.
Ось найцікавіше: оскільки кожен промпт базується на попередньому, вам не потрібно шість разів пояснювати свій додаток. Модель уже знає проблему, коли пише користувацькі історії, і вже знає історії, коли пріоритизує функції.
- Проблема та цілі: перетворює сиру ідею на формулювання проблеми та SMART-цілі.
- Користувацькі історії: перетворює цілі на користувацькі історії з критеріями прийняття.
- Список функцій: виводить конкретний перелік функцій із історій.
- Пріоритизація MoSCoW: сортує функції на Must (обов’язково), Should (бажано), Could (можливо), Won't (не потрібно).
- Оцінка: надає оцінку зусиль, діапазон вартості та терміни.
- Чернетка SOW: збирає все разом у технічне завдання.
Це також чистий набір промптів ШІ для управління проєктами загалом, але ми налаштували кожен промпт спеціально для веб-додатків (технологічний стек, інтеграції, крайні випадки). Саме це налаштування відрізняє придатний обсяг робіт від загального.
Секрет не в одному магічному промпті. Це шість промптів, які передають свої результати один одному.
Як запустити ланцюжок крок за кроком?
Ви запускаєте ланцюжок зверху вниз всередині одного проєкту Claude або ChatGPT Project, вставляючи кожен промпт по черзі та дозволяючи попередній відповіді залишатися в контексті. Нижче наведено шість простих кроків із точними промптами, які ми використовуємо. Кожен із них спеціально адаптований для веб-додатків, оскільки загальні промпти бізнес-аналізу дають загальні результати.
Примітка перед початком: замініть текст у квадратних дужках своїми деталями та ніколи не приймайте перший результат як фінальний. Професійний підхід — прочитати кожен результат, виправити його, а потім запустити наступний промпт.
Промпт 1: Формулювання проблеми та цілі
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.Це створює розділ огляду та цілей. Порада: рядок «3 припущення» виконує важливу роботу. Він виявляє прогалини, які ШІ інакше б ігнорував.
Промпт 2: Користувацькі історії
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.Тепер у вас є функціональні вимоги. Це чистий крок генератора користувацьких історій за допомогою ШІ. Підводний камінь: він часто забуває про адміністраторів та крайні випадки, тому повторно запитайте його: «тепер додай історії для адміністраторів, невдалих платежів та порожніх станів».
Промпт 3: Список функцій
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.Це ваш список кандидатів на функції, що входять в обсяг. Уважно стежте за цим кроком, тому що саме тут ШІ починає вигадувати інтеграції (про це нижче).
Промпт 4: Пріоритизація 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."Це маркує елементи, що входять і не входять в обсяг. Інструкція «будь безжальним» має значення; без неї модель позначає майже все як Must (обов’язкове).
Промпт 5: Оцінка зусиль, вартості та термінів
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.Це вхідні дані для вашого генератора SOW за допомогою ШІ щодо бюджету та термінів. Завжди вимагайте діапазон і припущення, тому що одне впевнене число — це найнебезпечніший результат, який дає ШІ.
Промпт 6: Чернетка 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].Теги [REVIEW] стають вашим чек-листом для людської перевірки. Цей крок збирає весь шлях від ідеї до SOW, який обіцяв увесь ланцюжок.
Відповідність промптів розділам обсягу робіт
Кожен промпт не просто відповідає на запитання, він заповнює конкретний розділ документа, який ви передаєте клієнту. Ця відповідність замінює звичайний шаблон із 11 розділів: замість того, щоб запам’ятовувати скелет, ви запускаєте ланцюжок, і документ збирається сам. Ось який промпт створює якийdeliverable.
| Промпт | Створює | Розділ документа обсягу, який заповнює |
|---|---|---|
| 1. Проблема та цілі | Формулювання проблеми + SMART-цілі | Огляд, Цілі та показники успіху |
| 2. Користувацькі історії | Користувацькі історії + критерії прийняття | Функціональні вимоги |
| 3. Список функцій | Перелік функцій | Функції в обсязі робіт |
| 4. MoSCoW | Пріоритизовані Must/Should/Could/Won't | В обсязі (з мітками) + Поза обсягом |
| 5. Оцінка | Зусилля, діапазон вартості, терміни | Терміни, Діапазон бюджету |
| 6. Чернетка SOW | Зібране технічне завдання | Повний SOW + deliverables + затвердження |
До часу завершення Промпта 6 у вас є повна перша чернетка документа, який клієнт може реально прочитати та підписати, а не купка незв’язних нотаток.
Кожен промпт не просто відповідає на запитання. Він заповнює конкретний розділ документа, який ви передасте клієнту.
Повний робочий приклад: оцінка SaaS для запису на прийом
Ось ланцюжок, запущений від початку до кінця на одному конкретному випадку: SaaS для запису на прийом для невеликої мережі стоматологічних клінік. Це ілюстративний приклад, а не реальний deliverable клієнта, і так, ми виявили дві помилки у виводі ШІ, які виправляємо в розділі людської перевірки нижче.
Вивід Промпта 1 (проблема та цілі). Проблема: мережа стоматологічних клінік із трьома локаціями втрачає записи через телефонні дзвінки та неявки. Цілі: зменшити кількість неявок на 30% за допомогою нагадувань, дозволити пацієнтам записуватися онлайн самостійно та надати співробітникам рецепції один спільний календар. Виявлені припущення: один часовий пояс, тільки англійська мова, без білінгу страхування.
Вивід Промпта 2 (зразок користувацьких історій).
- Як пацієнт, я хочу записатися на прийом онлайн, щоб не довелося дзвонити.
- Як пацієнт, я хочу SMS-нагадування, щоб не забути про свій прийом.
- Як співробітник рецепції, я хочу бачити всі три локації в одному календарі, щоб керувати накладками.
Вивід Промпта 3 (список функцій, скорочено). Онлайн-запис, синхронізація календаря, SMS та email-нагадування, акаунти пацієнтів, адміністрування кількох локацій, базова звітність та крок оплати (останній був вигаданий; ніхто про це не просив).
Вивід Промпта 4 (сітка MoSCoW).
| Пріоритет | Функції |
|---|---|
| Must (Обов’язково) | Онлайн-запис, календар для кількох локацій, SMS-нагадування, акаунти пацієнтів |
| Should (Бажано) | Email-нагадування, базова звітність |
| Could (Можливо) | Самостійне перенесення запису пацієнтом |
| Won't (Не потрібно v1) | Оплати, білінг страхування, нативний мобільний додаток |
Вивід Промпта 5 (оцінка, скорочено). Припускаючи Next.js, Supabase та Twilio з двома розробниками: функції Must займають приблизно 45–60 людино-днів, діапазон вартості близько $35K–$55K, термін 8–10 тижнів. Найризикованіша оцінка виділена: логіка календаря для кількох локацій.
Вивід Промпта 6 (уривок SOW). «В обсязі: онлайн-запис, спільний календар для кількох локацій, SMS-нагадування (Twilio), акаунти пацієнтів. Поза обсягом: оплати, страхування, нативний мобільний додаток. Термін: 8–10 тижнів. Діапазон бюджету: $35K–$55K. [REVIEW] Підтвердити з клієнтом вибір між Twilio та альтернативним постачальником SMS.»
Прогляньте це, і ви побачите, як реальний, придатний для підписання обсяг робіт сформувався за один присід. Якщо ви плануєте пізніше додати розумні функції, наш посібник про те, як додати функції ШІ до вашого додатка, продовжує там, де цей залишився.
Як оцінити вартість та терміни за допомогою ШІ?
Ви просите модель розбити оцінку за функціями в днях, припустити конкретний технологічний стек, вказати кожне припущення та повернути діапазон, а не одне число. Потім ви перевіряєте цей діапазон на відповідність відомим ринковим рівням, тому що ШІ майже завжди занадто оптимістично оцінює зусилля.
Ставтеся до оцінок ШІ як до відправної точки, а не як до офіційної пропозиції. Найкорисніша інструкція — «виділи три найризикованіші оцінки», що точно вказує, де витратити власне судження. Ось рівні, з якими ми порівнюємо кожну оцінку ШІ.
| Складність веб-додатка | Типовий діапазон вартості | Типові терміни |
|---|---|---|
| Простий MVP | $10K–$50K | 1–3 місяці |
| Середній (авторизація, оплати, дашборд) | $50K–$100K | 3–6 місяців |
| Складний (багато ролей, інтеграції, масштабування) | $75K–$150K+ | 6–12 місяців |
Ці діапазони узгоджуються з опублікованими бенчмарками агентств та маркетплейсів; дослідження вартості розробки додатків від Clutch є розумною publicly доступною точкою відліку. Якщо ваша оцінка ШІ значно нижча за відповідний рівень, вона, ймовірно, пропустила крайні випадки. Це також момент, щоб поставити більше запитання: робити самому чи купувати готове. Обсяг робіт, який виходить за межі складного рівня, іноді свідчить на користь покупки, а не розробки.
Який інструмент ШІ використовувати для кожної задачі?
Для всього ланцюжка використовуйте Claude Projects або ChatGPT Projects, оскільки обидва зберігають контекст між промптами, тому результат передається далі без необхідності копіювати заново. Використовуйте автономного агента лише після підписання обсягу робіт, коли ви генеруєте повторювані артефакти. Для одноразової оцінки обсягу Projects завжди краще за агента.
Ми запускаємо ланцюжок у Claude Projects для кроків із довгим контекстом (користувацькі історії, збірка SOW) і звертаємося до ChatGPT, коли хочемо отримати другу думку щодо оцінки. Згідно з документацією Anthropic щодо Projects, Project зберігає спільний контекст та інструкції протягом розмови, що є саме тим, що потрібно для робочого процесу claude projects для вимог із шести промптів. OpenAI Projects працюють так само для промптів chatgpt для розробки програмного забезпечення.
Одна техніка, яку варто запозичити: розділяйте роль ШІ на кожному кроці. Скажіть йому «дій як продукт-менеджер» для користувацьких історій та «дій як старший інженер» для оцінки. Зміна ролі змінює хід міркувань, і persona інженера помітно консервативніша щодо зусиль.
Коли обсяг робіт затверджено і починається розробка, питання інструментів зміщується до агентів кодування на основі ШІ, що є зовсім іншим рішенням.
Де ШІ помиляється в оцінці обсягу? Людський етап валідації
ШІ помиляється в оцінці обсягу передбачуваним чином: він галюцинує інтеграції, які ніхто не замовляв, недооцінює крайні випадки та стани помилок, а також або вигадує вимоги щодо відповідності нормам, або тихо пропускає реальні. Він також занадто оптимістично оцінює вартість. Нічого з цього не є рідкістю; це трапляється практично в кожному запуску, саме тому людська перевірка є обов’язковою.
Погані вимоги коштують дорого, незалежно від того, хто їх пише — людина чи модель. Дослідження PMI Pulse of the Profession виявило, що неточний збір вимог є основною причиною провалу проєктів у приблизно 37% невдалих проєктів, тому мета перевірки — виявити ці пропуски до того, як вони потраплять у кошторис, а не після.
Рішенням є короткий чек-лист, який людина проходить перед тим, як будь-який обсяг робіт надіслати клієнту:
- Видаліть вигадані функції: приберіть усе (оплати, експорт, інтеграції), про що клієнт ніколи не просив.
- Додайте відсутні крайні випадки: невдалі платежі, порожні стани, дозволи, обробка помилок.
- Перевірте кожну інтеграцію: підтвердіть, що кожен названий сторонній сервіс існує, потрібен і закладений у бюджет.
- Перевірте твердження про відповідність нормам: підтвердіть або виправте будь-які вимоги до авторизації, конфіденційності або регуляторних норм, які стверджував ШІ.
- Збільште оцінку: скоригуйте оптимістичні числа відповідно до вашої власної швидкості, особливо виділені ризиковані.
ШІ впевнено оцінить потік оплат, який він сам вигадав. Ваше завдання — видалити частини, про які ніхто не просив.
Що ми дізналися, запускаючи це на реальних проєктах клієнтів
У наших останніх кількох проєктах клієнтів дослідження, яке раніше займало приблизно 12–16 годин дзвінків та написання документів, тепер дає першу чернетку SOW приблизно за 2–3 години роботи зі ШІ плюс 1 година людської перевірки. Це чесні діапазони з наших власних запусків, а не точна заголовкова статистика, і годину людини ми ніколи не скорочуватимемо.
Ми запускаємо ланцюжок у Claude Projects, використовуючи ChatGPT для перевірки оцінок. Заощаджений час реальний, але цінність полягає в тому, щоб щоразу ловити ті самі три помилки:
- Він вигадує інтеграції. Крок оплати в прикладі зі стоматологією, про який ніхто не просив. Майже в кожному обсязі була принаймні одна фантомна функція.
- Він недооцінює крайні випадки. Стани помилок, порожні стани та потоки адміністратора постійно відсутні або недооцінені, саме там реальні бюджети руйнуються.
- Він неправильно обробляє відповідність нормам та авторизацію. Іноді він галюцинує вимогу, іноді пропускає реальну. Ми ніколи не довіряємо йому в цьому.
Тому ми додали вищезгадану людську перевірку як фіксований крок. Ланцюжок швидко пише чернетку; перевірка робить її безпечною для відправки. Пропустіть перевірку, і ви просто надсилаєте впевнений, добре оформлений здогад.
Як Techsy підходить до оцінки обсягу за допомогою ШІ
Цей ланцюжок плюс людська перевірка — це точний робочий процес, який ми запускаємо для клієнтів, що будують веб-додатки. Ми швидко готуємо чернетку за допомогою ШІ, а потім людина, яка має досвід запуску реальних проєктів, перевіряє кожен рядок перед тим, як він стане офіційною пропозицією. Якщо ви хочете передати оцінку обсягу команді, яка робить це щодня, саме цим ми й займаємось. Ви отримуєте обґрунтований SOW, не сплачуючи спочатку за два тижні дослідницьких дзвінків.
Про автора
Мерт Батур Гюрбюз є співзасновником Techsy.io, де команда поставляє агентів ШІ, системи автоматизації та голосові/SDR пайплайни для B2B-клієнтів. Він навчається в Бірмінгемському університеті та пише про стек інструментів LLM, який команда Techsy реально використовує у виробництві.
Співзасновник, Techsy.io — Бірмінгемський університет. Підключайтеся на LinkedIn.
Часті запитання
Чи може ШІ написати обсяг проєкту або SOW?
Так, ШІ може підготувати повний обсяг проєкту або технічне завдання, включаючи проблему, користувацькі історії, функції, пріоритети, терміни та діапазон бюджету. Запустіть ланцюжок із шести промптів всередині проєкту Claude або ChatGPT. Чернетка надійна як відправна точка, але людина повинна валідувати її перед затвердженням.
Який найкращий інструмент ШІ для оцінки обсягу програмного проєкту?
Claude Projects та ChatGPT Projects є найкращими інструментами для оцінки обсягу, оскільки обидва зберігають контекст протягом ланцюжка промптів, тому кожен результат живить наступний. Ми використовуємо Claude Projects для кроків із довгим контекстом, таких як користувацькі історії та збірка SOW, і ChatGPT як другу думку щодо оцінок. Агенти краще підходять для роботи після визначення обсягу.
Як використовувати ChatGPT або Claude для збору вимог?
Запустіть ланцюжок промптів по порядку: попросіть сформулювати проблему та цілі, потім користувацькі історії з критеріями прийняття, потім список функцій, потім пріоритети MoSCoW. Тримайте все в одному Project, щоб контекст зберігався. Результат кожного промпту стає вхідними даними для наступного, що робить збір вимог за допомогою ШІ швидким.
Чи може ШІ оцінити вартість та терміни програмного проєкту?
Так, але лише як відправну точку. Попросіть модель розбити оцінку за функціями в днях, припустити конкретний стек, вказати свої припущення та повернути діапазон. Потім перевірте його на відповідність ринковим рівням: $10K–$50K для простого MVP, до $150K+ для складних додатків. ШІ схильний занадто оптимістично оцінювати.
Чи є обсяг робіт, згенерований ШІ, дійсно надійним?
Надійний для першої чернетки, але не для затвердження. ШІ швидко створює добре структурований обсяг робіт, але він вигадує інтеграції, недооцінює крайні випадки та неправильно обробляє відповідність нормам майже в кожному запуску. Ставтеся до результату як до швидкої чернетки, а потім проведіть людську перевірку, щоб видалити вигадані функції та додати відсутні крайні випадки перед тим, як хтось підпише документ.
Як перетворити сиру ідею на специфікацію за допомогою ШІ?
Почніть з Промпта 1: вставте свою ідею у два-чотири речення та попросіть ШІ написати формулювання проблеми, SMART-цілі та припущення, які він робить. Потім запустіть наступні п’ять промптів по черзі. До Промпта 6 у вас буде чернетка SOW. Весь ланцюжок займає кілька годин замість днів.
Чи замінює оцінка обсягу за допомогою ШІ етап дослідження?
Ні, він стискає дослідження, а не замінює його. Вам все ще потрібні реальні розмови зі стейкхолдерами, щоб знати, чого дійсно хоче клієнт. ШІ обробляє чернетку та структурування, перетворюючи ваші нотатки на вимоги та SOW за години. Люди все ще валідують, пріоритизують та приймають остаточні рішення щодо обсягу.
Скільки часу займає оцінка веб-додатка за допомогою ШІ?
За нашим досвідом, перша чернетка SOW займає приблизно 2–3 години роботи зі ШІ плюс близько 1 години людської перевірки, проти 12–16 годин ручного дослідження та написання документів. Час ШІ швидкий; година перевірки є обов’язковою, тому що саме там ви виявляєте функції, які ШІ вигадав, та крайні випадки, які він пропустив.