Привет! Меня зовут Трубин Артём, я 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 минут с конкретными повестками, которые понятны благодаря визуализации процесса.
Появилось явное управление приоритетами: когда все проекты собраны на координационной доске, всем становится проще жить. Топ-менеджмент видит, на чем сегодня сфокусированы ресурсы, гибко ими управляет и точнее прогнозирует сроки. А команды явно понимают, над какими задачами нужно работать в конкретный момент времени.
Всё это высвобождает время и энергию всех участников процесса на достижение комплексного бизнес-результата, вместо микроменеджмента и безуспешных синхронизаций команд.
