Як порівняти три кошториси на сайт: однакове ТЗ, різні пропозиції

Як порівняти кошториси на сайт за обсягом, а не лише за сумою

Питання як порівняти кошториси на сайт варто починати не з найнижчої цифри, а з перевірки: чи продають вам три виконавці один і той самий результат. Однакове ТЗ у вкладенні ще не робить пропозиції однаковими. Один підрядник може включити адаптивні макети, тестування та передачу вихідних файлів, другий — винести це в додаткові роботи, а третій не згадати зовсім.

Мета порівняння — привести всі пропозиції до спільної одиниці: однакових сторінок, функцій, інтеграцій, критеріїв приймання та прав на результат. Лише після цього є сенс оцінювати бюджет, строки, ризики й підхід команди. Такий спосіб працює і для корпоративного сайту, і для інтернет-магазину, і для мобільного застосунку: змінюється набір робіт, але не логіка перевірки.

Низька початкова сума не обов’язково означає вигіднішу пропозицію. Часто вона означає, що частину рішень, контенту або перевірок ще не внесли до обсягу.

Спершу зафіксуйте базову одиницю порівняння

Не порівнюйте назви етапів на кшталт «дизайн», «розробка» або «запуск». За ними може стояти зовсім різний склад робіт. Замість цього створіть короткий перелік того, що має бути передано й прийнято: типи сторінок, ролі користувачів, сценарії форм, інтеграції, вимоги до контенту, адаптивні версії, документація та доступи.

Замість суми — карта обсягу

Для кожної позиції зафіксуйте не лише статус «є» або «немає», а й межу. Наприклад, «інтеграція з CRM» може означати передачу однієї форми через готовий конектор або розробку кількох сценаріїв з полями, перевіркою помилок, дублями та тестовими даними. Формально в обох пропозиціях інтеграція присутня, фактично — це різний обсяг.

Так само перевіряйте дизайн. Слово «дизайн» не відповідає на запитання, скільки буде унікальних шаблонів, чи передбачені стани форм і помилок, мобільні версії, компонентна бібліотека, кількість ітерацій правок та передача редагованих файлів.

Додайте критерії приймання

Кожна важлива позиція має завершуватися перевірним результатом. Не «налаштувати форму», а «форма надсилає визначені поля, показує повідомлення про помилку й передає тестову заявку до погодженої системи». Не «протестувати сайт», а «перевірити погоджені сценарії у визначених браузерах і на мобільних пристроях». Це зменшує простір для різного трактування після старту робіт.

Навчальний приклад: три пропозиції для одного ТЗ

Нижче — умовний навчальний приклад, а не ринкова оцінка й не рекомендація щодо бюджету. Усі три виконавці отримали однаковий стислий бриф: корпоративний сайт із головною сторінкою, кількома типовими внутрішніми сторінками, формою заявки, базовою CMS, адаптивною версткою та передачею матеріалів після запуску. У брифі не деталізовано, хто готує тексти, як саме тестується CRM-інтеграція та які саме файли дизайну переходять замовнику.

Пропозиція А: детально описаний основний продукт

Виконавець А включив UX/UI-дизайн, адаптивну розробку, базове функціональне тестування та передачу редагованих макетів. Наповнення сторінок матеріалами замовника і CRM-інтеграцію винесено окремими рядками. Це не є недоліком: межі робіт названо прямо, тому їх легко додати до порівнюваного обсягу або залишити за внутрішньою командою.

Пропозиція Б: ширший пакет із припущеннями

Виконавець Б заявляє дизайн, адаптиви й наповнення, але під наповненням розуміє розміщення готових текстів і зображень, а не створення матеріалів. Тестування позначено як окрема послуга, а права на вихідні файли не описано. Така пропозиція може бути доречною, якщо замовник підтвердить свої матеріали та окремо погодить формат перевірки.

Пропозиція В: функції включені, але частина меж не визначена

Виконавець В включає CRM-інтеграцію, проте не фіксує обсяг контенту, адаптивні версії й тестування. Дизайн та передача файлів зазначені як додаткові роботи. Тут ключове питання не в тому, чи є інтеграція в переліку, а скільки сценаріїв вона охоплює і хто підтверджує їхню коректність.

Жоден із цих форматів сам по собі не є «правильним» або «неправильним». Але без нормалізації А, Б і В не можна чесно зіставляти за загальною сумою.

Заповнена матриця порівняння пропозицій

Перенесіть у таку матрицю кожну суттєву позицію з вашого ТЗ. Статус «не зазначено» не слід читати як «включено» або «не потрібно»: це питання до уточнення. У прикладі нижче показано, як відрізняється склад робіт у пропозиції навіть за однакового стартового брифу.

Після заповнення матриці є два коректні сценарії. Перший — попросити кожного виконавця оновити пропозицію за єдиним переліком позицій. Другий — залишити різні комплектації, але свідомо оцінювати їх як різні продукти. Помилково порівнювати пропозицію А без CRM із пропозицією В із CRM так, ніби це однакові пакети.

Як нормалізувати різні пропозиції

Нормалізація не вимагає перетворити всіх підрядників на однакових. Вона потрібна, щоб рішення було прозорим. Спочатку сформуйте власний мінімальний обсяг: без яких результатів сайт не можна передати в роботу, запустити та підтримувати. Далі для кожної пропозиції позначте три групи.

• Включено: результат описаний достатньо чітко, щоб його перевірити й прийняти.
• Окремо: робота не входить до базової суми, але має зрозумілі межі, умови й спосіб оцінки.
• Не зазначено: відсутній опис, незрозуміла відповідальність або результат не можна перевірити.

Статус «окремо» часто безпечніший за «не зазначено». Він дає змогу заздалегідь погодити потрібний модуль, перенести його на наступний етап або доручити іншому виконавцю. Натомість мовчання про позицію створює ризик спору: замовник вважає її очевидною, а команда — поза межами домовленостей.

Надішліть усім трьом виконавцям одну й ту саму коротку форму уточнень. Не просіть просто «перерахувати дешевше». Попросіть підтвердити, що саме включено, що оцінюється додатково, які припущення закладено та який артефакт ви отримаєте на кожному етапі.

Питання, які знаходять прихований обсяг

Якісна оцінка кошторису сайту залежить від запитань, що розкривають межі, а не від кількості рядків у комерційній пропозиції. Перевірте такі пункти до вибору підрядника:

1. Хто створює, редагує та завантажує тексти, фотографії, картки товарів, переклади й SEO-метадані?
2. Скільки унікальних шаблонів або екранів буде спроєктовано, які стани інтерфейсу враховано та скільки циклів правок передбачено?
3. Чи входять мобільні макети й адаптивна верстка для всіх типів сторінок, а не лише для головної?
4. Які системи інтегруються, які дані передаються, хто надає доступи та як перевіряється обмін даними?
5. Які сценарії тестуються, хто фіксує дефекти, скільки раундів виправлень входить у запуск?
6. Що саме передається після завершення: доступи, вихідний код, дизайн-файли, інструкції, облікові записи та права використання?
7. Які роботи не входять до пропозиції: домен, хостинг, платні сервіси, ліцензії, підтримка, аналітика, міграція даних?

Якщо у вашому проєкті важливі макети, компоненти й подальша робота іншої команди, окремо узгодьте, що охоплює створення дизайну сайту: кількість шаблонів, стани інтерфейсу, адаптиви, формат файлів і правила передачі. Формулювання «дизайн включено» без цих деталей не дає достатньої основи для порівняння.

Приймайте рішення за ризиком і керованістю

Коли матрицю заповнено, не зводьте рішення до одного рейтингу з випадковими балами. Власнику бізнесу зазвичай корисніше оцінити кожен варіант за чотирма критеріями: відповідність обов’язковому обсягу, ясність припущень, зручність взаємодії та прогнозованість змін. Якщо якась пропозиція дешевша, але містить більше незакритих пунктів, її варто розглядати як початкову конфігурацію, а не як фінальну вартість проєкту.

Під час порівняння пропозицій розробників зверніть увагу на реакцію на уточнення. Підрядник, який ставить конкретні запитання, не обов’язково ускладнює процес; часто він намагається обмежити ризики до старту. Водночас надто загальна відповідь без припущень може приховувати значний обсяг майбутніх погоджень.

Попросіть фіналістів підтвердити одну версію переліку робіт і зафіксувати, як обробляються зміни: хто їх описує, коли вони оцінюються, що вважається новою функцією, а що виправленням дефекту. Це важливіше за формальну обіцянку «все включено».

Що формує бюджет після вирівнювання обсягу

Після нормалізації можна предметно обговорювати бюджет. На нього впливають не лише кількість сторінок, а й унікальність інтерфейсу, складність ролей і сценаріїв, інтеграції, міграція даних, вимоги до контенту, перевірки, документація, запуск і подальша підтримка. Детальніше про те, скільки коштує створити сайт, варто читати саме після визначення потрібної комплектації: інакше будь-яка сума буде відірвана від конкретного результату.

Не намагайтеся штучно зробити всі пропозиції дешевшими одночасно. Спершу вирішіть, що можна перенести на наступний етап без шкоди для запуску, а що є обов’язковим. Наприклад, додаткові контентні модулі іноді можна відкласти, але критичну перевірку платежу, заявки або передачі даних до CRM — ні.

Фінальна перевірка перед погодженням

Перед підписанням або стартом робіт перечитайте обрану пропозицію як документ для майбутнього приймання. Переконайтеся, що в ній є погоджений перелік результатів, відповідальні сторони за контент і доступи, порядок демонстрацій, межі правок, умови зміни обсягу та перелік матеріалів, які переходять замовнику.

Якщо два кошториси після уточнень близькі за складом, обирайте не лише за фінальною сумою. Врахуйте, де менше непідтверджених припущень, де зрозуміліше описано результат і де вашій команді простіше надавати зворотний зв’язок. Саме так порівняння перетворюється з вибору «дешевше або дорожче» на кероване рішення про обсяг, ризики та відповідальність.