Предыстория.
Продуктовая группа стартовала работать в LeSS несколько лет назад. Тогда было сформировано 5 фиче-команд. Со временем, потребности бизнеса в доставке ценности выросли, поэтому команды приступили к найму разработчиков для последующего митоза (см. паттерн Mitosis) и образования 6 и 7 команды. Через 6 месяцев найма и адаптации новых членов продуктовой группы, ситуация на рынке изменилась, что повлияло на расширение определения продукта. Появилась необходимость не только в новых командах, но в расширении технологического стека. Владелец Продукта коммуницировал командам изменившееся видение продукта и представил верхнеуровневый Бэклог Продукта на ближайшие 6 месяцев.
Создание Heat Map
Чтобы понять, какие компетенции должны быть в командах, мы использовали Heat Map. Heat Map - инструмент, который представляет из себя таблицу (Рис. 1), где столбцы - архитектурные компоненты и функции, строки - элементы Бэклога Продукта.
Если для создания PBI требуется работа в тех или иных архитектурных компонентах, то на пересечении строки и столбца ячейка загорается. Таким образом, подсчитав количество горящих ячеек в каждом столбце, можно обнаружить наиболее часто используемые компоненты, технологии, навыки работы с которыми должны быть в командах, чтобы они могли выбирать любой элемент из Бэклога Продукта и самостоятельно выпускать его на рынок по крайней мере один раз за спринт.
Чтобы создать Heat Map, мы провели встречу со всеми участниками продуктовой группы. Встреча проходила онлайн при помощи zoom и miro. Мы заранее приготовили станции в miro с заготовками Heat Map по количеству рабочих групп. В заготовке был заполнен первый столбец - элементы Бэклога Продукта (рис.2).
На встрече, после того, как была озвучена цель и агенда, мы на примере познакомили участников с инструментом Heat Map. Затем, объединили участников в группы и попросили на станциях выписать на стикерах все технологии и архитектурные компоненты, необходимые для создания каждого PBI (заполнить первую строку Heat Map). Когда работа была завершена, у каждой станции был свой вариант списка компонентов и технологий (Рис. 3).
Для следующего этапа, нужно было объединить эти списки в один. За основу была взята 1 станция, мы попросили остальных участников встречи добавить стикеры с недостающими архитектурными компонентами, технологиями, а дублирующие стикеры разместить рядом. В процессе, участники в открытой дискуссии обсуждали, какое название выбрать лучше, чтобы всем было понятно, о чем идет речь, какую еще стоит добавить технологию, а также прояснили, что имели в виду их коллеги.
Для завершения работы над Heat Map, снова объединили участников в группы. На этот раз задача состояла в том, чтобы поставить “галочки” на пересечении строки - PBI и столбцов - компонентов, которые потребуются для завершения PBI. Мы попросили группы руководствоваться правилом: если кто-то из другой группы уже поставил “галочку”, ее нельзя удалять, даже если кажется, что этот компонент не потребуется, так как возможно у другой группы есть больше контекста. После возвращения групп в общий зал, мы посчитали количество “галочек” - частоту использования компонентов, технологий (Рис. 4). Мы подвели итоги работы и завершили встречу.
После встречи мы упорядочили список компонентов и технологий по частотности их применения. Абсолютная адаптивность требует включения 100% компетенций во все команды, но зачастую это избыточно. Поэтому мы воспользовались правилом Парето. Согласно нему, нужно создать такие команды, участники которых покрывают как минимум 80% наиболее задействованных компонентов и функций. При этом вся группа команд должна закрывать все 100%.
Таким образом, мы получили список необходимых в команде навыков и первое ограничение для воркшопа по формированию команд, о котором я расскажу в следующем посте.
