Как мы разработали маркетплейс за 3 месяца

Клиент

ИНТЕРВОЛГА несколько раз делала совместные проекты с компанией ЕВРАЗ. Начали с Enterprise-проекта — ЛК клиентов , затем личный кабинет для ЕВРАЗ Металл Инпром , сайт ванадиевых активов и каталог металлопроката (и еще один проект находится сейчас в разработке). 

На старт!

В марте 2020 года нам предложили взяться за новый проект, необычный для ЕВРАЗа: разработать внутренний маркетплейс для сотрудников компании для заказа ТМЦ (товарно-материальных ценностей: канцтоваров, инструментов, офисной мебели, освещения и т.п.). Любой сотрудник смог бы оформить заказ на дрель или шлифовальный круг (в рамках бюджета на свой цех), проследить статус и получить в ближайшем складе на территории цеха. При этом сайт — только один кусочек пазла, за ним кроются серьезные управленческие решения.

ЕВРАЗ поставил перед собой непростую задачу. Раньше, если инструмент или прибор ломался, заявка сотрудника на закупку выполнялась неделями. Нужно было уменьшить этот срок до 48 часов. Все согласования внутри ЕВРАЗа планировалось сделать на сайте и автоматически отправлять заявки поставщикам.

Для осуществления проекта нужно было изменить некоторые устоявшиеся бизнес-процессы компании, доработать систему SAP, договориться с поставщиками ТМЦ — и весь этот амбициозный проект нужно было завершить всего за 3 месяца — срок был высечен в камне и сдвинуть его было невозможно. Нам предстояло работать в составе большой команды, возглавить разработку веб-сайта и решать все смежные вопросы.

Поначалу речь шла о переработке одного из текущих сайтов на платформе «1С-Битрикс: Управление сайтом» в маркетплейс с минимальным изменением дизайна. Но после первой же дизайн-сессии было решено: нужен свой современный, уникальный вид, который был бы дружелюбен к целевой аудитории и не вызывал бы у нее вопросов. Адаптив? Разумеется. А интерфейс нужно тестировать на реальных пользователях, проводя полноценные UX-исследования.

Звучит нереально? Скажете, что тут 3 месяца только на проектирование нужно? Что ж, для классической модели разработки это действительно задача нерешаемая. Тут поможет только Он

Внимание!

Мы уже работали в нескольких проектах по методологии Scrum, и писали об этом (например, Клуб клиентов Альфа-Банка ). Поэтому напомним только основные моменты:

  • Работа разбита на небольшие промежутки времени: спринты (в нашем случае — по 2 недели)

  • Каждый день 20-минутные стендап-планерки. У кого какие проблемы, кто что будет сегодня делать

  • В конце спринта — неизбежный релиз с законченными новыми функциями. В нашем случае еще и с онлайн-демонстрацией 150-ти сотрудникам ЕВРАЗа, в том числе и руководству.

  • Ретроспективы после окончания спринта.

По сути, это услуга аренды проектной команды . 1С полностью на себя взял другой подрядчик ЕВРАЗа, так что мы сосредоточились только на сайте. Несколько разработчиков (back и front) в течение нескольких месяцев занимались 100% только одним проектом. Аналитик, QA и дизайнер подключались по мере надобности. 

Scrum не означает, что в первый же день проекта разработчики хватают задачи и разбегаются писать код. Хочется процитировать Тома ДеМарко, автора замечательной книги «Deadline. Роман об управлении проектами».
«Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую‑то работу).»
«Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.  
Проектирование нужно, и Scrum его не исключает (распространенное заблуждение противников методологии). Мы провели «нулевой» спринт, и совместно с ЕВРАЗом и подрядчиком по 1С разработали базовые принципы проекта:
  • 1С — «бэк»:

    • взаимодействует с учетными системами поставщиков,

    • сопоставляет товары, статусы заказов от разных поставщиков в единый каталог.

  • Сайт — «фронт»:

    • взаимодействует только с сервисом авторизации ЕВРАЗа и 1С,

    • выводит чистые данные клиенту,

    • красивый и удобный,

    • взаимодействует с конечными пользователями.

Таким образом, мы определили для каждого участника его зону ответственности. Вопросы интеграции (подрядчики vs 1С) и (1С vs сайт) решались совместно. Подробнее об архитектуре подобных тяжелых проектов мы писали в статье Архитектура веб-проекта для тяжелых вычислений .

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

Марш!

Всего у нас было 6 спринтов с 20.04 по 03.07. Работы и итоги спринтов кратко приведены в таблице ниже (подробнее рассказать не можем).

Первые 2 спринта над дизайном работал другой подрядчик, с третьего эстафета перешла к ИНТЕРВОЛГЕ.


Дизайн

Фронтенд-задачи

Бекенд-задачи

Значимый результат

Спринт 1

20.04 - 30.04

Приветственный экран

Главная

Список товаров

Детальная товара

Приветственный экран

Шаблон сайта

Главная

В старой верстке:

  • Отзывы к товарам

  • Карточка товара

  • Рейтинг товаров

  • Поиск на сайте

В 1С ведется импорт товаров 1 поставщика. На сайте собрана логика для конверсионного пути в старой верстке

Спринт 2

06.05 - 08.05

Корзина

Список товаров

Применение верстки приветственного экрана

Применение верстки главной

В 1С и на сайте заведены справочники реальных пользователей

Спринт 3

12.05 - 22.05

Оформление заказа

Регистрация

Список разделов

Сравнение

UX-исследование основного пути заявителя (витрина-корзина-заявка)

Список товаров

Детальная товара

Регистрация

Корзина

Авторизация (интеграция с сервисом ЕВРАЗа)

Разбивка заказа по поставщикам

Применение верстки авторизации

Применение верстки списка товаров и детальной товара

В 1С ведется импорт товаров еще 2-ух поставщиков. Основные разделы сайта в новом дизайне.

Спринт 4

25.05 - 5.06

Весь ЛК (5 подразделов)

Первые задачи по mobile

Оформление заказа

Список разделов

Сравнение

ЛК (3 раздела)

Применение верстки корзины и оформления заказа

Доработка обмена заказами с 1С

Доработка проверки прав

Прямая интеграция с одним поставщиком по срокам доставки

Пилотный запуск на 1 фабрике. Весь сайт выглядит согласно дизайну. Вся цепочка «заявка-заказ-доставка» работает.

Спринт 5

08.06 - 19.06

Завершение mobile версии

Правки

UX-исследование ЛК приемщика

ЛК (2 раздела)

Mobile

Правки

Завершение применения верстки

Запуск еще на трех цехах

Спринт 6

22.06 - 03.07

Правки

Mobile

Правки

Правки

Запуск проекта

Каждый спринт — маленький законченный проект. Начиная с 3-его спринты стали тематическими: были четко сформулированы две-три конкретных цели, которые нужно было достичь через 2 недели.

В этом проекте мы очень хорошо знали свою целевую аудиторию. Чтобы убедиться, что всем работникам будет комфортно на сайте, решили провести испытание боем. Разумеется, до окончательной реализации. Мы собрали интерактивный макет интерфейса в figma, назначили Zoom-конференции и позвали будущих пользователей маркетплейса. 

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

Конечно, без накладок не обошлось. У кого-то был Internet Explorer, в котором figma работает криво. Кто-то жаловался на низкую скорость подключения к сети — работали с сильными тормозами. Кстати, после исследования скорость человеку наладили :)

В итоге мы получили список конкретных проблем, а к следующему спринту уже были предложены решения.

Составляющие успеха

Завершив проект, мы поняли ключевые особенности хорошего scrum-проекта.

Атмосфера

Сказать, что сложилась хорошая команда — не сказать ничего. За эти месяцы мы свернули немало гор с ЕВРАЗом и коллегами по 1С. Мы нашли общий язык, научились понимать друг друга с полуслова и выручать, когда у кого-то проблемы. На планерках и ретроспективах нередко звучал смех, а после очередного рабочего дня все возвращались домой довольные.

Тесный контакт всех со всеми. Заказчик — часть команды

Быстрые проекты нельзя делать в режиме «ну вы напишите ТЗ, мы 1С-нику нашему передадим, он на следующей неделе ответит». У всех одна цель — запуск проекта в минимальные сроки — и грань между заказчиком и подрядчиками должна быть тонка, практически неосязаема. Коллеги со стороны ЕВРАЗа работали не меньше нашего и могли в любой момент закинуть в общий чат «SOS» и мы реагировали. Подрядчики по 1С могли запросто позвать нас на получасовой Zoom, чтобы помочь им разобраться с запутанным форматом CommerceML. И мы, в свою очередь, могли выдернуть кого угодно для решения острых вопросов. За все время мы ни разу не слышали типовых фраз «он в отпуске, давайте подождем 2 недели». Все вопросы решались сразу, без проволочек.

Разговор о проекте почти так же важен, как сама работа

Ежедневные планерки на 15 минут — это хорошо. Но у нас были дни, когда мы созванивались с заказчиком по 4 раза в день по разным вопросам. Это мог быть короткий разговор 1 на 1 или двухчасовое обсуждение новой интеграции на 10 человек. 

Поначалу казалось, что это чересчур. Времени и так мало, лучше сесть и писать код/рисовать макеты. Но на то были свои причины.

  1. Проект менялся почти каждый день и достаточно сильно. Без таких планерок «все на всех» конечные исполнители рисковали выпасть из контекста. Понимать, чем заняты коллеги «по ту сторону XML-файлов обмена» очень важно для всей команды. За время проекта у всех участников со стороны ИНТЕРВОЛГИ произошло неплохое погружение в 1С (и даже дизайнера не пожалели).

  2. Такими созвонами мы обсуждали самые острые архитектурные нюансы, старались принять такие решения, чтобы никого не обидеть и не перекосить проект в одну сторону. Кто будет отправлять Email’ы: сайт или 1С? А интерфейс согласующего на чьей будет стороне? Отчеты?

Никого лишнего в команде

Бывают такие проекты, в которых некоторые люди со стороны заказчика будто специально вставляют палки в колеса. Такие люди — «давайте все сделаем обстоятельно, “по гамбургскому счету”, чтобы было не стыдно показать конкурентам» — очень полезны в классической разработке, когда нужно составить проработанный план и не двигаться с места, пока совет директоров не вчитается в каждую букву. Но только не в проектах, где важна скорость. Тут не было ни таких людей, ни таких стопоров. Если через 2 недели нужно показать прототип — каждый делал все, чтобы сделать обещанную функцию возможной. 

Конечно, высокий темп приводил иногда к проблемам. То за день до демонстрации отвалится приемка заказов, то страница авторизации развалится на второй день после пилотного запуска. Без этого никуда. Все проблемы старались быстро локализовать и устранить. Но все равно ошибок было гораздо меньше, чем все боялись в начале. Что-то было в этом проекте, что уберегло его от самых больших рисков. Кто-то скажет: профессионализм и синергия всей команды. А может быть, дело в том, что каждый участник проекта искренне и всей душой болел за успех проекта.

Инструменты

В этом проекте мы отступили от привычных нам Skype и Youtrack и дружно освоили Microsoft Teams, Zoom и Trello. Хотя совсем отказаться от YouTrack не смогли, сделали на коленке инструмент интеграции Trello и YouTrack.

Со временем Trello стал явно тесноват, но его механизм досок и карточек очаровал каждого с первого взгляда, так что от него так и не смогли отказаться.

Выводы

Карантин — не приговор

Первый спринт начался уже в эпоху весеннего карантина. Мы с ЕВРАЗом и другими подрядчиками находились в разных городах, к этому нам не привыкать. С невозможностью пообщаться командой боролись постоянными переписками и созвонами. И все получилось! Карантин, на наше счастье, не оказал никакого пагубного эффекта на производительность. 

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

Scrum существует

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

UX-исследования работают

Как понять, что дизайн хороший, что все будет понятно посетителю без чтения инструкций? Ветераны IT-отрасли (речь и про контактеров со стороны заказчик ЕВРАЗа, и про первого подрядчика по дизайну, и про ИНТЕРВОЛГУ) знают теорию и могут достаточно быстро предложить грамотный дизайн. А дальше предложенное решение желательно проверить на реальных посетителях.

Фрагмент из протокола UX-исследования

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

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

Курица или яйцо? Работа с нуля или легаси?

Мы начали работу, «пересобирая» один из сайтов ЕВРАЗа в маркетплейс, вместо того, чтобы начать работу с «пустого» Битрикса. Было ли это ошибкой или правильным решением? 

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

Результат

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

Что получил заказчик? ЕВРАЗ запустил маркетплейс ТМЦ для Западно-Сибирского металлургического комбината (пятый по величине металлургический комбинат в России). За первый месяц работы маркетплейса 200 заказов уже приехали к своим заявителям. В настоящий момент ЕВРАЗ принял решение развивать проект и тиражировать его на другие предприятия — а это значит, что нам предстоит решить еще множество нетиповых задач.


Оцените статью: