Приложение для сотрудников магазинов Детского мира
В Детском мире много внутренних цифровых сервисов.
Год назад мы решили активнее развивать одно из этих направлений и начали собирать внутреннюю команду проектов B2E (Business-to-Employee). Первым проектом для неё стала разработка нового мобильного приложения для сотрудников магазинов.
Подготовка к проекту
Для чего сотрудникам магазинов приложение? Сотрудники в магазине выполняют много разнообразных задач. Например, менеджер интернет-заказов собирает с полок товары, заказанные онлайн, консультирует по наличию, проверяет ценники в торговом зале, помогает найти заказ в зоне выдачи, уточняет информацию о наличии товара.
С большинством задач помогает компьютер с системой SAP, который стоит в торговом зале. Для загруженных магазинов с большим потоком покупателей и онлайн-заказов такой единственный компьютер в зале становится узким горлышком. Во-первых, у него собирается очередь из сотрудников, во-вторых, неудобно бегать через весь зал к терминалу, чтобы что-то уточнить.
В качестве эксперимента в 2019 году в Детском мире запустили проект «Мобильный кокпит», в рамках которого часть функций из SAP стала доступна в первом мобильном приложении для сотрудников магазинов.
Изначально приложением занимался один разработчик. Он делал фронт и бэк, разбирался в магазинных процессах. Это была классическая мультиплатформа на React-нейтиве.
Эксперимент удался, сотрудники оценили преимущества мобильности. На горизонте возникли разные внутренние департаменты, которые хотели добавить в приложение свои фичи. И исследования в магазинах указывали на необходимость оптимизации процессов — чтобы ускорить работу сотрудников, сократить очереди и снизить долю ошибок: словом повысить NPS. Приложение требовало масштабирования и более широкой интерграции с процессами компании.
Так начала формироваться отдельная команда внутри компании.
«Иконка — артефакт, который нужен сразу к первому релизу. Мы решили опереться на стиль Детского мира: всё же продукт наш. Перебрали арки, которые оформляют каждый вход в магазин, пробовали метафору заказа в виде упаковки, здание, похожее на склад, и другое. Вместе с артдиром и командой выбрали традиционный домик, олицетворяющий магазин в нашей графической системе»
Развивать старое приложение или делать новое?
К моменту формирования отдельной команды имеющееся приложение для сотрудников уже обладало достаточно богатым набором функций. И оно работало! Но мы решили, что от него надо отказываться в пользу создания нового.
- Во-первых, разработчик первого приложения больше не работал в Детском мире. Изучить, понять, дополнить и не сломать чужой код сложно.
- Во-вторых, мы планировали сделать приложение ещё функциональнее. Для этого нам нужна была стабильная обновляемая платформа, доступная для большинства разработчиков. Мы решили перейти с React-нейтива на классическую Android- и iOS-разработку.
- В-третьих, в Детском мире к тому моменту уже сформировался большой IT-департамент с разработчиками, QA и дизайнерами с большим опытом в Android- и iOS-платформах.
- В-четвёртых, в отличие от старого приложения, новое мы хотели распространять не по ссылке, а через App Store и Google Play.
Цели для продуктовой команды
Перед будущей командой внутренних цифровых продуктов поставили три цели:
- Сделать новое приложение таким же функциональным, как старое.
- Улучшить его функции с помощью UX-исследований в магазинах, обратной связи от сотрудников и аналитики.
- Создать гибкую платформу для будущего масштабирования, чтобы можно было с меньшими затратами реализовывать нужды департаментов.
Поиск команды разработки
Нам согласовали минимально необходимую команду из 8 человек:
- продакт-менеджер,
- проджект-менеджер,
- UX-исследователь,
- UX/UI-дизайнер,
- iOS-разработчик,
- Android-разработчик,
- бэкенд-разработчик,
- QA-инженер.
«Долго искали UX-исследователя. В начале привлекали на эту роль специалистов из других команд Детского мира. Им приходилось ездить по магазинам, общаться с сотрудниками и директорами, и это отдельная интересная история. Напишите в комментариях, если хотите её услышать» 😀
Проект стартовал с неполным составом. Команду собрали частично из внутренних сотрудников 🔗Дм-теха — IT подразделения Детского мира, а частично наняли. Сначала были только проджект, продакт и бэкендер.
На позицию QA-инженера переучили человека из техподдержки Детского мира. Она понимала все нюансы работы сотрудников магазинов с покупателями, что оказалось очень полезным.
Поиск стейкхолдеров внутри компании
Пока ребята завершали свои проекты и подтягивались в новую команду, продакт и бэкенд-разработчик начали разбираться в старом приложении.
Сразу попали в разработческий хаос, свойственный любой крупной компании. Был бэкенд старого приложения, бэкенд сайта Детского мира, бэкэнд SAP, где крутятся все процессы. Ребята встречались с разработчиками и продактами связанных команд, чтобы как-то во всём разобраться.
Параллельно продакт ходил по разным департаментам компании и общался со всеми, кого могло бы заинтересовать участие в приложении для сотрудников. Вскоре, эйчары, логистика, инвентаризация, склады и прочие отделы стали приходить сами, когда узнали, что под приложение формируется команда.
С «розницей» было проще всего: старое приложение работало и закрывало потребности сотрудников в магазинах. Во всех остальных департаментах были совершенно разные пожелания. И нам было важно понять, кому чего не хватает, какие процессы за этим стоят, какие есть проблемы, как упаковывать всё в юзер-стори.
«Например, сегодня обсуждали со „складами“ приложение для их сотрудников, в котором им детализируют зарплату. У них там зарплата сдельная, рассчитывается по сложным формулам. И сотрудники хотят видеть в любой момент времени, сколько они денег заработали и за что их оштрафовали».
В результате продакт составил импакт-мэп, где описал стейкхолдеров и чего они хотят. Так мы собрали идеи для бэклога развития.
Погружение в процессы розничных магазинов
Но начинать нам пришлось с бэклога первостепенных функций, которые нужно было перенести из старого приложения в новое и улучшить.
Раз в неделю мы ездили в магазины Детского мира и Зоозавра. Важно было самим понять, как они работают. Также было много встреч в офисе с представителями розницы, которые рассказывали о процессах в магазинах с точки зрения бизнеса.
Оказалось, что в эту сферу высокий порог входа, потому что в ней принята своя терминология, а отдельные процессы магазинов расходятся с представлением бизнеса. Также не всегда можно найти человека который знает важные детали, сложно находить документацию и приходится много исследовать.
«Вдруг узнаёшь, что в рознице есть „самовывоз“. А ещё есть „инстор“. В обоих случаях покупатель сам забирает заказ в магазине. Но в первом мы везём товары в магазин со склада, а во втором менеджер собирает их с полок в магазине. И сидя в офисе, нужно понять связанные с этим процессы в магазинах: чем „самовывоз“ отличается от „инстора“, доли „инстора“ и „самовывоза“ и то, как всё это влияет на бизнес.
В какой-то момент думаешь: «Ага, я все понял, мне рассказали, как работает самовывоз, мы сделаем его в новом приложении!»
А потом приезжаешь в магазин и понимаешь, что всё немного иначе. Сотрудники в магазинах делают не так, как описано в процессах и как тебе рассказывали на встрече в офисе. Сотрудники поступают по-своему, так как в магазине выработалась своя практика в силу неких ограничений: маленький склад, маленькая пропускная способность, мало посетителей, много «самовывоза».
Ты возвращаешься в офис и думаешь: «Ну теперь я точно понял, как надо оцифровать процесс самовывоза, есть пара гипотез, как это ускорить, класс!» А потом едешь в другой магазин сети, и там всё совсем по-другому!» 🤯
Основным источником информации для нас стали поездки по магазинам, общение с сотрудниками, работа вместе с ними, сбор и систематизация данных. Там же рождалось большое количество инсайтов. Мы приняли тот факт, что целиком полной информацией по работе в магазинах не обладает никто в офисе.
Если сотрудники «фродят»
Что делать, когда сотрудники обходят бизнес-процессы («фродят»)?
Сложно гарантировать единообразие процессов во всех магазинах сети. Магазины разные. Детских миров больше тысячи, они открыты в разных регионах и странах. Даже соседние магазины в Москве отличаются. В одном много покупателей из-за расположения рядом с метро, в другом мало. И у директоров разные подходы к управлению.
Сеть развивается и меняется. У нас нет цели прибить правила гвоздями и заставить сотрудников выполнять их во что бы то ни стало. Некоторые случаи «фрода», которым сотрудники пытаются обмануть систему, только на пользу. Далеко не каждая попытка обойти систему вредна. Но чтобы понять это, надо детально разбираться в каждом конкретном случае.
При сборке интернет-заказа сотрудник магазина видел в приложении номер телефона покупателя. Когда какой-то товар из заказа было сложно найти, сотрудник созванивался с покупателем и предупреждал, что заказ будет закрыт как полностью собранный, но в нём не будет такого-то товара. Если покупатель соглашался, то сотрудник повышал свой KPI, закрывая неполный заказ как полный. Если покупатель отказывался от заказа, сотрудник просил покупателя отменить заказ и снова сохранял KPI на высоте.
Такой трюк портит статистику для бизнеса, так как не видна реальная ситуация. Поэтому в новом приложении мы решили скрыть номер телефона покупателя от сотрудников. За это мы получили шквал заявок в техподдержку 🤬, но так надо.
При поступлении нового заказа система рассчитывает, к какому времени его нужно собрать. Сотрудник в приложении видит время, отведённое на сборку. Если он к этому времени не успевает, то теряет в KPI.
Чтобы избежать этого, сотрудники «фродили». Они закрывали заказы в системе вовремя как «полностью собранные», не собрав их, а недостающие товары докладывали позже. Так в некоторых магазинах накапливалось много недособранных заказов, о чём приходилось помнить сотрудникам.
Разобравшись в процессе, в новом приложении мы дали сотрудникам возможность продлить время сборки легально.
Наша задача не только ввести ограничения или послабления на уровне приложения для сотрудников, но и изучить, корректно ли вообще рассчитывается время на сборку заказа в системе. Возможно, формула устарела и не учитывает многих факторов, которые появились после её введения. Да, тут работа в большей степени для смежных команд, но мы помогаем коллегам реальными данными из магазинов.
Сотрудники «фродят» зачастую потому, что им так удобнее работать, а иногда это вообще единственный возможный способ справляться со своими задачами. Такой своеобразной оптимизацией на местах они делают бизнесу лучше.
Что делать, если сотрудники придумывают свои бизнес-процессы?
Когда «фрод» — обход принятых процессов — хорошо влияет на бизнес, он становится инсайтом.
Это звоночек для нас проанализировать «серый» процесс и легализовать его. Все инсайты мы складываем в копилку. Некоторые сразу реализуем в рамках приложения, какие-то сначала обсуждаем на уровне бизнеса или компании.
«Мы случайно узнали из разговора с сотрудником такой кейс. Если в магазин приходит много мелкого штучного товара (карандаши, ластики, ручки), это всё лежит в больших коробках. И когда падает интернет-заказ на карандаш с кошечками, найти его среди тысяч других карандашей нереально. В одном из магазинов сотрудники придумали сортировать карандаши по небольшим коробкам и писать, что где, в специальном файле Excel.
Одна из наших задач — находить такие местные процессы и оцифровывать их в приложении. И предлагать бизнесу улучшение на физическом уровне. Например, как в этом случае — мы предложили масштабировать систему маркировки коробок»
Мы не только фиксируем проблемы в магазинах, но и стараемся понимать и исправлять их причину более верхнеуровнево.
Внедрение приложения в магазины
Получается, сейчас существует два похожих приложения для сотрудников магазинов: всё ещё более функциональное старое и наше новое. Естественно, что большинство пользователей пока что работает в старом.
Когда запускали проект, была идея не продвигать новое приложение и не вынуждать переходить на него сотрудников. Хотели только рассказывать сотрудникам о новинке и не забывать о поддержке привычного старого приложения. Позже поняли, что работать на две стороны сложно и дорого.
Поэтому решили отказаться от поддержки старого приложения. Мы установили срок его блокировки, к которому все функции уже будут готовы в новом.
Чтобы набрать первых пользователей, необходимых для сбора статистики, мы провели несколько встреч с директорами магазинов, где рассказали о новом приложении и уже готовых функциях.
Позднее мы провели ещё целую серию информационных мероприятий: созвоны с директорами, почтовые рассылки, бумажную коммуникацию в магазина. Так у нас появилось больше пользователей и данных, которые помогают нам развивать новинку. Приятнее всего, что некоторые директора магазинов стали напрямую выходить на нашу команду и предлагать что-нибудь поисследовать в их магазине.
Многие новые сотрудники сразу начинают работать в новом приложении. А старое постепенно вымывается.
Конец статьи и только начало нашей работы
Сейчас мы чувствуем, что уже много сделали. Но в плане работы над продуктом мы находимся в самом начале. Что-то уже понятно, но многое ещё в тумане. Работы много. Работа разнообразная. Работа для людей с разными компетенциями.
Сейчас мы расширяемся и нанимаем. Надеемся, что вы дочитали эту публикацию до конца, вдохновились ею и готовы работать с нами.
🔗Вливайся в классную команду Дм-теха!
Авторы статьи:
Ux/Ui-дизайнер Сергей Булатов, продакт Вадим Копытин, редактор Кирилл Егерев