Как CPO организовать работу продуктового отдела в Kaiten

Привет! Меня зовут Артём Трубин, я работаю в компании 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