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

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

В Ameton рекомендуем начинать сравнение не с общей суммы, а с вопроса: какой бизнес-результат подрядчик обязуется обеспечить к запуску. Именно этот ответ показывает, сопоставимы ли два коммерческих предложения

Высокая стоимость не равна завышенной стоимости

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

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

Например, фраза «интеграция с 1С» может означать совершенно разный объём. В простом случае сайт получает товары раз в сутки. В сложном — синхронизирует остатки по складам, персональные цены, заказы, статусы оплаты и ошибки обмена. Название работы одинаковое, а состав и риск для бизнеса — разные

Какие признаки действительно указывают на завышение

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

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

Как формируется стоимость разработки сайта

Стоимость проекта формируется не из количества страниц, а из пути от бизнес-задачи к работающему сценарию

Бизнес-задачи → Сценарии → Данные → Интеграции → Архитектура → Разработка → Тестирование → Стоимость

Если компании нужен сайт для заявок, достаточно определить структуру, формы и правила обработки обращений. Если сайт должен принимать заказы, показывать персональные цены и передавать документы партнёрам, появляются роли, правила доступа, обмены данными и дополнительные проверки

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

Пример из практики Ameton: при оценке интернет-магазина заказчик считал личный кабинет простой страницей с историей заказов. Во время обсуждения выяснилось, что пользователи должны видеть договорные цены, документы, статусы отгрузки и данные нескольких организаций. Команда разделила базовый запуск и последующее развитие: иначе в смете оставалась бы одна строка «личный кабинет», которая не объясняла реальный объём работ и риск переделок

Почему оценки отличаются у разных подрядчиков

Разные оценки не всегда означают, что один подрядчик завышает цену. Чаще предложения отличаются глубиной проработки, составом команды, включёнными этапами и допущениями, которые сделаны до старта

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

Высокая стоимость не доказывает качество. Однако низкая стоимость не доказывает экономию: иногда она означает, что часть работ, рисков и ответственности пока не названа

Какие работы часто не попадают в первоначальную смету

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

Чаще отдельной оценки требуют:

• подготовка и массовое наполнение каталога

• перенос материалов, пользователей, заказов и других данных со старого сайта

• лицензии, хостинг, платные модули и внешние сервисы

• доработка нестандартных интеграций

• исправление проблем существующего кода

• дополнительные функции, которые появились после согласования первого запуска

• обучение сотрудников работе с новым процессом, если оно не включено в договорённость

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

Как сравнить дорогую и дешёвую смету

Сравнивать сметы нужно по одинаковому результату, а не по совпадающим названиям работ. «Интернет-магазин», «личный кабинет» или «интеграция» сами по себе не описывают объём задачи

Корпоративный сайт и интернет-магазин нельзя сравнивать только по числу экранов. У интернет-магазина появляется обработка заказа, оплата, доставка, статусы и работа с каталогом. Аналогично готовое решение и индивидуальная разработка решают разные задачи: шаблон обычно подходит для типовых процессов, а индивидуальный проект нужен, когда сайт должен поддерживать важную для бизнеса логику

Если подрядчик предлагает готовое решение, стоит уточнить, какие изменения возможны без вмешательства в его архитектуру. Глубокая переделка шаблона иногда обходится дороже, чем разработка нужной функции с понятными границами

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

Понять логику цены можно ещё до подписания договора. Полезнее спрашивать не «почему так дорого», а «что именно создаёт эту стоимость и как вы это проверите»

Вопросы, которые следует задать:

• Какие результаты входят в каждый этап работ?

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

• Что заказчик должен подготовить самостоятельно?

• Какие риски и допущения учтены в оценке?

• Что не входит в смету и может потребовать отдельного бюджета?

• Как будут согласовываться новые требования после старта?

• По каким критериям заказчик примет результат?

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

Пример из практики Ameton: перед доработкой действующего сайта клиент уточнил, зачем в оценке предусмотрена первичная диагностика. Команда объяснила, что новая функция будет использовать данные из существующего обмена с учётной системой, а значит, нужно проверить его текущую логику и возможные ограничения. После изучения стало понятно, какие работы действительно необходимы и что именно войдёт в смету. Такой вопрос помогает заказчику увидеть состав оценки до начала проекта, а не после появления дополнительной задачи

Когда стоит попросить независимую расшифровку сметы

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

Отдельная расшифровка особенно нужна, если:

• предложение заметно дороже других, но различия в составе работ не названы

• подрядчик отказывается обозначить исключения и критерии приёмки

• проект передаётся после работы другой команды

• в смете есть крупные общие строки без результата

• сайт должен поддерживать критичные бизнес-процессы

Мы рекомендуем обсуждать смету вместе с кратким описанием сценариев первого запуска. Тогда заказчик видит не только стоимость, но и последовательность решений, от которых зависит итоговый бюджет

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

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