Почему одинаковые сайты стоят по-разному?

Главное:

• Количество страниц редко определяет бюджет сильнее, чем процессы, которые сайт должен поддерживать

• Один и тот же блок на экране может требовать разной логики для разных компаний

• Интеграция с 1С — это не одна задача, а правила передачи данных и проверки результата

• Низкая сумма без состава работ не помогает сравнить предложения

• Смету нужно сравнивать по результатам, границам и исключениям, а не только по итоговой цифре

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

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

Похожий интерфейс может скрывать разную бизнес-логику

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

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

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

Из чего складывается стоимость разработки сайта

Стоимость сайта складывается последовательно: бизнес-задачи → сценарии → данные → интеграции → архитектура → разработка → тестирование → стоимость

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

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

Если в проекте есть интеграция, то увеличивается объём анализа, разработки и тестирования, потому что нужно проверить не только соединение систем, но и бизнес-результат. Заказ должен дойти до менеджера, цена — остаться корректной, а повторная отправка — не создать дубль

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

Какой функционал проекта чаще всего влияет на смету

На бюджет проекта влияют нестандартные сценарии пользователя и сложные интеграции

Данные и каталог

Запрос клиента → «нужен каталог продукции»
Решение команды → определить структуру товаров, свойства, фильтры, изображения и источник обновления
Риск без проработки → пользователи не находят товар, а данные отображаются по-разному в каталоге и карточке
Влияние на смету → увеличивается объём работы с контентом, импортом, поиском и проверкой

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

Интеграции

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

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

Личный кабинет и роли пользователей

Запрос клиента → «нужен личный кабинет»
Решение команды → определить действия пользователя, связь с организацией, права доступа и нужные данные
Риск без проработки → клиент увидит не те условия или не получит нужный документ
Влияние на смету → увеличивается объём проектирования, разработки и проверки связанных сценариев

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

Тестирование и выпуск

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

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

Компетентная команда задаёт вопросы до оценки

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

Полезно спросить подрядчика:

• Какие сценарии вы изучите до начала работ?

• Какие данные и разделы может затронуть эта функция?

• Что вы проверите после выпуска?

• Какие риски видите до разработки?

• Какая информация нужна, чтобы оценить задачу?

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

В Ameton считают, что компетентность проявляется в умении связать изменение кода с бизнес-результатом. Разработчик должен понимать не только, как реализовать функцию, но и какой пользовательский сценарий нельзя нарушить

Готовое решение и индивидуальная разработка дают разный состав работ

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

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

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

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

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

Что обычно считают отдельно от разработки

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

Отдельно могут учитываться:

• лицензия 1С-Битрикс и её продление

• хостинг, домен и инфраструктурные сервисы

• платные модули и сервисы оплаты, доставки или рассылок

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

• миграция данных и сохранение материалов со старого сайта

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

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

Как получить более точную оценку

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

Для оценки полезно описать:

• тип сайта и его роль в бизнесе

• действия, которые должен выполнить посетитель

• роли пользователей и различия между ними

• источники товаров, цен, остатков, заявок и заказов

• нужные интеграции

• наличие действующего сайта и задачи миграции

• готовность контента и каталога

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

• улучшения, которые можно перенести на следующий этап

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

Для каких проектов применим этот подход

Такой подход подходит для разработки са йта любого типа. Он особенно полезен, если сайт связан с продажами, учётной системой, CRM, оплатой, доставкой или внутренними процессами компании

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

Типичные заблуждения о стоимости сайта

Количество страниц определяет стоимость сайта. Неверно: важнее действия пользователя, правила данных и связанные сценарии. Проверять нужно не число экранов, а состав функций и процессов

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

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

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

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