Сделать работу сотрудников удобнее, а самих специалистов — счастливее: опыт команды Lamoda

Привет, VC! Меня зовут Яна Климанова, я менеджер по развитию продукта доставки в компании Lamoda. В нашей компании работает больше 11 тысяч сотрудников — это огромный механизм, внутренние процессы которого нужно постоянно поддерживать и совершенствовать.

Доставка Lamoda — это большой отдел, почти 5 000 сотрудников. А доставлять заказы клиентов в России, Казахстане и Беларуси нам позволяет внутренняя доставочная система Express, которую развивает и поддерживает большая IT-команда. В ней мы пилим как крупные проекты, так и небольшие доработки, которые улучшают рабочие процессы других сотрудников. Расскажу, как это происходит и какие результаты нам приносит в итоге.

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

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

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

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

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

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

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

То есть, наш Feature Backlog основан на максимально клиентоориентированном подходе к продукту. Это позволяет нам внедрять в текущие процессы решения, которые лучше всего соответствуют реальным потребностям. А это помогает нам не только делать работу внутренних пользователей удобнее, повышая их эффективность, результативность и лояльность к компании, но и предоставлять более качественный сервис клиентам. Именно в этом суть.

Мы стараемся стандартизировать процесс подачи и рассмотрения заявок в Feature Backlog. Уже сейчас у нас примерно 200 задач в очереди, поэтому единый процесс крайне важен, чтобы ничего не потерялось. А еще это просто удобно и для нас, и для самих сотрудников.

Чтобы подать заявку, нужно пять минут: сотруднику необходимо заполнить форму, в которой он указывает:

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

А еще в нашей команде есть практика Field Experience — так называемая «работа в полях». Это когда любой сотрудник офиса Lamoda едет, к примеру, в пункт выдачи заказов или на транзитный склад и смотрит, как процессы, продукты и системы работают в обычном режиме. Он общается с пользователями, собирает обратную связь о взаимодействии с продуктами и системами. Свежий взгляд позволяет оценить, насколько удобно построены действия и как их можно улучшить. Естественно, обратную связь специалистов на месте мы тоже собираем. А после из этого тоже формируются конкретные задачи.

Общая схема для задач фича бэклога выглядит так:

Все заявки падают к нам задачами в Jira, где мы распределяем их между нами (продактами) в зависимости от того, к какому продуктовому стриму относится задача и кто в нем владелец экспертизы.

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

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

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

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

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

А далее используем формулу, чтобы определить финальную оценку:

Чем выше результат, тем выше задача стоит в приоритете.

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

Начинаем измерение:

Используем формулу и для этой задачи получаем 2. И так для всех обращений. Чем больше коэффициент, тем выше задача по приоритету.

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

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

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

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

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

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

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

При планировании ресурс команды разработки распределяем по приоритетам всего продуктового бэклога в целом: сначала проекты с большим value, потом фичи. Заворачиваем все это в план, в течение этого периода разрабатываем, тестируем, проводим User Acceptance Testing (UAT) и релизим. А в самом конце рассказываем о доработке в Release Notes и собираем обратную связь.

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

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

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

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

Допустим, у сотрудника есть идея: добавить кнопку «История заказа» на страницу «Детали заказа», чтобы не переключаться между вкладками и не искать информацию дополнительно. Он оставляет заявку.

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

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

Такая мотивация одного сотрудника приносит компании долгосрочные плюсы:

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

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