Квартальное планирование на 20+ команд (Часть 1)

Введение.

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

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

Если вы все делаете правильно, то скорее всего вы начнете расти. Больше людей, больше команд, кто-то работает удаленно, кто-то находится в другой локации. Другими словами увеличивается “налог на коммуникацию”. Становится все труднее собрать и скоординировать всех заинтересованных людей, чтобы принять решение.

Эта проблема проявляется во всех аспектах функционирования компании, но конкретно сейчас я бы хотел поговорить про Планирование.

В какой-то момент в компании появился вполне понятный запрос:

• Сейлз-организация хочет хотя бы приблизительно понимать что им ожидать в следующем квартале.
• С-левел хочет понимать какие есть capabilities у R&D подразделения, чтобы определить стратегические направления работы на ближайшие 3 месяца

Вроде бы ничего нового. Классический запрос для организации 100+ человек. Все же знакомы с Agile и его Scaled Frameworks. “Так это же типичный PI-planning” скажете вы. И будете правы. Только вот загвоздка заключается в том, что в большинстве случаев много кто знает “что” делать, но мало кто знает “как”. Devil is in details как говорится.

Что мы знаем про организацию PI- планинга?

• Соберите всю компанию вместе на 2 дня
• Дайте им вводные и направления
• Составьте агенду 2 дней
• Пусть они общаются и проясняют интересующие их детали
• Красными нитками на доске показываем зависимости между командами
• В конечном итоге каждая команда имеет план по спринтам когда кто что будет делать

Если коротко, это все детали, которые я нашел на официальном сайте по теме PI-планинга.

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

Подготовка

Прежде чем переходить к деталям технической реализации, важно задать контекст.

• Наша компания не работает по SAFe, Less либо какой-то еще известной методологии. Однако в нашем подходе к работе присутствуют много элементов, которые описываются в scaled подходах.
• Разработанный процесс должен обслуживать 4 группы пользователей, которые будут работать с процессом абсолютно по-разному:
• C-левел и Sales-организация. Определяют стратегию на ближайший квартал исходя из состояния дел на рынке. Утверждают финальный план на квартал для каждой команды.
• Product Managers — прорабатывают Epic/Features на квартал исходя из приоритетов от С-левела. Помогают командам технически проработать эпики.
• Представители R&D команд. Изучают Эпики-кандидаты на квартал. Определяют капасити команды. Подсвечивают зависимости между командами.
• Project Management Office — будет следить за всей операционкой, чтобы все участники процесса ничего не забыли и сделали все верно

Вообще, начиная такие проекты, хорошей практикой будет собрать у каждой группы стейкхолдеров ожидания и хотелки. Но нашем случае мы не могли дизайнить процесс очень долго. Был вполне понятный запрос и внедрение первой версии процесса, с дальнейшими доработками было предпочтительнее, чем полгода ждать “идеального” процесса, с учетом всех пожеланий.

В итоге, на уровне Vision-а получился вполне понятный процесс:

1. C-level задает направление
2. Product-команда прорабатывает детали, чтобы это можно было оценить R&D
3. R&D-команда прорабатывает Epics-кандидаты с технической точки зрения
4. В конечном итоге у каждой R&D команды должен сформироваться список эпиков на квартал учитывая:

— Капасити команды

— Приоритеты от бизнеса

— Наличие зависимостей между командами

Теперь, когда понятно “Что”, нужно прорабатывать “Как”.

Поиск Решений.

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

Вы очень зависите от текущих инструментов, интегрированных в вашу компанию. Они ваши текущие data sources. С ними уже привыкли работать люди. Там хранятся ваши исторические данные, чтобы не наполнять все с нуля.

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

Если вашего авторитета и власти достаточно, чтобы отказаться от одного инструмента и переехать на другой — это еще рабочий вариант.

Но добавление еще одного “тула для планирования, который надо будет тоже “обслуживать”, точно приведет к сопротивлению среди участников процесса. А для успешного внедрения изменений, поддержка участников критически важна (но об этом дальше).

Tool should serve the organization but not the organization should serve the tool.

К чему я это все подвожу? Изначально у нас в компании была выбрана Jira Cloud для Project/Task менеджмента. Соответственно поиск решения был ограничен тем, что выбранный инструмент должен был быть частью Jira-функционала, либо достаточно глубоко с ней интегрироваться.

Честно признаться, по запросу “PI planning using Jira” я получил очень мало релевантной информации… Но в конечном итоге выбор остановился на Structure.

Structure

Почему же именно она?

1. Иерархическое отображение информации и группировка.

Достаточно легко я могу отобразить все эпики для конкретной команды, да еще и расширить их user stories под этими эпиками и если надо сгруппировать это все по спринтам. А если какая-то задачка заблочена другой, еще и пока казать эту зависимость.

2. Формулы.

В Structure есть возможность писать свои формулы. Например:

• Просуммируй все завершенные\начатые задачки под этим эпиком и сравни со значением поля Panned Effort (custom field) которое мы проставляем в Эпике.
• Если полученная сумма больше запланированной — подсвети поле красным, иначе зеленым

В целом формулы позволяют делать очень разную крутую магию если вы хоть когда-то писали код.

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

3. Фильтры.

Построив структуру для всей компании, ты можешь легко обвесить ее множеством фильтров (построенных на JQL) которые позволяют конкретной команде смотреть только на свои задачи. В итоге получаем единую точку входа для всей компании, без необходимости строить для каждого свою вьюшку.

А если этот плагин усилить Jira Automation из коробки — получается гремучая смесь:

• создаем planning tasks для команд, исходя какие команды нужны для планирования этого эпика
• автоматически меняем статусы задач, если все готово
• автоматически пишем в слак если кто-то что-то делает не так

В итоге получилась очень мощная связка, которая позволяет планировать работу на квартал вперед для 20+ команд.

Техническая Реализация.

Теперь, когда понятен контекст и мотивация, переходим к самому интересному — реализации.

Задача 1. Отобразить все эпики для планирования на будущий квартал.

Начать следует с того, что мы добавили еще один уровень иерархии над эпиками — Initiative.

Инициатива — это что-то глобальное и скорее стратегическое (например “Новый дизайн главной страницы”), то, с чем удобно работать С-левелу для определения приоритетов и направлений на квартал. Так же это позволяет четко держать продуктовый фокус и не распыляться на миллион вещей одновременно. PMO все время челенджит топ-менеджмент оставлять около 10 инициатив на квартал, над которыми будут работать все команды. Соответственно, любой эпик обязательно должен принадлежать какой-то инициативе.

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

Получается следующая задача:

1. Отобразить только те инициативы, выбранные на новый квартал
2. Под инициативами отобразить эпики, причем только те, которые так же выбраны на новый квартал

Чтобы это все провернуть, нам надо добавить еще один элемент дифференциации — labels. Для каждого квартала мы добавляем новую лейблу, обозначающую, что эта сущность будет частью нового квартального планирования — Q4_2023_Candidate. Ею мы маркируем все наши инициативы и эпики.

Получаем следующее правило:

1. Отобразить все Инициативы с нужной леблочкой
2. Расширить инициативы эпиками под ними

Задача 2. Как понять какие эпики уже можно изучать и оценивать и какая команда должна это смотреть.

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

Оптимизация 1: Добавляем отдельный статус “Refinement Ready”, сигнализирующий о том, что данный эпик проработан и содержит все необходимые детали (definition of ready) для изучения его командой.

Оптимизация 2: Добавляем в эпик кастомные поля Leading Team и Team Dependencies

Leading Team: В нашей компании принято, что именно RnD команда в итоге отвечает за успешную реализацию фичи (ни продакт, ни проджект, а именно команда разработки). Соответственно лидеры команд в первую очередь особое внимание уделяют планированию эпиков, за которые им потом держать ответ.

Team Dependencies: перечисляем все команды, которые должны будут вовлечены в разработку этого эпика. Соответственно каждой команде из этого списка, нужно будет запланировать какое-то время на работу над этим эпиком, если его возьмут в квартал

Как же решаем задачу 2.

Через Structure создаем фильтр для каждой команды, чтобы показать только те эпики, где она является или Leading Team или Team Dependencies.

В итоге каждая команда может увидеть только те эпики, которые нужно оценить и запланировать именно ей.

Задача 3. Как сделать Capacity Planning для каждой команды.

А вот тут уже начинается задача со звездочкой. Перед командой для планирования есть 100 эпиков. Необходимо понять сколько и каких эпиков команда сможет взять в следующий квартал.

Для этого нам надо создать несколько уникальных сущностей.

Для этого вам понадобятся права Global Admin в Jira.

Создаем новый Issue Type — Capacity Planning — оно нам понадобится для будущей формулы ( понять сколько работы сможем взять). В этом issue type нам важно только 3 поля:

• Leading Team
• Labels (ex. Q4_2023_Candidate)
• Capacity MM (тут будем указывать капасити команды на квартал)

Теперь мы можем видеть не только эпики\кандидаты на квартал для команды, но какая у команды капасити на квартал

А теперь там нужно оценить каждый эпик (мы оцениваем их в Man Month). Если над эпиком одновременно будут работать несколько команд, то каждая команда должна оценить его отдельно. Поэтому вариант с добавлением дополнительных полей с оценками в эпик отпал. Пришлось придумывать что-то посложнее

Создаем еще один уникальный Issue Type — Team Planning Task — в иерархии задач, она находится под эпиком (так же как любая User Story).

Ключевые поля:

• Leading Team
• Labels (ex. Q4_2023_Candidate)
• MM Estimated (тут будем указывать оценку команды)
• Committed Yes\No (об этом поле позже)

Так же мы копируем из эпика (через автоматизацию) много других полей (например description или product manager) чтобы команде не нужно было открывать сам эпик в соседнем окне, для проставления оценки.

Теперь каждая команда будет видеть перед собой трехуровневую иерархию с которой ей нужно работать Initiative->Epic->Team Planning Task (TPT)

NOTE: чтобы все отображалось именно так, нам нужно усложнить генерацию структуры.

Было:

1. Отобразить только те инициативы, выбранные на новый квартал
2. Под инициативами отобразить эпики, причем только те, которые так же выбраны на новый квартал

Стало:

1. Отобразить только те инициативы, выбранные на новый квартал
2. Под инициативами отобразить эпики, причем только те, которые так же выбраны на новый квартал
3. Отобразить TPT под эпиками. Но теперь будет проблема, под эпиками есть и User Stories, которые сейчас мы видеть не хотим
4. Для этого добавляем дополнительный фильтр: отображать только эпики инициативы и TPT

Описание процесса Capacity Planning для команды

Итак у нас почти все настроено. Прежде чем переходить к описаниям формул и математике, расскажу сам процесс.

1. Команда заходит на Structure
2. Выбирает свою команду (через фильтры, что я описал выше) и видит (в виде 3-уровней иерархии) все Team Planning Tasks (TPT) которые она должна оценить
3. Сортируем все задачи по приоритету (про приоритеты напишу отдельно) и начинаем обрабатывать эпики сверху вниз

Если все понятно

— Проставляем значение в MM Estimate

— Меняем статус TPT на Estimated

Если есть вопросы

— Пишем коментарий

— Меняем статус TPT на Impediment

— Статусы нужны для PMO, чтобы следить, что в конечном итоге все эпики были оценены и в статусе Estimate

4. Все оцененные эпики суммируются через формулу в отдельном поле (об этом ниже). Продолжаем оценивать эпики пока их суммарная оценка не будет превышать Capacity команды в 1.5–2 раза или пока не закончаться эпики

5. Начинаем выбирать из всех эпиков те, которые точно будем брать в следующий квартал

В TPT меняем значение поля Committed на Yes

Отдельная формула будет суммировать только те TPT, где Committed — Yes (так вот зачем было нужно это поле)

— Еще одна формула будет сравнивать Sum Committed с Capacity команды и высчитывать разницу (т.е. набираем задач в квартал пока поле не будет 0 или отрицательным)

Т.е. мы можем играться с Committed — Yes чтобы уложиться в капасити команды и получить самый оптимальный набор эпиков на квартал

Note: Финальный выбор эпиков делается вместе с топ-менеджментом исходя из того, что могут взять на следующий квартал другие команды (какой смысл брать в работу эпик на который комитнулась только одна команда из 4, указанных в зависимостях)

6. Когда список эпиков определен для всех коммитнутых эпиков меняем статус TPT на Committed.

Тут получается небольшая путаница. У TPT есть поле Committed со стаусами Yes\No. Также у TPT есть статусы (Open, Impediment, Estimated, Committed, Not Committed).

— Поле мы используем для правильной работы формулы (подсчет капасити)

— Статус мы используем для коммуникации с другими командами (и PMO), готовы мы взять этот эпик или нет

Так что же это за формулы у Structure

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

В нашем случае нам нужно было:

• Суммировать TPT для эпиков на которые мы планируем комитаться:

• А еще нам нужно понимать разницу между Team Capacity — SUM Work Committed:

В итоге для команды мы получаем вот такую картину

Как мы видим капасити у команды 7MM. Всего было оценено эпиков на 9,75 MM. Из них комитнулись на 8MM что на 1ММ больше возможностей команды (как команда согласилось на такое, я не знаю).

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

В следующий постах я хочу рассказать про:

• Как внедрить и организовать такое изменения (как квартальное планирование) на всю компанию
• Как пересматривать и улучшать базовый процесс
• Как организовать Monitoring & Control во время квартала
• Какие полезные мониторы\вьюшки можно подготовить для команд для трекинга своего прогресса.

С радостью отвечу на возникшие вопросы.

-Антон