Сравнивать предложения на разработку ПО только по итоговой сумме — почти всегда недостаточно. Два подрядчика могут назвать разные цифры, потому что включили разный объём аналитики, прототипирования, тестирования, интеграций и поддержки. Надёжное сравнение начинается с приведения предложений к одной структуре: что именно строим, какие допущения приняты, как принимаются результаты и что будет после релиза. В этой статье — рабочая схема, которую можно использовать на встрече с подрядчиками.
Почему одинаковая задача получает разные цены
Коммерческое предложение — это не ценник, а модель будущего проекта. В одном документе может быть только разработка основных экранов, в другом — discovery, дизайн, backend, интеграции, тестирование, аналитика, публикация и гарантийный период. Если сравнивать только итог, бизнес рискует выбрать не более эффективного исполнителя, а самый узкий состав работ.
Разница возникает и из-за неопределённости. Подрядчик фиксирует часть решений как допущения: количество ролей, источники данных, ограничения внешних API, правила расчёта и объём миграции. Чем больше неизвестных оставлено за скобками, тем ниже может выглядеть стартовая сумма — и тем выше вероятность отдельной оценки позже.
- Сравнивайте состав результата, а не размер счёта
- Отделяйте обязательный объём от опций
- Проверяйте, какие неизвестные вынесены в допущения
Нужна независимая оценка? Напишите в Telegram или оставьте заявку — разберём исходные требования и поможем подготовить сопоставимый следующий шаг.
Приведите предложения к единому шаблону
Перед сравнением составьте собственную таблицу требований и попросите каждого участника заполнить её. Не нужно навязывать конкретный стек или способ реализации, но нужно одинаково описать бизнес-результат, роли пользователей, внешние системы, ограничения по данным и критерии готовности.
Если подрядчик не может оценить часть работ, это не автоматически минус. Важно, чтобы неопределённость была названа, объяснено, как её снять, и указано, что произойдёт с оценкой после уточнения. Прозрачная неопределённость полезнее красивой, но необъяснимой точности.
- границы первой версии
- интеграции и миграция
- аналитика и тестирование
- обучение и поддержка
Какие строки сравнивать в таблице
Удобно разложить каждое предложение по блокам. В колонке «результат» фиксируется не активность команды, а проверяемый артефакт: прототип, работающий сценарий, API-контракт, отчёт о тестировании или инструкция. Рядом отмечаются часы или стоимость, зависимости, исключения и критерий приёмки.
Такой формат позволяет увидеть, где цена ниже за счёт отсутствующего результата. Например, у одного подрядчика включён импорт исторических данных, а у другого он назван отдельной опцией. Или тестирование у одного описано как отдельный этап, а у другого подразумевается без состава и границ.
Как оценить этапы и контроль изменений
Хорошее предложение показывает не только финальную дату, но и контрольные точки. Для каждой точки должны быть понятны входные данные, результат, формат демонстрации и способ принять работу. Это особенно важно для проектов, где требования уточняются по ходу разработки: иначе любое изменение превращается в спор о том, входило ли оно в исходную цену.
Попросите описать процедуру change request: кто фиксирует изменение, как оценивается влияние на сроки и бюджет, какие решения считаются согласованными. В зрелом процессе это не бюрократия, а способ сохранить управляемость проекта.
- этап и результат
- критерий приемки
- ответственный за решение
- правила изменения объёма
Цена проекта: что спросить о допущениях
Цена становится сопоставимой только после того, как понятны условия, при которых она рассчитана. Спросите, какие объёмы заложены для пользователей, ролей, интеграций, документов, языков, устройств и миграции. Отдельно проверьте, учтены ли инфраструктура, лицензии, сервисы рассылок, публикация и сопровождение.
Не требуйте от подрядчика обещать неизменную стоимость при меняющихся требованиях. Требуйте другой вещи — понятного механизма пересчёта. Тогда бизнес видит не только стартовый бюджет, но и диапазон решений, которые могут на него повлиять.
- Какие допущения влияют на цену?
- Какие работы считаются опциями?
- Как оформляется пересмотр оценки?
Как оценить подрядчика без субъективного «понравились люди»
Коммуникация важна, но её стоит дополнить проверяемыми признаками. Посмотрите, задаёт ли команда вопросы по бизнес-процессу, замечает ли противоречия в исходных данных, объясняет ли риски и умеет ли отделять обязательное от желательного. Это информативнее длинного списка технологий.
Попросите показать обезличенный пример результата: структуру discovery, фрагмент технического задания, формат демо, шаблон отчёта о тестировании. Конфиденциальные детали не нужны. Важно увидеть, как команда превращает договорённости в артефакты, по которым можно принять работу.
- задаёт вопросы до оценки
- показывает артефакты, а не только слайды
- называет риски и границы ответственности
Что должно быть в финальном сравнении
Финальная таблица не должна превращаться в конкурс по количеству строк. Оставьте несколько критериев, связанных с вашим решением: полнота результата, прозрачность допущений, управляемость изменений, опыт с нужными интеграциями, качество поддержки и совокупная стоимость владения.
Отдельно выпишите вопросы, на которые нельзя ответить по документам. Проведите короткий одинаковый follow-up со всеми участниками и внесите ответы в таблицу. После этого решение становится воспроизводимым: его можно объяснить руководству и использовать как основу договора.
- что получаем к релизу
- что остаётся за рамками
- как принимаем
- как сопровождаем
- какие риски принимаем
Короткий чек-лист перед решением
- Одинаково описать объём первой версии для всех подрядчиков
- Выделить допущения, исключения и опции
- Проверить критерии приёмки по каждому этапу
- Уточнить интеграции, миграцию, инфраструктуру и поддержку
- Зафиксировать процедуру изменений до подписания
- Сравнить совокупный риск и стоимость, а не только стартовый счёт
Готовы обсудить задачу? Напишите в Telegram — команда Paladin Engineering предложит формат аудита, discovery или разработки под ваш контекст.
Вопросы, которые стоит задать подрядчику
Нужно ли просить всех подрядчиков использовать одну и ту же технологию?
Нет, если стек не является жёстким ограничением. Сначала сравните результат, риски и ограничения решения; технологический выбор попросите обосновать через требования проекта.
Что делать, если одно предложение вдвое дешевле?
Проверить состав работ и допущения построчно. Большая разница часто объясняется отсутствующими этапами, интеграциями, тестированием или поддержкой, а не только эффективностью команды.
Можно ли выбрать подрядчика только по портфолио?
Портфолио полезно как сигнал опыта, но не заменяет разбор процесса: задайте вопросы о похожих ограничениях, артефактах и критериях результата.
Как сравнить фиксированную и почасовую модель?
Сначала приведите к общей картине объём и правила изменений. Фиксированная цена снижает неопределённость только при ясном объёме, а почасовая требует прозрачного учёта и регулярной сверки результата.
Нужен ли отдельный discovery перед договором?
Не всегда отдельный, но неопределённость должна быть управляемой: discovery может быть самостоятельным этапом или частью первой фазы с понятным результатом и лимитом.
Какая ошибка встречается чаще всего?
Сравнивать красивые коммерческие документы, не проверив, что именно будет принято и кто отвечает за данные, интеграции и эксплуатацию после релиза.
Комментарии