Как понять, что подрядчик завышает стоимость IT-проекта: признаки и вопросы

Высокая оценка IT-проекта не всегда означает, что подрядчик завышает стоимость. В неё могут входить discovery, сложные интеграции, безопасность, миграция данных, тестирование и сопровождение. Но и низкая цена не доказывает эффективность: важные работы могли просто не попасть в предложение. Надёжный способ сравнить варианты — привести их к одной структуре и проверить, что именно покупает бизнес.

Ниже — практический разбор для заказчика: какие вопросы задать, как отделить MVP от опций и как понять, что изменение сметы объяснимо.

Сначала сравните границы, а не суммы

Почему одинаковое ТЗ получает разные оценки

Фраза «сделать личный кабинет» описывает направление, но не объём. Один подрядчик включает вход, профиль и список заказов; другой сразу закладывает роли, обмен с ERP, уведомления, импорт архива, аудит и поддержку. Оба могут считать добросовестно, но считать разные продукты.

Признаки завышенной и опасно низкой оценки

Завышение видно по несоответствию объёма и результата: в смету попали модули, которые не нужны для первого сценария, или часы управления не связаны с этапами и рисками. Низкая цена тоже требует вопросов: отсутствие аналитики, тестирования и поддержки часто проявляется после старта. Ни один признак не доказывает недобросовестность — это повод запросить объяснение.

Как привести предложения к одной структуре

Попросите показать результат каждого этапа: карту сценариев, прототип, модель данных, API-контракт, рабочий контур, тесты, инструкцию и план запуска. Названия у команд разные, поэтому сравнивайте выходы и критерии приёмки, а не красивые формулировки. Если интеграция описана одной строкой, уточните API, авторизацию, лимиты, повторные запросы и обработку сбоя.

Что проверить до подписания

Зафиксируйте допущения: готовность данных, число ролей, внешние системы, окружения и ограничения по срокам. Разделите обязательный MVP и опции второй очереди. Уточните, как считается изменение требования, кто принимает этап и входят ли в сумму миграция, релиз, документация, исправления и сопровождение.

Как выглядит честный пересмотр сметы

Если discovery выявил отсутствие нужного API или более грязные данные, оценка может вырасти объективно. Нормальный пересмотр показывает причину, затронутые задачи, влияние на срок и варианты: принять объём, упростить сценарий, отложить функцию или остановить этап. Опасен не диапазон, а точная сумма без границ и объяснений.

Если у вас есть два коммерческих предложения, обсудите их структуру с Paladin Engineering. Полезно принести версии без чувствительных данных: цель, функции, сроки и допущения.

Чек-лист вопросов подрядчику

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

FAQ: как проверить оценку IT-проекта

Можно ли сравнить подрядчиков только по общей сумме?

Нет. Сначала сопоставьте границы, функции, этапы, интеграции, приёмку и поддержку.

Почему нужен discovery до точной оценки?

Потому что стоимость зависит от данных, ролей, ограничений и внешних систем. Discovery переводит догадки в решения.

Что делать, если смета выросла?

Попросите связать изменение с конкретным требованием или ограничением и сравните варианты: принять, упростить или отложить.

Опасна ли фиксированная цена?

Нет, если зафиксированы границы и порядок изменений. Одна сумма без результата создаёт иллюзию контроля.

Что важнее цены?

Команда, прозрачность работ, поддержка и способность объяснить решения. Дешёвый проект без этих опор может оказаться дороже.

Paladin Engineering может провести предпроектный разбор, помочь сформировать границы MVP и подготовить оценку с допущениями. Оставьте заявку на обсуждение проекта, если нужно сопоставить стоимость, сроки и риски.

Как снизить риск ещё до выбора подрядчика

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

Так заказчик получает не только цену, но и карту решений: что можно упростить, что требует проверки, а что относится к следующей очереди. Это снижает риск принять дешёвое предложение, в котором нет нужного результата, или дорогое предложение, перегруженное функциями вне MVP.