Привет! Меня зовут Трубин Артём, я CPO в облачном провайдере ActiveCloud. Когда я пришел, у продуктового отдела не было выстроенных процессов, задачи ставились через почту, команда ощущала фоновый стресс, а руководство не устраивала скорость выполнения инициатив. 

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

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

О компании

ActiveCloud — облачный провайдер. Мы занимаемся продажей облачных ресурсов и ПО для организации работы офиса, информационной безопасностью и другими облачными продуктами для организации ИТ-инфраструктуры бизнеса. В моем подчинении 4 менеджера продукта, один аналитик, а также в кросс-функциональном управлении находятся отделы R&D и биллинга.

В рамках онбординга в компанию я выделил ряд проблем:

• коммуникация по задачам велась через почту;

• заказчики не видели, что происходит с их задачами, и требовали соблюдения сроков;

• разные команды зависели от действий друг друга, но не видели общей картины этих взаимосвязей;

• не было понятной приоритизации;

• ежедневные встречи могли длиться по два часа, но не приносить результатов.

Компания не достигала целевых показателей из-за отсутствия слаженной работы всех команд и отделов.

После ряда консультаций с экспертами, я пришел к выводу, что в нашем случае нужно внедрять Kanban-метод c примесью Scum-процессов, так как мы по ряду организационных ограничений не могли выделить кросс-функциональные команды, в которых были бы все необходимые специалисты для достижения результата в формате «end-to-end», что является одним из обязательных критериев для внедрения Scrum в чистом виде.

Мне повезло с тем, что CEO поддерживал изменения, да и продуктовая команда была к ним предрасположена. В качестве рабочего инструмента выбрали Kaiten, так как в нем есть необходимые инструменты для выстраивания процессов по Kanban-методу. 

Визуализация проектов

В первую очередь нам нужно было видеть, над какими проектами мы работаем и какие команды в них вовлечены. 

Для этого мы завели пространство «Координация» и поделили доску на стримы (дорожки) по разным направлениям. Каждый проект фиксируется на этой доске в виде карточки на нужной дорожке и двигается по этапам процесса. 

В свою очередь многие из этапов делятся на дополнительные подэтапы с помощью колонок 2-го уровня. Такая визуализация необходима, чтобы сделать систему вытягивающей. Например, этап разработки делится на подэтапы «В работе» и «Готово». Если карточка находится в колонке «Разработка – Готово», значит, на стороне разработчиков задача выполнена, готова к тестированию и будет перемещена на следующий этап, только когда будут ресурсы на тестирование.

Так мы получаем верхнеуровневую визуализацию работы с портфелем инициатив.

Проработка инициатив и точка принятия обязательств

Дальше доска делится на 2 большие части: 

• Upstream — включает этапы по проработке инициатив и принятию решений «Делать/Не делать»; 

• Downstream — этапы по реализации инициатив в продакшен. 

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

Эти части разделяются этапом «На разработку» — это точка принятия обязательств. Если карточка инициативы прошла все этапы Upstream и попала в эту колонку, значит, эта инициатива имеет проверенный и достаточный бизнес-эффект и команде необходимо взяться за ее выполнение и довести эту инициативу до продакшен.

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

Upstream: принятие решения о ценности инициативы

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

Мы собираем инициативы со всей компании (как это происходит – это тема для отдельной статьи). Собранные инициативы сначала отправляются в общую очередь и хранятся в ней. 

Далее менеджеры продукта берут инициативу на валидацию и назначают инициативе тип: продукт, проблема или идея. 

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

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

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

Если инициатива прошла валидацию, мы двигаем карточку дальше в колонку «Исследования». На этом этапе собираем данные и готовимся к тестированию.

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

Если тестирование прошло успешно, то дальше переносим инициативу на этап «Анализ и оценка для внедрения в продакшен». Здесь мы детализируем затраты, ТЗ и другие вопросы, которые необходимо прояснить для реализации инициативы в продакшен. 

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

Когда инициатива проходит все эти этапы, то попадает в колонку «На разработку». Это значит, что мы уверены в том, что ее выполнение принесет бизнес-ценность, ресурсы по ней не будут потрачены впустую и у нас есть вся необходимая информация для ее выполнения. Здесь наступает точка принятия обязательств, то есть инициативы из этой колонки будут взяты в реализацию на продакшен и будут двигаться по процессу в Downstream.

Тут нужно отметить, что далеко не все инициативы попадают в продакшен. Есть метрика, которая показывает процент отсеивания — Discard Rate. У нас она сегодня держится на уровне 30% — это то, что не идет в продакшен. Но это не значит, что инициатива полностью отсеивается, мы можем «припарковать» ее на будущее, если видим потенциал, но сейчас не время или нет ресурсов.

Downstream: внедряем инициативы в продакшен

Вторая часть процесса направлена на реализацию задач. Downstream включает такие этапы, как:

• разработка, 

• тестирование, 

• оформление документации и обучение, 

• ограниченный запуск, 

• публичный запуск,

• анализ обратной связи.

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

Декомпозиция инициатив на задачи и их распределение среди команд

Когда инициативы идут в работу, они декомпозируются на задачи для конкретных команд и специалистов. Задачи в виде дочерних карточек создаются на отдельных рабочих досках команд: Менеджеров продукта, Аналитики, RND, Маркетинга,  Биллинга, Службы поддержки и Эксплуатации. 

Эти пространства спроектированы по-разному, в зависимости от нюансов организации работы команды и отдела. Например, на рабочем пространстве команды менеджеров продукта мы разделили доску на дорожки, чтобы развести задачи членов команды.

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

Взаимосвязи между отделами: прозрачное кросс-командное взаимодействие

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

Чтобы это исправить, мы реализовали сервисный подход к внутреннему взаимодействию с помощью модуля Service desk в Kaiten.

На пространствах каждой команды есть отдельная доска для приема входящих задач.

Если команда-заказчик есть в Kaiten, то они просто создают карточку-задачу на пространстве команды-исполнителя в колонке «Запросы к …..» и подписываются на нее, чтобы получать уведомления о любых изменениях в этой задаче.

А если команды-заказчика нет в Kaiten, то они отправляют запрос через специальный сервис модуля Service Desk, после чего команда-исполнитель увидит эту заявку в виде карточки на своей доске. 

Команда-исполнитель получит уведомление о том, что к ним поступила новая задача, и может дальше двигать ее по доске. А заказчик получит автоматическое оповещение, как только увидит, что его его заявка принята в работу.

Мы договариваемся на определенный SLA. Например, гарантируем, что в течение 4 часов команда-заказчик получит первичную реакцию на свой запрос. Мы не обязуемся за 4 часа выполнить заявку, но даем понять, что команда увидела обращение и оно будет обработано в соответствии с регламентом приоритетов.

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

Результаты спустя полгода с момента начала внедрения Kanban-метода

За 6 месяцев мы прошли путь от первого уровня зрелости команд по Kanban Maturity Model, на котором каждый специалист работает самостоятельно, до третьего, на котором выстроена синхронная кросс-функциональная работа разных команд для достижения общих результатов.

Если кратко, то скорость решения вопросов выросла в три раза: что раньше решалось годы, сегодня решается за квартал.

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

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

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

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