Как CPO организовать работу продуктового отдела в Kaiten
Кейс ActiveCloud: как с помощью Kanban-метода наладить коммуникацию между отделами, сократить ежедневные созвоны и повысить производительность команд в три раза
Привет! Меня зовут Артём Трубин, я работаю в компании ActiveCloud на должности директора по продукту. В момент, когда я пришел в компанию, у команд не были налажены рабочие процессы, все задачи назначались через почту, а руководство было недовольно скоростью выполнения проектов.
У команды развития продукта и отделов, которые с ней связаны, был запрос на изменения. И я взялся за это. Уже через полгода усилий мы достигли 3 уровня зрелости по модели Kanban Maturity Model, на котором построена синхронная кросс-функциональная работа разных отделов с целью достижения общих результатов.
Мы только недавно перешли на этот уровень и впереди еще много задач, чтобы его закрепить. Но уже сейчас хочется поделиться своим опытом по внедрению Kanban-метода в рабочие процессы компании и тем, что из этого вышло.
О компании
Мы продаем облачные решения для организации работы офисов. В моем подчинении 4 product-менеджера, аналитик, а также в общем доступе находятся отделы R&D и биллинга.
Прежде чем внедрять новые механики, я обозначил наши проблемы:
- плохо налажены пути коммуникаций между отделами, все задачи ставились через почту;
- отсутствовала приоритезация новых задач;
- заказчики не понимали, на каком этапе находится их проект и когда он будет готов;
- не было карты взаимозависимостей, из-за чего смежные отделы не понимали важность выполнения работы в срок;
- ежедневные созвоны длились по несколько часов, но часто были безрезультатны.
После анализа проблем и обсуждения с экспертами я решил, что нужно внедрить Kanban-метод с применением некоторых Scrum-процессов. Так как для внедрения Scrum в чистом виде необходимы объединенные команды с узкопрофильными специалистами для работы в формате «end-to-end», которых по ряду организационных моментов у нас не было.
Меня радовало то, что в компании все были готовы к переменам. Для работы выбрали Kaiten, потому что в нем имелись все необходимые инструменты для работы по Kanban-методу.
Визуализация проектов
Для начала мы определили, по каким проектам ведется работа и какие команды отвечают за них. Для этого создали пространство «Координация», разделили доску по дорожкам с разными направлениями. Все проекты закрепляются на этой доске на определенной дорожке, по мере выполнения карточка передвигается по этапам.
Многие этапы разделены на более детальные подэтапы с использованием вторичных колонок. С такой визуализацией система становится вытягивающей. Например, этап разработки разделяется на «В работе» и «Готово». Если карточка находится в колонке «Разработка — Готово», то это означает, что задача выполнена разработчиками, готова к тестированию и будет перемещена на следующий этап только после наличия ресурсов для тестирования.
Так мы получаем верхнеуровневую визуализацию работы с портфелем инициатив.
Проработка инициатив и точка принятия обязательств
Мы делим доску на 2 части:
- доска Upstream, которая включает в себя этапы по проработке инициатив и принятию решений;
- доска Downstream, которая отвечает за этапы по реализации проектов и передачу в продакшен.
Здесь важно отметить, что в этот процесс включены инициативы не только по разработке и изменению продуктов. Это могут быть инициативы и по изменению бизнес-процессов компании или внедрению внутренних систем для повышения эффективности. В этом случае в Upstream мы исследуем и тестируем предлагаемое изменение, а в Downstream — внедряем изменения в регулярный бизнес-процесс.
Две части разделяются этапом «На разработку», который является нашей точкой принятия обязательств. Если карточка инициативы прошла по всем этапам Upstream и попала в Downstream, это означает, что данная задача проверена и имеет весомый бизнес-эффект. И команда должна взяться за ее исполнение, доведя инициативу до продакшена.
С помощью этой системы мы можем эффективно управлять потоком входящих заявок: в работу берутся только те задачи, которые имеют обоснованную ценность как для компании, так и заказчиков.
Upstream: принятие решения о ценности инициативы
Наша главная цель — сократить риски для компании и выполнять только те задачи, которые принесут выгоду для компании. Чтобы наша цель исполнялась, мы внедрили несколько этапов: валидация, исследование и тестирование инициатив.
Инициативы, которые мы получили со всей компании (как мы это делаем — лучше рассказать в отдельной статье), отправляются в общую очередь, откуда менеджеры по продукту забирают карточки на валидацию. После проверки инициативе присваивается тип: продукт, проблема или идея.
Затем карточки пропускают через специальные фильтры, чтобы до реализации дошли только те, которые подходят под регламент компании. Фильтр помогает определить, например, соответствует ли данная инициатива OKR организации.
В зависимости от типа инициативы карточкам присваиваются чек-листы с определенными критериями, которые отличаются друг от друга исходя из категории. Чек-листы помогают product-менеджерам понять, стоит ли двигать проект дальше или его нужно отсеять.
После прохождения всех этапов проверки для инициативы, которая двинулась дальше, должна быть сформулирована гипотеза. Чтобы снизить когнитивную нагрузку и ввести единый формат работы для всех сотрудников, гипотезы формируются автоматически в комментариях по шаблону.
Если инициатива соответствует всем требованиям компании, мы передвигаем ее в колонку «Исследования». В этой колонке происходит сбор данных и анализ проекта.
После чего приступаем к тестированию. Перед тем как передавать проект в разработку, нам нужно получить обратную связь от внутренних или внешних клиентов. Мы проводим A/B-тесты, собираем фокус-группы, демонстрируем MVP и т. д.
Если результат теста успешный, мы передвигаем карточку на этап «Анализ и оценка для внедрения в продакшен». На этом этапе идет анализ и сбор данных по затратам, ТЗ и другим вопросам, которые нужно прояснить для реализации инициативы в продакшен.
Важно отметить, что чек-листы присутствуют на каждом из вышеописанных этапов. Они помогают соблюдать сроки и регламенты по рабочему процессу.
Когда инициатива прошла все эти этапы, мы передвигаем ее в колонку «На разработку». На этот этап переходят те проекты, которые принесут компании бизнес-велью, а ресурсы на ее исполнение не будут потрачены впустую и мы имеем все необходимые данные для реализации. Тут наступает наша точка принятия обязательств, то есть проекты из этой колонки попадут в Downstream и будут исполняться.
Нужно отметить, что далеко не все инициативы попадают в продакшен. Есть метрика, которая показывает процент отсеивания — Discard Rate. У нас она сегодня держится на уровне 30% — это то, что не идет в продакшен. Но это не значит, что инициатива полностью отсеивается, мы можем «припарковать» ее на будущее, если видим потенциал, но сейчас не время или нет ресурсов.
Downstream: внедряем инициативы в продакшен
Во втором процессе Downstream, который направлен на реализацию проектов, есть несколько этапов:
- этап разработки,
- этап тестирования,
- этап оформления документации и обучения,
- этап по ограниченному запуску,
- этап публичного запуска,
- этап с анализом обратной связи.
Наличие этапов позволяет отслеживать актуальные состояния задач и быстро решать проблемы, которые мешают исполнению. Например, если в очереди на разработку стоит много задач, то мы можем быстро найти и устранить причину.
Распределение проектов среди команд
Когда инициатива переходит в исполнение — карточка проекта распределяется на конкретную команду или специалиста. С помощью дочерних карточек задачи создаются на отдельных досках разных отделов.
У каждого отдела есть своя доска, которая спроектирована с учетом рабочих нюансов. К примеру, на рабочем пространстве команды менеджеров продукта мы разделили доску на дорожки, чтобы развести задачи членов команды.
Главная карточка будет отражать прогресс и всю работу по проекту, а отдельные команды будут видеть только свои задачи, с которыми будет вести работу на отдельных досках.
Коммуникация между командами — внедрение Service desk
Изначально в компании была плохо налажена коммуникация между смежными отделами. Один отдел ставил задачи другому, но не знал? ведется ли работа по их заявке и когда она будет исполнена.
Чтобы решить эту проблему, внедрили модуль Service desk, который реализовал сервисный подход к взаимодействию между отделами.
Внутри пространства каждой команды есть отдельная доска для приема входящих заявок.
Если заказчик использует Kaiten, он может создать карточку с задачей и разместить ее на доске «Запросы к …..» , а также подписаться, чтобы получить уведомление о начале работы с заявкой.
Если команды-заказчика нет в Kaiten, то заявку можно направить через специальный сервис модуля Service Desk.
Заказчик получит оповещение о том, что его задача принята в работу, а команда-исполнитель увидит эту задачу в виде карточки на своей доске и получит уведомление о новой заявке.
Внутри отделов есть SLA по первичной реакции на новую заявку. Например, мы гарантируем, что команда-заказчик получит уведомление о том, что его заявку увидели и взяли в работу, в течение 4 часов. Конечно, исполнитель может не успеть выполнить задачу за это время, но заказчик будет уверен, что его заявка не потерялась и будет выполнена в ближайшее время.
Наши результаты через полгода работы по методу Kanban
За полгода мы проделали огромный путь в развитии команд по модели зрелости Kanban Maturity Model. На начальном уровне каждый специалист работал независимо, но благодаря нашим усилиям мы достигли третьего уровня зрелости, где различные команды синхронно взаимодействуют друг с другом для достижения общих результатов.
Стоит отметить, что такой быстрый рост связан с активным участием всех команд и их запросом на перемены. Но мы понимаем, что процесс изменений и развития постоянен, поэтому нам есть куда расти!
Встречи между отделами стали более эффективными — мы не тратим большое количество времени на собрания и двигаемся согласно теме встречи, которая понятна благодаря визуализации.
У нас появилась понятная система приоритезации — когда все рабочие процессы находятся в одном пространстве, всем становится проще жить. Руководство видит, куда направлены ресурсы команд, поэтому может прогнозировать сроки выполнения. А у отделов появляется четкая картина тех задач, над которыми нужно работать в первую очередь.
Благодаря автоматизации и налаженным рабочим процессам у всех членов команд появляется время и энергия, которую они направляют на достижение комплексного бизнес-результата.
P.S. Я на связи в Telegram @trubinart
Успешные компании уже используют Kaiten. Попробуйте расширенный функционал на своем проекте бесплатно.
Попробовать