Как быстро запустить интернет-магазин?

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

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

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

Нам нужно определить некий стартовый набор функционала, достаточный для организации продаж и эффективного обслуживания клиентов. То есть MVP (Minimum Valuable Product или Минимально жизнеспособный продукт) вашего интернет-магазина.

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

Еще один важный момент — какой магазин считать маленьким, а какой — средним?

В этой статье будем считать, что:

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

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

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

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

И на нашем этапе запуска не лишним будет вспомнить, что главная цель магазина — это продавать.

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

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

Основной принцип внедрения функционала, который изложен в таблице:

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

Классическая методика разработки подразумевает, что вы пишете максимально тщательное техническое задание со всеми мельчайшими подробностями. Затем отдаете его разработчику — разработчик оценивает и разрабатывает. Можно долго описывать процесс планирования разработки — разумеется, используются различные методики типа «Метод критического пути» или Waterfall, строятся диаграммы Ганта или процессные диаграммы... Мы сейчас не о деталях, а о принципах разработки.

Так вот, если о принципах — то часто возникают следующие сложности:

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

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

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

Lean-метод гибкой разработки (и, в частности, его разновидность Agile) может помочь вам оптимизировать процесс. В случае с маленьким магазином вы можете изначально договориться с разработчиком о том, что:

• у вас есть определенный бюджет на разработку, в который нужно уложиться;

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

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

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

Agile подразумевает, что вы «держите руку на пульсе» проекта. Планирование позволяет разбить проект на небольшие кусочки, которые можно принимать в процессе разработки по частям — например, отдельно карточку товара или отдельно новости. Можно объединять эти кусочки-задачи в более продолжительные спринты, но это не обязательно. Гораздо важнее, чтобы разработчики представляли вам готовый результат по каждой мелкой задаче в согласованные сроки.

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

Сейчас мы подходим к торжественному моменту — определению разницы между техническими и организационными решениями. Но сначала экспресс-вопрос: что лучше — выбрать самую быструю систему управления сайтом (CMS) или самую популярную?

• Техническое решение: самую быструю.
• Организационное решение: самую популярную.

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

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

1. Какова стоимость лицензии и стоимость разработки?
2. Насколько сложно найти персонал для поддержки и обслуживания выбранного решения?
3. Насколько дорого обслуживание?
4. Как скоро можно внедрить систему в эксплуатацию?
5. Какой функционал система включает в себя?
6. Просто или сложно в случае необходимости подключать новые модули, есть ли готовые решения?
7. Учитывает ли выбранное решение требования законодательства?

Ответы на все эти вопросы позволяют принять оптимальное решение для нашего конкретного бизнеса.

Юлия Виноградова, r52.ru:

Экономичный и быстрый способ создать интернет-магазин — применить готовое коробочное решение, плюс готовый шаблон дизайна на базе известных CMS типа 1C-Bitrix, OpenCart и т.д. Такой шаг позволяет сразу реализовать примерно 80% существующего в природе функционала и запуститься в минимальные сроки.

Имеет смысл эксплуатировать подобное решение в течение 6—8 месяцев. Это позволит владельцу понять, чего он ждет от своего сайта, каких функций не хватает посетителям, что нужно для нормальной интеграции с CRM-системой и т.д.

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

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

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

Алексей Шишкин, redsoft.ru:

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

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

Кроме того, в реальной жизни 50—80% функционала магазина используется малой долей клиентов (например, мы очень любим фильтры в сложных каталогах, но как показывает практика, далеко не все пользователи работают с фильтрами даже на большой выборке товаров). Поэтому все непопулярные фичи магазина можно выносить на этап развития, не задерживая ради них старт. Но для этого неплохо знать, какие функции реально востребованы для выбранного сегмента (товарная матрица + аудитория).  

Роман Горевой, eurosites.ru:

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

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

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

Артем Соколов, insales.ru:

• Заказная разработка. Нет необходимости тратить время и деньги, если нет четкого понимания бизнес-процессов и бизнеса в целом. Берем SaaS-решение и стартуем за несколько дней, в том числе с готовыми необходимыми интеграциями.
• Сложные механики (скидочные, ценооразования и т.д.) на сайте магазина на этапе старта однозначно не нужны, в них можно закопаться навечно, и их наличие не критично для начала.
• Прорисовка баннеров, игра со шрифтами, разработка «как Ламода, только лучше». Для старта лучше всего взять минималистичный адаптивный дизайн-шаблон и в дальнейшем дорабатывать по фидбэку от покупателей.

Илья Леонов, webasyst.ru:

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

Мурад Эфендиев, itsoft.ru:

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

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

Виктор Бондаренко, intaro.ru:

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

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

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

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