Как выбрать подрядчика для разработки интернет-магазина

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

Портфолио показывает результат, но не ход работы

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

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

Дайте команде один заказ

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

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

Неизвестное должно получить способ проверки

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

Вопрос: как сайт получает актуальный остаток товара при оформлении покупки? Кто приносит данные: ответственный IT-специалист или руководитель склада. Как проверяем: изучаем техническое описание системы учета и проверяем тестовый файл с остатками. Что считаем ответом: подтверждение, что система передает точное количество предметов по каждому артикулу.

Такая проверка строится на доступном источнике данных, документации или ответе ответственного сотрудника компании. Например, руководитель склада подтверждает структуру передачи сведений или IT-специалист предоставляет спецификацию файла с остатками, после чего команда фиксирует конечное решение.

Что зафиксировать до начала разработки

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

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

На первую встречу с разработчиками стоит принести описание пути одного заказа, список используемых внешних сервисов и контакты сотрудников, отвечающих за учет товаров. Компания IDBI занимается разработкой с 2011 года и делает интернет-магазины на 1С-Битрикс и InSales. Этих вводных достаточно, чтобы спокойно оценить подход специалистов к проекту и обсудить разработку интернет-магазина без лишних догадок.