Как читать смету на разработку и не переплатить

Читать смету на разработку нужно не с итоговой суммы, а с состава работ: что именно будет сделано, кем, по какой единице оценки и с каким запасом. Хорошая смета разбита по сценариям или модулям, включает аналитику, тестирование, запуск и запас на неизвестное, а плохая — одна цифра или список экранов с часами. Понимая структуру, вы увидите, где переплачиваете, а где цена занижена.

Разберём, из чего состоит смета, как проверить каждую строку и какие вопросы задать подрядчику.

Из чего состоит смета на разработку?

Смета на разработку состоит из этапов работ, их оценки в часах или деньгах, ролей исполнителей и условий: что входит, что не входит и какие допущения сделаны. Итоговая сумма — производная от всего этого, и сама по себе ничего не говорит о качестве оценки.

Обязательные части хорошей сметы:

• аналитика и проектирование — сценарии, прототипы, архитектура;
• дизайн интерфейса, если он не готов;
• разработка, разбитая по функциональным блокам;
• тестирование и исправление ошибок;
• запуск: настройка серверов, мониторинга, бэкапов;
• управление проектом;
• запас на неизвестное с объяснением, откуда он взялся;
• список допущений и того, что в смету не входит.

Типичные доли этих частей мы показывали в статье сколько стоит разработка MVP.

Как проверить разбивку разработки?

Разбивку разработки проверяют на связь с реальными сценариями продукта: каждая строка должна соответствовать законченному действию пользователя или модулю системы, а не абстрактной «разработке бэкенда». Если по строке нельзя понять, что появится в продукте, оценку нельзя проверить.

Пример строки, которую можно проверить:

Сценарий «Оплата заказа»                        оценка
  фронтенд   — корзина, выбор способа, статус     16–24 ч
  бэкенд     — платёж, вебхук банка, чек           24–32 ч
  админка    — список оплат, возврат               8–12 ч
  тесты      — успех, отказ, повторный вебхук      8–12 ч
  итого                                            56–80 ч

И пример, который проверить нельзя: «Бэкенд — 400 часов». Непонятно, что входит, где риски и что можно отрезать при нехватке бюджета.

Вилка лучше точной цифры

Честная оценка на ранней стадии — это вилка, а не одна цифра. Ширина вилки показывает, сколько неопределённости осталось: узкая — требования понятны, широкая — есть вопросы, которые стоит закрыть до старта. Точная цифра без вилки при сырых требованиях означает либо большой скрытый запас, либо будущие допсоглашения.

Фото: Unsplash

Как оценить ставки и роли?

Ставки и роли оценивают вместе: важна не только цена часа, но и то, кто выполняет работу и сколько часов уходит на каждую роль. Смета, где вся работа посчитана по одной усреднённой ставке, скрывает, сколько времени уйдёт на опытных специалистов, а сколько — на младших.

Что проверить	Хороший признак	Повод задать вопрос
Роли	Перечислены: аналитик, дизайнер, разработчики, QA, менеджер	Только «разработка»
Ставки	Указаны по ролям	Одна средняя ставка на всё
Управление проектом	10–15% от объёма работ (ориентир студии)	Нет вовсе или больше четверти
Тестирование	Отдельная строка или явно в каждом блоке	Не упомянуто
Запас на неизвестное	Назван и обоснован	Отсутствует при сырых требованиях
Допущения	Перечислены явно	Нет ни одного

Какие признаки говорят о заниженной или завышенной смете?

Заниженная смета обычно не содержит тестирования, запуска и запаса, а завышенная — оценивает простые вещи как сложные или закладывает работу, которая продукту не нужна. И то и другое видно, если сравнивать строки, а не итог.

Признаки заниженной сметы:

1. Нет тестирования и исправления ошибок.
2. Нет запуска и настройки инфраструктуры.
3. Интеграции с внешними сервисами оценены в пару часов.
4. Нет запаса на неизвестное при явно неполных требованиях.

Признаки завышенной сметы:

1. Микросервисы, Kubernetes и сложная инфраструктура для продукта без пользователей.
2. Собственная разработка того, что закрывается готовым сервисом.
3. Функции, которых нет в ваших требованиях, «потому что так правильно».
4. Одинаково большие оценки для простых и сложных блоков — признак оценки «на глаз».

Какие вопросы задать подрядчику по смете?

Вопросы по смете задают, чтобы понять логику оценки, а не чтобы сбить цену. Хороший подрядчик охотно объясняет, из чего складывается каждая строка и что можно упростить, — это нормальная часть работы.

Что спросить:

• Какие допущения лежат в основе оценки и что будет, если они не подтвердятся?
• Какие строки самые рискованные и почему?
• Что можно отложить во вторую версию и сколько это сэкономит?
• Как оплачиваются изменения требований по ходу работы?
• Что входит в гарантийный период после запуска?

Модель оплаты тоже влияет на то, как читать смету: при фиксированной цене запас уже внутри суммы, при оплате по времени важнее вилка и лимиты. Подробнее — в статье fixed price или Time & Materials.

Коротко

• Читайте смету с состава работ, а не с итоговой суммы.
• Каждая строка разработки должна соответствовать сценарию или модулю, который можно проверить.
• Честная оценка на ранней стадии — вилка; её ширина показывает неопределённость.
• Проверьте роли, ставки, тестирование, запуск, запас и явные допущения.
• Задавайте вопросы о рисках и о том, что можно отложить, — это лучший способ снизить цену без потери качества.