В статье
Проверять смету разработчика нужно по составу результата, границам и допущениям, а не по впечатлению от итоговой суммы. У каждой существенной работы должно быть объяснение: какую задачу она решает, что будет передано и как вы убедитесь в готовности. Цена сама по себе не показывает, есть ли в предложении лишняя работа.
Я предлагаю сначала сделать предложения сопоставимыми. Один исполнитель мог включить перенос данных и запуск, другой — только создание экранов. Пока состав разный, сравнение итогов говорит мало. Задача собственника — не пересчитать программирование за разработчика, а понять, за какой проверяемый результат он платит.
Начните с границ проекта
Сопоставьте смету с коротким описанием процесса: пользователи, действия, данные и конечный результат. Отметьте обязательные функции и пожелания на будущее. Если исполнитель оценивает всё сразу, попросите выделить минимальный рабочий сценарий и отдельно — дальнейшее развитие.
Зафиксируйте, что не входит в предложение: подготовка контента, очистка исходных файлов, подключение старой учётной системы, обучение или сопровождение. Отсутствующая строка не означает, что работа бесплатна. Возможно, её предполагается выполнить силами заказчика.
Общие факторы цены разобраны в статье о стоимости разработки приложения. Здесь речь о проверке конкретного коммерческого предложения: его полноте, обоснованности и управляемости изменений.
Какие блоки должны быть объяснены
Требования и проектирование
Исследование процесса, описание сценариев и прототип помогают договориться о будущем результате. Это самостоятельная работа, если после неё остаются согласованные требования, схема данных, список ограничений или проверенный макет.
Попросите назвать документы и решения, которые получите после этого этапа. Строка «аналитика» без результата слишком неопределённа. Но требовать подробную архитектуру бесплатно до изучения систем тоже не стоит: часть неопределённости можно снять только отдельным обследованием.
Интерфейс и обработка данных
Frontend — часть, с которой взаимодействует пользователь: формы, страницы, сообщения. Backend — обработка данных и правил за интерфейсом. Для бизнеса важно, какие сценарии покрываются вместе, а не сколько модных названий перечислено.
Спросите, включены ли роли, ошибки, пустые состояния и восстановление после прерванного действия. Экран может выглядеть готовым, но не сохранять результат или показывать чужие данные. Поэтому строка «личный кабинет» должна раскрывать поведение, а не только перечень страниц.
Интеграции и инфраструктура
Для каждой интеграции нужны источник, получатель, объекты обмена и предположения о доступности подключения. Если документация ещё не изучена, точная оценка должна сопровождаться оговоркой, а не обещанием совместимости.
Различайте настройку запуска приложения и регулярную оплату инфраструктуры. Сервер, домен, резервные копии, внешние сервисы и обслуживание могут оплачиваться отдельно. Уточните, какие учётные записи оформляются на компанию и кто управляет расходами после передачи продукта.
Тестирование и приёмка
Попросите перечислить способы проверки: обычные сценарии, неверные данные, права доступа, сбои интеграций и восстановление. «Заказчик посмотрит и скажет» — недостаточный критерий готовности сложного продукта.
Для обсуждения требований безопасности можно опираться на OWASP ASVS, открытый стандарт проверки веб-приложений. Нужный набор требований и его версию выбирают под риски проекта. Упоминание стандарта в смете ещё не означает, что проверки проведены или продукт сертифицирован.
Отделите неизвестное от необоснованного
Техническая неопределённость — это конкретный вопрос, который влияет на объём работ. Например, можно ли получить историю изменений из старой системы или удастся ли восстановить данные из имеющегося архива. Нормальная оценка объясняет, как и когда этот вопрос будет проверен.
Попросите для спорного блока указать допущение, действие для его проверки и последствия отрицательного результата. Так видно, что лучше обследовать до основного договора. Запас на риск может быть обоснован, если понятно, какой именно риск покрывается и как согласуются изменения.
Тревожный признак — не диапазон часов, а уверенная точность без доступа к данным и без списка ограничений. Не менее опасна формулировка «разберёмся по ходу», если у заказчика нет возможности остановить этап или согласовать дополнительный бюджет.
Условный пример проверки предложения
Представим два предложения на отчёт из CRM. В первом указаны подключение источника, сопоставление полей, контроль повторов, тестовые данные и уведомление о сбое. Во втором — «выгрузка и красивый отчёт». Итог второй сметы может выглядеть привлекательнее, но готовность результатов пока несопоставима.
Составьте один список приёмки и попросите обоих исполнителей ответить по нему. Если первый оценил ненужную двустороннюю синхронизацию, её можно убрать. Если второй не учёл обработку ошибок, это нужно добавить или осознанно оставить на стороне компании.
Это учебный пример, а не оценка конкретного подрядчика. Нельзя заключать, что более дорогой вариант честнее, а более подробный документ автоматически лучше. Каждая строка должна соответствовать задаче и риску.
Где скрываются лишние и пропущенные работы
Проверьте, не предлагается ли отдельное приложение для функции, которая уже есть в действующей системе. Обратная ошибка — исключить из сметы всё, что не видно на экране, хотя без этого продукт нельзя надёжно использовать.
Для проекта CRM полезно сверить предложение с этапами её разработки: обследование и перенос данных не исчезают от того, что их не назвали. А выбор между новой и готовой системой — отдельное решение, которое стоит принять до подробной оценки разработки.
Дешёвая смета может стать дорогой из-за постоянных дополнений, зависимости от личных доступов исполнителя или переделки непринимаемого результата. Дорогая — из-за неоправданного масштаба. Не существует универсальной суммы, выше которой работу можно считать завышенной.
Вопросы перед согласованием
- Какой рабочий результат я получу по каждому этапу?
- Какие сценарии и данные не входят в оценку?
- Какие предположения ещё не проверены и сколько стоит их проверить?
- Кто отвечает за лицензии, доступы и исходные данные?
- Как принимаются ошибки, изменения и дополнительные пожелания?
- Что передаётся для запуска, восстановления и сопровождения?
Сама смета не заменяет договор и проверку исполнения. Если проект уже остановился или есть спор о фактически сделанной работе, нужно отдельно изучить код, документы и договорённости. Сравнение строк предложений для такого вывода недостаточно.
Для собственника хорошая смета — инструмент управления объёмом и риском. После её разбора должно быть понятно, что обязательно, что можно отложить и какие условия способны изменить бюджет. Если нужна независимая проверка предложения, следующий шаг — Обсудить техническую экспертизу. Цель разбора — получить аргументы для решения, а не заранее доказать, что подрядчик неправ.