Кейс X5: как продуктовые команды выстроили прозрачные рабочие процессы и начали работать по канбан-методу

Чем больше команд и сотрудников работает над одним продуктом, тем тяжелее добиться слаженной и эффективной работы. Это и произошло в компании X5

X5 Tech — это IT-компания и основной цифровой партнер торговых сетей и бизнесов X5 Group. В X5 есть продукт, который направлен как на внутренних пользователей так и на покупателей «Пятерочки»​​. Одновременно над ним работает 5 продуктовых команд — более 50 специалистов.

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

• Отсутствовало прозрачное взаимодействие между командами.
• Невозможно было ответить на вопрос бизнеса «Когда будет готово?».
• Сотрудники не понимали, как идет процесс поставки ценности.
• О новых функциях продукта узнавали, только когда ломался другой функционал.

Чтобы решить перечисленные проблемы, команда X5 Tech перешла в Kaiten и организовала совместную работу над продуктом. Подробнее о работе с таск-трекером нам рассказал delivery-менеджер X5 Tech — Артур Темиров.

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

Шаг 1. Поиск инструмента для управления проектами и совместной работы

Таск-трекер — не новый инструмент в X5 — раньше у каждой команды была собственная доска в Jira. Но, так как компании нужно было визуализировать рабочие процессы 5 команд и создать единую картинку по 1 продукту, от Jira решили отказаться.

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

Но вести доску для такой большой команды с разными специалистами становилось всё тяжелее, потому что:

1. Когда появлялись новые задачи или рабочие элементы, было непонятно, кто выступал в роли заказчика. Из-за этого приходилось тратить много времени на погружение в задачу.
2. В Miro нет автоматической статистики, поэтому сотрудникам приходилось вести ее вручную. Каждый раз статистика расходилась, т.к. в любой момент кто-то мог внести изменения.
3. Карточек было слишком много, и на встречах нам просто физически не хватало заложенного времени для обсуждения задач.
4. Ребятам из команды было сложно работать с новой визуализацией. Плюс она совершенно не ассоциировалась с их работой. Особенно ярко это подсвечивало название доски — все ее называли «доска Артура».

И хоть работа в Miro тоже не подошла ребятам, команда получила много плюсов от этого изменения. Как отмечает Артур:

«Мы заложили фундамент для дальнейшей оптимизации наших процессов. К счастью, работать с доской в Miro пришлось только 3-4 месяца, и в апреле 2022 мы мигрировали работу команд в Kaiten, чтобы удобно управлять процессом производства в продукте».

Шаг 2. Визуализация задач всех команд на одном пространстве

Одной из причин, из-за которой X5 решили перейти в Kaiten, стала возможность показать работу всех команд на едином пространстве.

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

Т.к. одной из причин отказа от Jira была необходимость постоянно переключаться между разными досками разработчиков, в Kaiten ребята сделали дополнительные доски команд на одном пространстве. Каждая доска отображает техническую реализацию инициатив.

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

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

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

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

Шаг 3. Попытки сократить время производства

Первая доска подсветила команде X5 первые проблемы. И руководство задалось вопросом: «Почему так долго?». Начали разбираться.

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

«Нам стало ясно, откуда возникает нехватка ресурса и высокий lead time (время производства)».

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

Как в X5 выявили причины блокировок задач и уменьшили их количество

Для подробного анализа блокировок команды брали данные из Kaiten и обрабатывали их вручную.

В ходе анализа было выявлено несколько причин высокого lead time. Главная причина заключалась в большом количестве блокировок задач, которые не могут быть завершены по какой-либо причине, и в итоге сильно тормозят рабочий процесс. Проанализировав блокеры, ребята увидели 3 наиболее часто встречающихся кластера блокировок:

1. «Нет рук»,
2. «Зависимость от другой задачи»,
3. «Не хватает обратной связи».

В итоге команда построила различную аналитику, например, как на рисунке выше.

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

• Проблему «Нет рук» решили с помощью WIP-лимитов.
• Проблемы зависимостей задач друг от друга решили, запустив процесс Discovery и описав для него правила передачи инициатив в Delivery.

Результат не заставил долго себя ждать — сумма потерянного времени значительно уменьшилась.

Как установить лимиты, если над задачами работает пять разных команд

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

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

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

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

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

«Какой это дало результат? Лидтайм начал расти, а не падать. «Фейл!» — скажете вы. А я скажу, что это было очевидно, и мы были к этому готовы. Дело в том, что лидтайм нашего продукта по 85 процентилю — 130 дней. Большое количество задач уже находилось в работе. Понятное дело, чтобы завершить их все и «очиститься», требуется достаточно много времени».

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

Шаг 4: Детальная проработка инициатив до взятия в работу

После собранной аналитики команда поняла, что около 25% задач, которые попадали на доску Delivery, либо стояли на месте из-за блокировки, либо отменялись. Команда пришла к выводу, что инициативы, которые передаются разработчикам, недостаточно проработаны.

Чтобы исправить ситуацию, X5 решили добавить дополнительные доски для нового этапа — Discovery:

1. Backlog discovery — сюда команда складывает все поступающие идеи.
2. Discovery — место для сортировки и приоритезации этих идей по методу RICE.

В ходе Discovery команда:

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

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

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

Что изменилось спустя год работы в Kaiten

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

Поработав в Kaiten несколько месяцев, команда оценила плюсы визуализации работы в новом инструменте:

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

А спустя год, как отмечает Артур:

⚬ «Команда перестала бездумно брать задачи в работу, а потом отменять их. Сначала анализируем, понимаем риски и совместно принимаем решение о дальнейшей работе над инициативой.

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

⚬ Анализируем и открыто обсуждаем эти данные, что позволяет нам совместно принимать решения о новых изменения в нашем процессе производства».