Як визначити обсяг веб-проєкту за 7 кроків (не перевищивши бюджет)
Нечітке технічне завдання — це те, як проєкт вартістю $40 тис. непомітно перетворюється на проєкт за $90 тис. Вирішенням є правильне визначення обсягу веб-проєкту, але більшість команд ігнорують три речі, які реально впливають на бюджет: жорстке обмеження функціоналу MVP, реалістичну оцінку вартості та письмовий процес затвердження змін. Зробіть це правильно, і ваша кошторисна пропозиція перестане бути просто здогадкою.
Це той самий 7-кроковий процес, який ми використовуємо в Techsy, із діапазонами вартості, готовим до копіювання шаблоном і реальними цифрами порівняння оцінок із фактичними витратами, яких ви не побачите на першій сторінці інших гайдів.
Ключові висновки
- Визначення обсягу = чітке визначення того, що саме буде розроблено (функції, результати, терміни, бюджет) і, що критично важливо, що не входитиме в проєкт.
- Використовуйте метод MoSCoW, щоб скоротити список функцій до необхідного мінімуму для MVP перед оцінкою вартості.
- Простий MVP коштує приблизно $20–70 тис. і займає 1–3 місяці; складні проєкти можуть сягати $200 тис.+ і тривати 8+ місяців.
- Письмовий процес затвердження змін — ваш найкращий захист від неконтрольованого розростання обсягу робіт (scope creep) та перевищення бюджету.
Що насправді означає «визначити обсяг веб-проєкту»?
Визначення обсягу веб-проєкту означає чітке формулювання того, що саме буде створено (функції, результати роботи, графік і бюджет), а також, що не менш важливо, того, що створюватися не буде. Чіткий обсяг робіт для розробки вебсайту перетворює туманну ідею на прорахований план і є вашим найкращим захистом від розростання обсягу, перевищення бюджету та зриву дедлайнів.
Обсяг проєкту: документально зафіксована домовленість про те, що саме проєкт має поставити, коли, за яку суму та де проходять його межі.
Люди часто плутають три документи, які виконують різні функції. Statement of Work (SOW) або опис цілей та меж — це короткий підсумок. Scope of Work (SOW) або технічне завдання — це детальний перелік результатів та обов’язків. Вимоги поділяються на функціональні (що робить додаток) та нефункціональні (яка швидкість, безпека та доступність потрібні). Зазвичай вам потрібні всі три, але саме statement of work визначає, чи всі учасники розуміють проєкт однаково.
Інститут управління проєктами (PMI) визначає управління обсягом як роботу з контролю того, що входить і не входить до проєкту (управління обсягом PMI). Друга частина важливіша за першу. Обсяг — це стільки ж про те, що ви не будуєте, скільки й про те, що будуєте. Ігноруйте виключення, і ви підпишетесь на рахунок без ліміту.
7-кроковий процес визначення обсягу оглядом
Ось весь процес по порядку. Кожен крок живить наступний, і пропуск будь-якого з них зазвичай призводить до проблем із бюджетом. Цей список також є чіткою картою того, що охоплює решта цього гайду, крок за кроком.
- Чітко сформулюйте проблему та користувачів. Запишіть реальну проблему та тих, хто її має, перш ніж називати хоч одну функцію.
- Визначте SMART-цілі. Перетворіть проблему на вимірні показники, які можна перевірити після запуску.
- Складіть список функцій і відсійте зайве за методом MoSCoW. Розподіліть усе на Must / Should / Could / Won't, потім визначте межі MVP.
- Оцініть зусилля, вартість і терміни. Оцініть список Must-have, застосуйте припущення щодо швидкості команди, додайте буфер на ризики.
- Напишіть документ з обсягом робіт. Зведіть усе в один документ, який підпишуть усі сторони.
- Зафіксуйте межі. Виключення, припущення та письмове затвердження перед початком написання коду.
- Запровадьте процес управління змінами. Фільтр для кожної нової ідеї, щоб розростання обсягу коштувало грошей свідомо, а не випадково.
Atlassian та більшість PM-фреймворків стискають це до п’яти кроків (гід Asana з управління обсягом є гарною універсальною версією). Ми виділили оцінку та контроль змін в окремі кроки, тому що саме тут веб-проєкти найчастіше виходять за рамки бюджету.
Як чітко сформулювати проблему та поставити SMART-цілі? (Кроки 1, 2)
Почніть із запису проблеми та користувача простою мовою, а потім перетворіть це на вимірні цілі. Крок 1 — це фаза дослідження (discovery): коротке платне розслідування перед тим, як хтось напише код. Крок 2 — це перетворення розмитих амбіцій («покращити чекаут») на цифри, які можна перевірити після запуску («зменшити відток з 70% до 50%»).
Проведіть легке дослідження (Discovery)
Фаза discovery у веб-розробці — це коротке дослідження, яке відбувається перед розробкою: інтерв’ю зі стейкхолдерами, начерк основних потоків і підтвердження того, що проблема реальна і варта вирішення. Для MVP це зазвичай кілька днів або два тижні, а не квартал. Ви не проектуєте весь додаток. Ви відповідаєте на одне запитання: чи достатньо добре ми розуміємо проблему, щоб виділити на неї бюджет?
Швидка перевірка інтуїції перед тим, як взагалі братися за оцінку кастомної розробки: чи варто це будувати, чи краще купити готове рішення? Це окреме питання, і ми розглядаємо його в статті рішення про власну розробку чи покупку. Визначення обсягу передбачає, що ви вже вирішили будувати власний продукт.
Пишіть цілі, які можна виміряти
SMART-цілі мають бути Specific (конкретними), Measurable (вимірними), Achievable (досяжними), Relevant (актуальними) та Time-bound (обмеженими в часі). Для e-commerce проєкту слабка ціль — «покращити чекаут». SMART-версія: «зменшити відтік користувачів на етапі чекауту з 70% до 50% протягом трьох місяців після запуску». Одна ця цифра каже дизайнеру, що оптимізувати, дає розробнику критерій прийняття роботи, а вам — спосіб зрозуміти, чи спрацювали вкладені кошти. Розмиті цілі породжують розмиті обсяги, а розмиті обсяги — це те, як бюджет «йде пішки».
Як перетворити цілі на функції та відсіяти зайве за методом MoSCoW? (Крок 3)
Складіть список усіх функцій, яких хоче кожен, а потім розподіліть їх на чотири категорії: Must-have (обов’язково), Should-have (бажано), Could-have (можливо) та Won't-have (не буде в цьому релізі). Це метод MoSCoW, і це найкорисніший інструмент для визначення обсягу MVP веб-додатка, оскільки він змушує приймати рішення, а не просто складати список бажань. Ваш MVP — це лише колонка Must-have і нічого більше.
Метод MoSCoW був розроблений Даєм Клеггом в Oracle у 1994 році та популяризований agile-фреймворком DSDM (походження методу MoSCoW). Колонка «Won't-have» — це те, що більшість команд пропускають, і вона є найважливішою. Явне називання того, що ви не будуєте в цьому релізі, — це половина вашого захисту від розростання обсягу, і вона безкоштовна.
Ось реальний приклад обсягу проєкту для e-commerce сайту з фактично відсортованим списком функцій:
| Пріоритет | Функції | Входить у MVP? |
|---|---|---|
| Must-have | Каталог товарів, кошик, чекаут через Stripe, авторизація користувачів, email підтвердження замовлення | Так |
| Should-have | Список бажань, відгуки про товари, промокоди | Наступний реліз |
| Could-have | Персоналізовані рекомендації, листи про покинутий кошик | Якщо дозволяє бюджет |
| Won't-have (в цьому релізі) | Мультивалютність, програма лояльності, маркетплейс для сторонніх продавців | Ні, навмисно |
Емпіричне правило: якщо ваш початковий список функцій після сортування за MoSCoW залишає все в колонці Must, ви недостатньо різко скоротили список. Прагніть викреслити приблизно половину. Якщо все є Must-have, то нічого не є пріоритетним, і ваш бюджет уже програно.
Як оцінити зусилля, вартість і терміни? (Крок 4)
Розбийте список Must-have на окремі функції, оцініть кожну, помножте на реальну швидкість вашої команди, а потім додайте буфер на ризики. Простий MVP коштує приблизно $20–70 тис. і займає 1–3 місяці; проєкт середньої складності з дашбордами та інтеграціями обійдеться приблизно в $80–180 тис. і займе 4–8 місяців; складні або регульовані проєкти досягають $200 тис.+ і 8+ місяців. Буфер не є опціональним. Це різниця між реальною пропозицією та мрією.
Метод оцінки простими словами
Припиніть оцінювати весь проєкт одним числом. Оцінюйте кожну функцію окремо. Привойте кожній функції розмір футболки (S/M/L) або story points, переведіть у приблизні дні, використовуючи історію вашої команди, а потім додайте діапазон буфера залежно від ризикованості роботи. Нова інтеграція зі стороннім сервісом? Великий буфер. Стандартна CRUD-форма? Маленький.
Ось математика простими словами:
base_estimate = sum(days per feature) # e.g. 60 days
risk_buffer = 20% for a clean build
35–50% if it has payments, auth/roles, or new integrations
quoted_range = base_estimate * (1 + low_buffer) to base_estimate * (1 + high_buffer)
# Example: 60 days, integration-heavy MVP
# 60 * 1.20 = 72 days (optimistic)
# 60 * 1.50 = 90 days (realistic)
# Quote the RANGE (72–90 days), never the single 60.Називання єдиної цифри — це спосіб занизити власну ставку. Назвіть діапазон і поясніть буфер, і клієнт довірятиме вам більше, а не менше.
Скільки насправді коштує веб-додаток у 2026 році
Вартість майже лінійно залежить від рівня складності обсягу робіт. Ці діапазони узгоджуються з індустріальними оцінками на 2026 рік (дані SaM Solutions про вартість веб-додатків):
| Рівень складності | Приклад | Діапазон вартості (2026) | Терміни |
|---|---|---|---|
| Простий MVP | Статичні сторінки, форми, базова авторизація, один платіжний потік | $20–70 тис. | 1–3 місяці |
| Середній | Дашборди, база даних, API сторонніх сервісів, ролі користувачів | $80–180 тис. | 4–8 місяців |
| Складний / AI / регульований | Реальний час, мікросервіси, AI-функції, комплаєнс | $200–500 тис.+ | 8–24 місяці |
"Web App Development Cost by Scope Tier (2026)"
Таблиця даних
| "Scope tier" | "Low estimate" | "High estimate" |
|---|---|---|
| "Simple MVP" | 20 | 70 |
| "Moderate" | 80 | 180 |
| "Complex / AI" | 200 | 500 |
Дві речі швидко переводять вас на вищий рівень: інтеграції зі сторонніми сервісами та вибір технологічного стеку. Ваша CMS — один із таких виборів, і неправильний вибір посеред проєкту призведе до дорогого перегляду обсягу, тому вирішуйте це рано. Ми детально розбираємо варіанти у статті вибір headless CMS. Якщо проєкт включає функції машинного навчання, це штовхає вас до складного рівня; ось наш гайд щодо додавання AI-функцій та їх впливу на оцінку.
Що має включати документ з обсягом робіт для веб-додатка? (Крок 5)
Повний документ з обсягом робіт для веб-додатка має одинадцять розділів: огляд проєкту, цілі та метрики, функції в обсязі, виключення поза обсягом, результати роботи, припущення, технологічний стек, графік та майлстоуни, діапазон бюджету, процес управління змінами та затвердження. Кожен розділ закриває конкретне питання до того, як воно виникне. Пропустіть, наприклад, «припущення», і кожне непорозуміння стане платним сюрпризом.
Ось шаблон обсягу проєкту для вебсайту, який ми використовуємо. Вставте його в Notion або Google Doc, і у вас буде реальне ТЗ за годину, а не за тиждень:
# PROJECT SCOPE: [Project name]
Version: 1.0 | Date: [date] | Owner: [name]
## 1. Overview & Problem
One paragraph: what we're building and the problem it solves.
## 2. Goals & Success Metrics
SMART goals with target numbers. (e.g. cut abandonment 70% → 50% in 3 months)
## 3. In-Scope Features (MoSCoW-tagged)
- [MUST] ...
- [SHOULD] ...
- [COULD] ...
## 4. Out of Scope (Won't-have, this release)
- Explicitly NOT building: ...
## 5. Deliverables
- Working app, source code, docs, handover, [hosting setup?]
## 6. Assumptions
- Client provides brand assets / copy / API keys by [date]
- Third-party services (Stripe, etc.) accounts exist
## 7. Tech Stack & Integrations
- Frontend / backend / DB / hosting / third-party APIs
## 8. Timeline & Milestones
- Discovery → Design → Build → QA → Launch (with dates)
## 9. Budget Range
- $X–$Y, with the buffer assumptions stated
## 10. Change-Request Process
- How new requests are logged, costed, approved, signed
## 11. Sign-Off
- Names, date, signatures (digital is fine)Розділи «Out of Scope» (Поза обсягом) та «Assumptions» (Припущення) виконують основну роботу. Це найдешевша страховка, яку ви коли-небудь писали: кілька рядків, які запобігають суперечкам на тисячі доларів у майбутньому.
Як запобігти розростанню обсягу за допомогою виключень та запитів на зміни? (Кроки 6, 7)
Зафіксуйте межі письмовим списком виключень, підписаним розділом припущень та процесом затвердження змін, який пропускає кожну нову ідею через оцінку впливу на вартість і час перед тим, як вона торкнеться розробки. Розростання обсягу (scope creep) — це неконтрольоване збільшення обсягу проєкту після його погодження (PMI про scope creep). Воно рідко приходить як один великий запит. Це сотня маленьких прохань «а чи можемо ми ще й...».
Крок 6: Зафіксуйте межі
Отримайте письмове затвердження перед початком розробки. Не усне «виглядає добре», а підпис під документом з обсягом робіт. Список виключень («Won't-have, в цьому релізі») та розділ припущень — це те, на що ви посилаєтеся, коли хтось просить додати мультивалютність на шостому тижні. Межі — це не бюрократія. Це те, що захищає обидві сторони.
Крок 7: Запровадьте працюючий процес управління змінами
Кожен новий запит потрапляє в беклог, а не прямо в поточний спринт. Потім проводиться оцінка впливу: скільки грошей, скільки днів, затверджено або відхилено до внесення будь-яких змін у код. Ось як виглядає один рядок на практиці:
| Запит на зміну | Зміна вартості | Зміна часу | Рішення |
|---|---|---|---|
| Додати підтримку мультивалютності | +$8,000 | +2 тижні | Затверджено, підписано [дата] |
Ця одна звичка перетворює розростання обсягу з тихої втрати бюджету на свідомий, оцінений вибір. Клієнт все ще може додати мультивалютність. Просто він робить це з відкритими очима. Для більших або проєктів корпоративного рівня цей фільтр стає формальною радою з контролю змін, але механіка ідентична: запишіть, оцініть, підпишіть.
Що ми дізналися, визначаючи обсяг реальних веб-додатків: оцінка проти факту
Серед веб-додатків, обсяг яких ми визначали в Techsy, проявляється чітка закономірність: початкові оцінки в годинах зазвичай виявляються заниженими на 20–35% у середньому, і ті самі три пункти обсягу щоразу спричиняють більшість перевищень. Інтеграції платежів, авторизація з ролями та «прості» адмін-панелі — звичайні підозрювані. Жоден із них не виглядає дорогим у списку функцій. Але всі вони такими є.
Це репрезентативна картина з типів проєктів, які ми оцінюємо, а не дані одного аудиторського проєкту, але напрямкові числа достатньо стабільні, щоб ми планували, враховуючи їх:
| Пункт обсягу | Типова первинна оцінка | Типова фактична витрата | Відхилення |
|---|---|---|---|
| Базові CRUD-функції | В ціль | В ціль | ~0% |
| Авторизація користувачів + права доступу | «Кілька днів» | Ближче до 1.5–2x | +50–100% |
| Інтеграція сторонніх платежів (Stripe) | «Це просто SDK» | Крайні випадки, вебхуки, повернення | +30–50% |
| «Проста» адмін-панель | Недооцінено | Фільтри, експорт, права доступу накопичуються | +40–70% |
| Інтеграції зі сторонніми API (загалом) | Оптимістична | Авторизація, ліміти запитів, обробка помилок | +30–50% |
Чому саме ці три? Авторизація та ролі здаються тривіальними, доки ви не розпишете кожну комбінацію прав доступу. Інтеграція платежів виглядає як виклик SDK, доки ви не почнете обробляти невдалі списання, вебхуки та повернення коштів. Адмін-панелі часто оцінюються як «просто таблиця», а в результаті стають маленьким другим додатком із фільтрами, експортом та власною моделлю прав доступу.
Урок, який змінив наш підхід до оцінки: ми додаємо фіксований буфер щонайменше 20% до будь-якої розробки та 35–50% до всього, що сильно залежить від інтеграцій, і надаємо пропозицію у вигляді діапазону, а не єдиного числа. Єдине число — це обіцянка, яку ви не можете виконати. Діапазон із заявленим буфером — це чесна оцінка, навколо якої ваш клієнт може реально планувати.
Як AI-агенти для написання коду змінюють оцінку обсягу в 2026 році?
AI-агенти для написання коду прискорюють будівництво, а не прийняття рішень, тому вони змінюють вашу оцінку менше, ніж підказує хайп. На деяких задачах агенти, такі як Cursor та Claude Code, скорочують фазу чистої розробки на 40–60%. Але дослідження, дизайн-рішення, QA та налагодження інтеграцій не скорочуються, а саме там проєкти зазвичай спізнюються.
Тому тут потрібно ретельно визначати обсяг. Якщо ви зріжете свою загальну оцінку вдвічі, тому що «тепер AI пише код», ви сильно занизите ставку, адже код ніколи не був найдорожчою частиною. Найдорожча частина — це зрозуміти, що будувати, та перевірити, що воно працює. Ми випустили проєкти, де агенти обробляли більшу частину шаблонного коду, а людський час все одно йшов майже повністю на ті самі три пункти перевищення, згадані вище. Якщо хочете повної картини, ось наша думка про AI-агентів для кодингу та те, що вони реально роблять із термінами. Коротка версія: агенти роблять чіткий обсяг більш цінним, а не менш, тому що вони виконують усе, на що ви їх спрямуєте, включно з неправильними речами, швидше.
Як Techsy підходить до визначення обсягу
Ми починаємо кожну співпрацю над веб-додатком із фіксованого спринту дослідження (discovery), який продукує саме ті артефакти, що описані в цьому гайді: заповнений каркас документа з обсягом робіт, список функцій за методом MoSCoW із чіткими межами MVP та прорахований діапазон вартості із зазначеним буфером. Кошторисна пропозиція на розробку виходить із цього, тому вона не є здогадкою жодної зі сторін.
Інші підходи також працюють. Багато команд успішно визначають обсяг за допомогою легкого брифа та довірчих стосунків. Але якщо ви витрачаєте реальні гроші з новим партнером, документований обсяг захищає вас більше, ніж їх. Це наш процес розробки веб-додатків в одному абзаці.
Потрібен свіжий погляд на ваш обсяг робіт? Отримайте безкоштовну консультацію.
Про автора
Мерт Батур Гюрбюз — співзасновник Techsy.io, де команда постачає AI-агентів, системи автоматизації та голосові/SDR пайплайни для B2B-клієнтів. Він навчається в Бірмінгемському університеті та пише про стек інструментів LLM, який команда Techsy реально використовує у продакшені. Підключайтеся на LinkedIn.
Поширені запитання
Що таке обсяг проєкту веб-додатка?
Обсяг проєкту веб-додатка — це документально зафіксований набір функцій, результатів, термінів і бюджету, які проєкт має створити, плюс явні виключення того, що він створювати не буде. Він визначає межі, з якими всі погоджуються перед початком розробки, що робить його головним інструментом контролю проти розростання обсягу та перевищення бюджету.
Як написати документ з обсягом робіт для веб-додатка?
Використовуйте одинадцять розділів: огляд проєкту, цілі та метрики, функції в обсязі (з позначками MoSCoW), виключення поза обсягом, результати роботи, припущення, технологічний стек, графік та майлстоуни, діапазон бюджету, процес управління змінами та затвердження. Вставте наведений вище шаблон у документ, заповніть кожен розділ реальними деталями та отримайте підпис перед написанням будь-якого коду.
Що має включати технічне завдання (SOW) для веб-додатка?
Технічне завдання для веб-додатка має включати результати роботи, обов’язки, майлстоуни, критерії прийняття та графік, а також виключення та припущення. Список виключень і розділ припущень мають найбільше значення, оскільки вони запобігають непорозумінням, які пізніше перетворюються на платні сюрпризи під час розробки.
Наскільки детальним має бути обсяг проєкту?
Достатньо детальним, щоб розробник міг його оцінити, а клієнт міг зрозуміти, що саме він купує, але не настільки детальним, щоб він ставав специфікацією для додатка, якого ще не існує. Для MVP це зазвичай кілька сторінок: чіткі цілі, список функцій за MoSCoW, прорахований діапазон вартості, виключення та процес змін.
Як оцінити проєкт веб-додатка?
Розбийте список функцій Must-have на окремі пункти, оцініть кожен за розмірами футболок (S/M/L) або story points, переведіть у дні, використовуючи реальну швидкість вашої команди, а потім додайте буфер на ризики: 20% для чистої роботи та 35–50% для всього, що пов’язано з платежами, авторизацією або новими інтеграціями. Подавайте результат як діапазон, а не як єдине число.
Як запобігти розростанню обсягу в веб-проєкті?
Запобігайте розростанню обсягу трьома речами: письмовим списком виключень «Won't-have», підписаним документом з обсягом робіт перед початком розробки та процесом управління змінами, який пропускає кожну нову ідею через оцінку впливу на вартість і час. Нові запити потрапляють у беклог і входять у розробку лише після того, як вони оцінені та затверджені письмово.
Що таке фаза discovery у веб-розробці?
Фаза discovery — це коротке, зазвичай платне дослідження, яке відбувається перед розробкою: інтерв’ю зі стейкхолдерами, начерк основних потоків і підтвердження того, що проблему варто вирішувати. Для MVP це займає від кількох днів до двох тижнів. Її завдання — відповісти на запитання, чи достатньо добре ви розумієте проблему, щоб виділити на неї бюджет.
Скільки часу займає визначення обсягу веб-додатка?
Визначення обсягу простого MVP зазвичай займає 1–3 тижні, включаючи коротку фазу discovery. Проєкти середньої складності з інтеграціями та ролями займають більше часу, часто 3–6 тижнів, оскільки більше функцій потребує оцінки, а більше припущень — підтвердження. Поспіх у визначенні обсягу заради економії тижня регулярно коштує місяців переробок та запитів на зміни в майбутньому.
Скільки коштує розробка веб-додатка в 2026 році?
Простий MVP коштує приблизно $20–70 тис., проєкт середньої складності з дашбордами та інтеграціями — близько $80–180 тис., а складний, насичений AI або регульований проєкт — $200–500 тис. і більше. Вартість тісно пов’язана з рівнем складності, а інтеграції зі сторонніми сервісами та вибір технологічного стеку — це два фактори, які найшвидше переводять вас на вищий рівень.
Чи роблять AI-агенти для кодингу визначення обсягу менш важливим?
Ні, більш важливим. AI-агенти, такі як Claude Code та Cursor, прискорюють написання коду на 40–60% у деяких задачах, але вони не прискорюють прийняття рішень про те, що будувати, або перевірку того, чи це працює. Чіткий обсяг важливіший з агентами, а не менше, тому що вони виконують усе, на що ви їх спрямуєте, включно з неправильними речами, набагато швидше.
Підсумок
Визначення обсягу веб-проєкту зводиться до семи кроків: чітко сформулюйте проблему, поставте вимірні цілі, відсійте функції за методом MoSCoW, оцініть з буфером і надайте діапазон вартості, напишіть документ з обсягом робіт, зафіксуйте межі виключеннями та підписом і запровадьте реальний процес управління змінами. Єдина ідея, що лежить в основі всього цього: обсяг — це стільки ж про те, що ви не будуєте, скільки й про те, що будуєте.
Зробіть правильний відбір для MVP і налаштуйте фільтр змін, і бюджет перестане вас дивувати. У цьому вся суть гри.