Почему сметы на один сайт расходятся в разы и как их сравнить

На тендер на сайт приходят десять предложений: одно — на 600 тысяч, другое — на 2,5 миллиона, третье — на 5. В каждом написано «дизайн, разработка, адаптив, SEO». Руководитель видит одну задачу и несколько цен; подрядчики уверены, что посчитали честно. Но сравнивать пока нечего.

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

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

Фраза «нужен новый сайт» слишком расплывчата для сметы. Под ней могут скрываться совершенно разные проекты: презентация новой услуги, каталог на несколько тысяч позиций, интернет-магазин с оплатой, личный кабинет для дилеров или замена старой платформы без потери поискового трафика.

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

До сравнения зафиксируйте хотя бы пять решений:

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

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

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

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

Особенно внимательно посмотрите на четыре зоны.

Первая — контент. «Наполнение силами клиента» может быть нормальным условием. Но тогда нужно знать, кто собирает характеристики, фотографии, кейсы, документы, тексты и права на их использование. Если это не назначено, запуск обычно сдвигается, а дизайн начинает жить на заглушках.

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

Третья — интеграции. В смете может быть «подключение CRM», но не быть обработки ошибок, передачи источника лида, тестирования дублей, обратного статуса или ответственности за недоступное API. Такая интеграция выглядит готовой до первого нестандартного заказа.

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

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

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

Минимальная матрица выглядит так:

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

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

Сайт продолжает стоить денег после релиза. Хостинг, лицензии, платные сервисы, поддержка, обновления, резервные копии, мониторинг, доработки, создание страниц, работа с каталогом, исправление последствий неудачных решений — это стоимость владения. Её иногда обозначают аббревиатурой TCO, total cost of ownership, то есть полная стоимость владения.

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

У компании с редкими обновлениями и простой формой связи поддержка выглядит иначе, чем у интернет-магазина с ежедневными ценами, остатками и оплатой. У B2B-портала может быть меньше посещений, но выше цена одного сбоя в правах доступа или заказах. Универсальной цифры «нормальной поддержки» здесь нет.

Иногда честный ответ подрядчика — не фиксированная смета, а отдельный этап исследования. Заказчики часто воспринимают это как попытку продать воздух. Но риск обычно возникает не из-за исследования, а из-за того, что его результат нигде не зафиксирован.

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

Если после такого этапа понятна не вся будущая система, это не повод возвращаться к смете на догадках. Как переходить от первой проверяемой версии к полноценному продукту, разбираем в статье про итерационную разработку.

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

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

У каждого допущения должны быть последствия. Например: «цена рассчитана для 300 карточек при наличии единого файла характеристик»; «интеграция с CRM включает создание лида и передачу источника, но не синхронизацию статусов заказа»; «в макете предполагается один язык». Тогда после уточнения можно понять, что изменилось, почему и на сколько, а не получать счёт с формулировкой «дополнительные работы».

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

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

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

Спросите не «сколько людей у вас в штате», а кто будет участвовать в вашем проекте и за что отвечает. Кто принимает архитектурные решения? Кто проверит мобильную форму и ошибку в интеграции? Кто ведёт статус проекта? Кто подхватит работу, если ключевой специалист недоступен? Ответы часто важнее красивой презентации команды.

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

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

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

Смета — не прайс-лист на «сайт», а гипотеза о составе работ и распределении риска. До выбора подрядчика:

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

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