Запустить интернет-магазин за 1 млн рублей: подводные камни, опыт и нюансы

Наша цель — не рассказать как создается интернет-магазин, а показать, что отличает качественную разработку от типового подхода. Что именно находится под капотом создания e-commerce продукта верхнего ценового сегмента.

Последние шесть лет мы разрабатываем e-commerce продукты. Пора поделиться опытом с предпринимателями и digital-специалистами.

• почему устное проговаривание функционала и структуры работает в разы эффективнее брифа;
• моменты, которые могут стать критическими;
• про распространенный формат, так называемые доработки по сайту;
• каким должно быть ТЗ;
• про подбор технологий, выбор CMS и возможные интеграции;
• наши детальные решения с интеграциями;
• первичное тестирование до показа и сдачи проекта.

Это фундамент, на основе которого будет построена вся дальнейшая разработка. Этап брифинга позволяет запланировать структуру, дизайн и функционал интернет-магазина.

Если привести пример, то выглядеть это может так. Заказчик приходит с запросом: «Хочу интернет-магазин на Bitrix вот с таким функционалом и дизайном». Скорее всего он изучил разные CMS и выбрал одну из них, руководствуясь своими интересами. В нашей практике мы работали и с запросами «Что угодно, только не битрикс» или «Нужна исключительно индивидуальная разработка».

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

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

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

Что обязательно спрашиваем

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

• Какая номенклатура товаров. Вопрос касается наполнения, и сколько часов оно займет. Помимо этого от объема товара зависит общая нагрузка сайта и сложность фильтрации. На 100 товаров не нужно 20 фильтров. И наоборот, на 200 тыс. товаров недостаточно двух фильтров;

• Какое количество категорий товара. Узнаём насколько будет сложно проработать интернет-магазин. Продумать сайт, где одна категория товара явно проще, чем учитывать целый магазин бытовой техники;

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

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

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

• Какая бонусная система: нет, есть, какая;

• Интеграции с учетными системами: 1С, Мой склад и подобное. Узнаём есть ли в них какая-то специфика.

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

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

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

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

Распространенный формат обращений по интернет-магазинам — проведение доработок по сайту. Заранее избежать проблем в таких случаях нереально. Например, у заказчика есть только frontend-разработчик. Некому произвести настройку CMS системы или программирование серверной части сайта. У кого-то есть только дизайнеры и нет ресурсов на разработку.

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

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

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

Что должно быть в техническом задании на разработку интернет-магазина:

• документы со структурой каталога товаров
• подробное описание каждого дополнительного функционала

Четко сформулированное техническое задание позволяет на этапе обсуждения избежать 99% потенциальных технических ошибок. Но далеко не у каждого заказчика есть ресурс составлять ТЗ самостоятельно и это нормально. Поэтому совместным составлением ТЗ занимаются на первом этапе разработки. На технический анализ подключаются техлиды. Изучаем какие возможности и ограничения имеются для реализации. Подходит ли выбранная заказчиком CMS для функционала, который планируется внедрить.

Агентское решение

В основном в ASAP для интернет-магазинов используем 1С-Битрикс или работаем на фреймворках. Например, сайт с 20 000 позициями можно сделать на Битрикс, ModX или готовом конструкторе. Но реализация на каждой потребует разные расходы временных и финансовых ресурсов. Плюс учитывать ограничения платформ.

Случаи, в которых мы советуем использовать технологии и платформы:

• Вариант первый. Решение на 1С-Битрикс подойдет в случае разработки стабильного, понятного и долгосрочного проекта, нуждающегося в интеграциях с 1С. С каталогом на десятки и сотни тысяч позиций и интеграциями с внешними сервисами. Личным кабинетом и адаптацией под различные разрешения. SEO-оптимизацией, оформлением оплаты, возврата и доставки заказа. Это надежное коробочное решение для интернет-магазина, в том числе при создания уникального дизайна. Разработанные интернет-магазины на 1C-Битрикс с индивидуальным дизайном koico. ru, mebelkmv. ru, stroy-s. org.

• Вариант второй. Разработка на фреймворках ReactJS, VueJS с индивидуальным дизайном. Позволяет реализовать любое кастомное решение. Разрабатывать проект заточенный под определенные задачи: нестандартный функционал, уникальную визуализацию, моушн-дизайн. Подойдет для интернет-магазинов со специфическими товарами и нестандартными системами измерения.
• Вариант третий. Битрикс + фреймворк. Здесь есть свои плюсы. Основное преимущество — скорость реакции на действия пользователя и скорость перехода по страницам. Можно использовать React точечно: в личном кабинете, пошаговом оформлении заказа, прочих страницах, которые не нужны для SEO. Вариант использования Битрикс + фреймворк подойдет тем, кому нужна seo-оптимизация и скорость. Пример такого интернет-магазина evanty. ru.
  

Другие решения, которые можно рассматривать

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

• Интернет-магазин на платформе Tilda. Вариант для тех, кому не нужна интеграция с 1С и в ассортименте не более 500 товаров. При наличии детальных карточек товаров установлен лимит страниц — в одном проекте не более 500. Платформа позволяет создать индивидуальный дизайн сайта, но имеет ограничения по дизайну карточек товаров и функционалу для обширного каталога. Интернет-магазин на Tilda — хороший способ для быстрого запуска, так как основной срок в целом будет определяться количеством контента и скоростью его размещения.
  

Минимальный стандартный функционал, который входит в разработку интернет-магазина: каталог товаров, корзина, оплата.

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

Мы интегрировали:

• Сайт и 1C
• Сайт и CRM
• Сайт, 1C и CRM
• Сайт и бонусная система UDS

Стоимость и время интеграции могут отличаться в зависимости от CMS. В одной системе они составят 30 часов, а в другой 130. Поэтому список интеграций формируется, просчитывается по времени и стоимости еще до старта разработки.

Интеграции со сторонними сервисами позволяют решать задачи:

• Оформления заказа, оплаты и доставки
• Поддержания актуальной информации о наличии, ценах и характеристиках товаров
• Сбора информации по клиентам: адреса доставки, личных данных, истории покупок, данных банковских карт
• Применения программ лояльности
• Сбора и обновления данных воронки продаж
• Коммуникации с клиентами

Для этого могут понадобиться сервисы и программы:

• Системы складского учета: 1С: Торговля и Склад, МойСклад
• Бонусные программы: UDS
• CRM-сервисы: Битрикс24, amoCRM
• Системы эквайринга
• Бухгалтерия: Моё дело, 1С:Бухгалтерия
• Курьерские службы: СДЭК, Boxberry
• Кредиты онлайн: Тинькофф, Покупай со сбером
• Сервисы онлайн-чатов
• Сервисы обратного звонка
• СМС и Email-рассылки: TargetSMS и UniSender
• Интеграция с маркетплейсом: Яндекс.Маркет, Wildberries
• Агрегаторы отзывов: Яндекс.Маркет, Mneniya
• Веб-аналитика: ROIStat, Convead, Call-tracking, Яндекс.Метрика
  

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

Функционал складского учета

Реализовали кастомный складской учет фермерских продуктов питания в интернет-магазине Ko&Co. Задача — сделать расчет поставок фермерских продуктов с учетом срока годности. В системах учета «МойСклад» и «1С» такого функционала не предусмотрено. Мы нашли решение — написать с нуля кастомный складской учет на стороне сайта.

Опишем доработку поэтапно:

• Создали сущности товаров и поставщиков. Чтобы их можно было учитывать, и они могли привязываться.
• Сделали возможным добавление свойств: дата производства, дата поставки, срок годности, прямой привязки к поставщику.
• При этом сделали возможным, чтобы одно наименование товара могло быть привязано к разным поставщикам. Например, пользователь на сайте видит один вид фермерского молока. В базе данных это молоко может быть от трех разных поставщиков. Покупая товар, система учета отображает привязку к определенному поставщику.
• Мы задали формулу, по которой производится ежедневный расчет срока годности. Она учитывает дату изготовления, срок годности и количество прошедших дней.
• Когда срок приближается к списанию, начинает формироваться поставка.

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

Решение с возвратом средств

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

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

Трехсторонняя интеграция: сайта, 1C и CRM-системы Битрикс24

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

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

Доработки интеграции по API

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

Так мы сделали для проекта Fitness Кухня. Случай сайта на MODX и сервиса обработки транзакций. Заказчик — партнер дисконтной программы UDS. Её клиенты могут зарабатывать бонусы, заказывая здоровое питание. Затем тратить накопленные баллы на покупки в Fitness Кухне. Начали привязывать приложение UDS. Но из-за того, что товар продавался не просто поштучно, а со сложными дополнительными данными (пол, возраст, вес, калорийность) UDS неправильно получал эти данные.

В заказе на доставку питания изначально число персон приложением UDS воспринималось как количество отдельных заказов. Например, заказ на 10 000 рублей на трех лиц стандартным модулем рассчитывался, как три отдельных заказа по 10 000 рублей каждый. Соответственно по заказу начислялось в три раза больше бонусных баллов, как с трех разных заказов.

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

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

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

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

Просмотр на баги является частью приемки со стороны заказчика. Всю основную работу по тестированию проводим мы. Но заказчик в любом случае изучает свой продукт и просматривает его. Например, при тестировании интернет-магазина мебельной фабрики столкнулись с багами в Safari. При добавлении товара в корзину, она вела себя абсолютно неадекватно. Могла накидывать вместо одного товара, сразу 10. При этом в Chrome всё было хорошо.

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