Как выбрать подрядчика для разработки интернет-магазина на Битрикс?
На что обратить внимание при выборе подрядчика для интернет-магазина:
-
Полезно изучить портфолио, но это не заменяет вопросы о вашем каталоге и процессах
-
«Интеграция с 1С» должна быть разложена на данные, направления обмена и ошибки
-
В смете важнее состав первого запуска, чем итоговая сумма
-
Команда должна объяснить, как будет проверять заказ, оплату, доставку и обмен данными
-
Прозрачное понимание того, что заказчик получит при передаче сайта и как будет его развивать
Интернет-магазин редко ограничивается витриной и корзиной. Даже при похожем дизайне два проекта могут сильно отличаться: в одном товары заполняются вручную и используется один способ доставки, в другом нужно синхронизировать остатки по складам, несколько типов цен, заказы, статусы оплат и правила работы с клиентами
В Ameton начинаем разговор не с выбора шаблона, а с пути заказа: от появления товара в каталоге до обработки заказа сотрудником компании. Такой разбор показывает, какие компетенции действительно нужны подрядчику и что следует включить в первый этап
Выбирайте подрядчика по пониманию магазина целиком
Подрядчик должен понимать, как интернет-магазин принимает заказ: от выбора товара до оплаты заказа и его обработки
Для бизнеса важен не факт публикации каталога, а корректный путь товара, заказа и оплаты через связанные системы
Если товары, цены и остатки обновляются из учётной системы, команда должна уточнить, где хранится актуальная информация и что происходит при ошибке обмена. Если покупатель видит персональные цены, нужно заранее определить, кто получает такие условия, как они обновляются и что увидит новый пользователь. Если заказ передаётся в CRM или учётную систему, важен не только факт отправки, но и корректный статус после обработки
Подрядчик, который начинает с вопроса «сколько будет страниц», может не заметить важные риски. Количество страниц влияет на объём контента и дизайна, но редко определяет сложность магазина так же сильно, как правила работы с данными и заказами
Какие вопросы студия должна задать до оценки проекта
Компетентный подрядчик не называет точную стоимость интернет-магазина до уточнения ключевых сценариев. Сначала нужно понять, что именно сайт должен делать и какие системы будут участвовать в работе
Полезные вопросы со стороны студии:
-
какие товары продаёт компания и как устроен каталог
-
где редактируются цены, остатки, свойства и изображения
-
какие действия должен выполнить покупатель до оформления заказа
-
какие способы оплаты и доставки нужны на первом этапе
-
нужны ли личный кабинет, история заказов, персональные цены или документы
-
куда должны передаваться заказы и в каком виде
-
есть ли действующий сайт, данные для миграции и накопленные доработки
-
какие функции обязательны для запуска, а какие можно перенести на следующий этап
Бизнес-задачи → Сценарии → Данные → Интеграции → Архитектура → Разработка → Тестирование → Запуск
Если компания не разделяет обязательный функционал и улучшения, первый этап часто разрастается до бесконечности. Если команда фиксирует состав запуска заранее, то дополнительные идеи можно оценивать отдельно, не ставя под угрозу основную дату релиза
Как проверить коммерческое предложение студии
Коммерческое предложение должно показывать, что подрядчик понял задачу, а не просто применил универсальный шаблон сметы. Для интернет-магазина особенно важны границы работ по каталогу, интеграциям, оплате, доставке и тестированию
|
Критерий |
Хороший вариант |
Рискованный вариант |
|---|---|---|
|
Описание магазина |
Указаны функции, сценарии и состав первого запуска |
Есть общая строка «интернет-магазин под ключ» |
|
Каталог |
Понятны источник данных, импорт и правила отображения |
Предполагается, что каталог уже готов |
|
Интеграции |
Описаны данные, направления обмена и проверки |
Указано только «интеграция с 1С» |
|
Заказ |
Учтены корзина, оплата, доставка, статусы и уведомления |
Проверка ограничена страницей оформления |
|
Тестирование |
Описаны критичные сценарии приёмки |
Неясно, что именно будет проверено |
|
Изменения |
Есть порядок оценки новых требований |
Любая задача обсуждается после старта без границ |
|
Передача сайта |
Указаны доступы, исходные материалы и документация |
Заказчик получает только опубликованный сайт |
Низкая цена не всегда означает слабое предложение, а высокая — качественное. Сравнивать нужно не итоговые суммы, а то, что каждая студия включила в свое предложение: состав первого запуска, интеграции, тестирование, подготовку к запуску, исключения и границы ответственности. Если одна команда включает проверку обмена заказами и сценариев после оплаты, а другая оценивает только интерфейс и базовую настройку, это разный объём работ, даже если обе сметы называются «разработкой интернет-магазина». Подробнее – в статье Как оценить коммерческое предложение на разработку сайта?
Почему оценки интернет-магазина отличаются у разных подрядчиков
Оценки отличаются потому, что студии по-разному понимают границы ответственности. Одна команда может заложить только типовой каталог и оформление заказа, другая — анализ данных, настройку нестандартных правил цен, проверку обменов, сценариев оплаты и передачи результатов заказчику
|
Что сравнивают |
Комплексный подход к проекту |
Поверхностный подход к проекту |
|---|---|---|
|
Аналитика |
Сценарии, роли, данные и исключения определены до разработки |
Решения принимаются по ходу проекта |
|
Интеграции |
Учтены ошибки, дубли и повторная обработка |
Настроено только базовое соединение |
|
Тестирование |
Проверяется весь путь заказа |
Проверяется только открытие страниц |
|
Запуск |
Определены передача, приёмка и поддержка после релиза |
Работа завершается публикацией сайта |
Когда товары в каталоге заполнены по разным правилам, сначала необходимо привести в порядок данные: свойства, категории, цены и изображения. Эта работа нередко занимает больше времени, чем настройка самого каталога на сайте
Если учётная или другая внешняя система меняет формат обмена, подрядчик должен проверить результат на стороне интернет-магазина: корректность цен и остатков, передачу заказов и обновление их статусов
Мы рекомендуем не просить студию «сделать дешевле» без изменения состава первого запуска. Полезнее определить, какие функции можно отложить, а какие нельзя исключить без риска для продаж и обслуживания клиентов
Готовое решение или индивидуальная разработка
Готовое решение подходит, если процессы магазина близки к типовым и компания готова использовать его логику без глубокой перестройки. Индивидуальная разработка оправдана, когда магазин должен поддерживать важный для бизнеса сценарий: нестандартный подбор товара, сложные условия цен, роли пользователей, правила заказа или обмена данными
|
Критерий |
Готовое решение |
Индивидуальная разработка |
|---|---|---|
|
Старт |
Быстрее при типовом каталоге и заказе |
Требует этапа проектирования |
|
Первоначальный объём |
Обычно меньше |
Обычно больше из-за проработки логики |
|
Ограничения |
Нужно учитывать архитектуру решения |
Можно заложить нужные правила в основу проекта |
|
Изменения |
Глубокая адаптация может стать сложной |
Развитие зависит от качества архитектуры и документации |
|
Когда выбирать |
Бизнес готов следовать готовому сценарию |
Сайт должен адаптироваться к процессам компании |
Шаблон не всегда дешевле в конечном счёте. Если студия вынуждена глубоко переделывать каталог, личный кабинет и процесс заказа, преимущества готового решения могут исчезнуть. Поэтому сначала стоит сопоставить требования магазина с возможностями выбранного решения, а не выбирать его только по скорости старта. Подробнее – в статье Почему крупные компании выбирают 1С-Битрикс?
Как проверить техническую компетенцию подрядчика
Техническая компетенция проявляется в предметных вопросах и понятном плане проверки, а не в перечне технологий на презентации. Студия должна объяснить, как она будет работать с текущими данными, связанными системами и критичными сценариями магазина
На первой встрече полезно спросить:
-
как команда выясняет источник товаров, цен и остатков
-
где будут проверяться изменения перед публикацией
-
как контролируется передача заказа после оформления
-
что происходит, если внешняя система временно недоступна
-
как проверяются оплата, доставка и уведомления
-
какие материалы и доступы получит заказчик после запуска
Содержательный ответ не сводится к обещанию «мы всё протестируем». Команда должна назвать конкретные действия: создать заказ, оплатить его доступным способом, проверить передачу данных, убедиться в корректном статусе и обработать нештатную ситуацию
Пример из практики Ameton: при обсуждении интернет-магазина с персональными ценами по изначальным вводным данным предполагалось, что достаточно показывать их пользователю после авторизации. В ходе разбора выяснилось, что условия зависят от договора, юридического лица и актуальности данных из учётной системы. Команда выделила правила получения цены и обработку ошибок обмена как отдельную часть проекта. Без этого магазин мог бы внешне работать, но показывать клиентам неверные условия покупки
Как оценить подход студии к запуску и развитию
Надёжная студия думает не только о первом релизе, но и о том, как магазин будет меняться после него. Новый способ доставки, изменение структуры каталога или подключение программы лояльности могут затронуть уже работающие сценарии
Если проект регулярно развивается, подрядчик должен предложить порядок постановки задач, оценки изменений, проверки результата и фиксации важных решений. Если магазин связан с оплатой, заказами и внешними системами, изменения стоит проверять до публикации на рабочем сайте, потому что ошибка может проявиться не на странице, а после действия покупателя
Для таких проектов команда обычно фиксирует критичные сценарии ещё до запуска: оформление заказа, передача данных, обработка оплаты, обновление статусов и работа личного кабинета. Этот список помогает безопасно выпускать изменения и отличать новое развитие магазина от исправления уже согласованной функции
Какие материалы должны остаться у заказчика
Заказчик должен получить контроль над магазином и материалами, необходимыми для его дальнейшей работы. Передача не ограничивается паролем от административной части сайта
До завершения проекта стоит согласовать:
-
доступы к домену, хостингу, сайту и репозиторию исходного кода
-
права и порядок использования дизайна, кода и других материалов
-
сведения о лицензии 1С-Битрикс, платных модулях и внешних сервисах
-
описание нестандартных доработок и интеграций
-
перечень критичных сценариев и известных ограничений
-
порядок резервного копирования и восстановления, если он входит в проект
-
список открытых задач, если часть развития переносится на следующий этап
Студия может организовать покупку лицензии 1С-Битрикс или включить её в смету. При этом лицензию необходимо регистрировать на компанию-заказчика как на конечного пользователя, а порядок оплаты и продления закрепить в договоре
Выбор подрядчика для интернет-магазина определяет не только первый запуск, но и стоимость последующих изменений. Стоит выбирать команду, которая понимает путь заказа, заранее обозначает границы работ и умеет проверять результат там, где он важен для бизнеса: в данных, оплатах, доставке и работе сотрудников
Ameton может начать с разбора будущего магазина или действующего сайта: уточнить критичные сценарии, состав интеграций и функции первого запуска. Это помогает подготовить сравнимые предложения и выбрать формат разработки без случайных обязательств