Успеть к сезону: как перезапустить интернет-магазин в 2 раза быстрее стандартных сроков

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

• Грамотно приоритизировать работу над компонентами;
• Уделить больше времени проектированию, чтобы сэкономить время на исправлениях;
• Не выкатывать весь функционал сразу, а вместо этого запустить MVP.

Эти три принципа и помогли нам все успеть. Расскажу о них подробнее.

Запуск MVP

Если долго запускать продукт, компания в ожидании релиза потеряет время и деньги, а ее клиент уйдет к конкурентам. В случае с «Аквилоном» еще и было важно запустить новый сайт быстрее, чтобы маркетологи начали привлекать трафик заранее. Но ценность MVP не только в сокращении time-to-market.

Мы ведь делаем продукт для тех, кто будет покупать у бизнеса. Фидбек от проблемных интервью не сравнить с тестированием продукта на реальной аудитории.

Запуск MVP позволяет:

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

MVP не только сократил объем работ, чтобы мы вписались в дедлайн, но и стал еще одним источником данных для приоритизации и планирования разработки.

Приоритизация

У нас уже был ориентир для простановки приоритетов — MVP. В первом релизе мы ограничиваемся функционалом, без которого невозможно воспользоваться интернет-магазином — каталог и оформление заказа. Но нужно учитывать, что:

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

Еще одним ориентиром для приоритизации стали результаты Customer Development. Об этой методологии часто говорят в контексте стартапов и тестирования новых идей. Но крупным компаниям кастдев тоже полезен.

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

• Быстрая загрузка страниц;
• Понятная структура каталога;
• Удобный поиск;
• Мобильная версия.

Бэклог позволил нам поэтапно распланировать работу над фичами.

Проектирование

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

В работе ориентировались на подход DDD — Domain-Driven Design. Суть подхода в том, что команда разработки учитывает «домен» — сферу бизнеса, для которой она делает приложение.

В рамках DDD клиент постоянно в контакте с командой и дает ей экспертизу в своей сфере. А мы «переводим» бизнес-требования на «язык» разработчиков. Рассмотрим пример влияния DDD на выбор технических решений.

Как работает DDD

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

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

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

А теперь представьте, что все товары от штукатурок до дрелей внесены в одну огромную таблицу Excel с тысячами пустых ячеек. Реляционные базы, в том числе, на «Битриксе» работают именно так. Из-за такой структуры данных:

• Сайт медленно грузится.
• Нет поиска по фильтрам — пользователь прочесывает каталог вручную и устает.

Поиск и сложные фильтры поисковой выдачи — это важный элемент хорошего UX строительного интернет-магазина. Поэтому нужен был каталог с нечеткой структурой. Мы использовали документоориентированную СУБД — MongoDB. В таких базах данных можно хранить только нужную информацию по каждому товару без длинного списка категорий с пустыми значениями.

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

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

Как мы (почти) победили 1С

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

Компания хранила информацию о заказах и товарах в 1С. Мы договорились, что будем использовать 1С как мастер-систему. Это «истина в последней инстанции» — база, данные из которой считаются правильными для других систем, например, сайта.

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

Допустим, пользователь оформил заказ. Сайт отправляет информацию о заказе в 1С, а она недоступна. Чтобы данные не потерялись и сайт продолжил работать, мы внедрили менеджер очередей RabbitMQ. Это «зал ожидания» для данных. Пока 1С лежит, информация о заказе хранится в RabbitMQ — и отправляется в мастер-систему после ее восстановления.

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

Но даже несмотря на RabbitMQ, к весне из-за 1С по-прежнему не работали важные интеграции по программе лояльности. Нам было важнее запустить новый сайт с минимально необходимым функционалом и собрать фидбек с пользователей. Поэтому мы уложились в срок, но в первой версии все разделы с бонусной программой были скрыты.

Читайте также: Как совмещать несколько бизнесов — советы серийного предпринимателя

Результат

Новый сайт работает уже больше года, сейчас второй сезон. В сентябре 2022 его посещаемость составила 200 тысяч уникальных пользователей ― это на 202% больше, чем годом ранее.

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

Как получить максимум

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

Вот что способно помочь:

1. Урежьте функционал. Запустите MVP с базовыми фичами, которых достаточно, чтобы пользователь достиг главной цели. Даже если в ходе разработки что-то внезапно пошло не так, не забывайте о том, что в приоритете именно база. Мы поначалу запустились без бонусной программы, но от этого ничего плохого не случилось.
2. Проектируйте. Если приступить к кодингу сразу, вы не только не сократите time-to-market, но и напишете лишнего и потратите больше времени и денег на исправление. Применяйте подход DDD — слушайте экспертов из сферы и внимательно уточняйте бизнес-требования. Так вы избежите дорогих ошибок еще на этапе дизайна.
3. Расставляйте приоритеты. Помимо нужных для MVP фичей, хороший источник информации для приоритизации — сами пользователи. Проведите опрос, чтобы узнать, что им нужнее.

Фото на обложке: Unsplash

Иллюстрация предоставлена автором