20 Апреля 2023 12:00 20 Апр 2023 12:00 |

Поделиться

5 команд на 1 продукт: как X5 выстроила рабочие процессы от визуализации и прозрачных взаимосвязей до работы с блокерами, WIP-лимитов и аналитики

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

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

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

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

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

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

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

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

Вести такую доску было крайне сложно по ряду причин:

1. Каждый раз возникали новые рабочие элементы, и было сложно понять кто именно их добавил;
2. Надо было вручную вести статистику, и каждый раз она расходилась, потому что в любой момент кто-то мог внести изменения;
3. Количество карточек было огромным, поэтому на еженедельных встречах нам не хватало выделенного часа для обсуждения всех задач;
4. Людям было сложно работать с новой визуализацией;
5. Явно отсутствовала эмпатия к такой визуализации. Особенно ярко это подсвечивало название доски — все ее называли «доска Артура».

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

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

При переезде в Kaiten сразу было принято решение показывать работу всех команд в одном общем пространстве:

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

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

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

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

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

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

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

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

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

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

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

Проведя анализ по блокерам, мы увидели 3 наиболее часто встречающихся кластера блокировок: «Нет рук», «Зависимость от другой задачи» и «Не хватает обратной связи».

Как мы выстроили процесс анализа блокировок?

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

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

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

Забегая вперед скажу, что после введения WIP-лимитов блокер «Нет рук» сократился. И сумма потерянного времени значительно уменьшается.

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

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

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

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

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

Тогда мы установили допустимый WIP (количество незавершенной работы) для каждой из команд и зафиксировали его в описании доски производства. Сумма лимитов всех команд — это и есть общий WIP-лимит. То есть одна команда может одновременно выполнять пять задач, а другая — семь. И это нормально, потому что у каждой из них своя специфика работы и производительность.

Эти же WIP-лимиты каждая команда устанавливает на своих функциональных досках.

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

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

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

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

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

Чтобы исправить ситуацию, мы добавили в процесс этап Discovery. Для удобной визуализации этого этапа мы создали две доски Backlog discovery и Discovery:

Все новые идеи складываются в очередь Backlog discovery — это такой склад всего подряд. Затем мы проводим их приоритизацию по методу RICE и принимаем решение, берем ли мы их в Discovery сейчас или вернемся к ним позже.

В ходе Discovery мы:

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

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

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

Прошел год, как мы работаем в Kaiten: что изменилось

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

В мае 2022 г. команда стала осознавать плюсы визуализации:

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

Спустя год:

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

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

Поделиться

Подписаться на новости Короткая ссылка