Как Провести Распределенное Безбумажное Квартальное Планирование И Не Облажаться?

Пока космические корабли бороздят просторы, а Илон Маск роет туннели, мы, «айтишники», упорно пишем маркерами на липких бумажках и приклеиваем их на доски — в этом есть определенный диссонанс.

Вот как выглядел наш комментарий некоторое время назад:



Да, это лист бумаги размером примерно 2х5 метров, и каждый лист бумаги нужно было после планирования превратить в задачу в Jira. 2) Усталость собратьев-кочевников.

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

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

3) Вовлечение большего количества ИТ-коллег в процесс планирования.

Как понятно из предыдущего пункта, мы не могли позволить себе отправить на планирование весь офис, поэтому отправили только Избранных, исключив тем самым остальных из процесса, что не добавило никаких плюсов к общей морали.

4) Оптимизация финансовых затрат. Да, это чувствительный момент — ключевых людей много, и возить их туда-сюда самолетом четыре раза в год — это дорого.

Чтобы это произошло, я должен как можно раньше занять владельцев бизнеса работой над предлагаемыми инициативами (или, в терминологии SAFe, «всплесками», но я буду использовать привычный мне термин).

В идеале этот процесс должен быть полностью отделен от циклической природы квартального планирования и следовать своему собственному пути Канбана.

За основу мы взяли портфолио SAFe Kanban:



У нас есть отдельный проект JIRA с тремя типами задач: эпики, бизнес-инициативы и архитектурные инициативы; а также соответствующую доску Канбан.

Алгоритм для владельца инициативы прост: он добавляет задачу в этот проект, и она по умолчанию попадает в Backlog — это первый статус нашего канбана — Воронка:



Там хранятся инициативы, которые еще не готовы к рассмотрению.

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

Минимум, необходимый на этом этапе — это заполненные поля «Постановка задачи», «Желаемый результат» и «Показатель успеха», а также чуть более подробное, но простое и понятное изложение.

На этом этапе важно отойти от упоминания технических решений и сконцентрироваться на бизнес-параметрах.

Когда все данные собраны, владелец переводит задачу в следующий статус — Обзор.

Мы проводим обзоры еженедельно, как для деловых, так и для архитектурных инициатив.

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

Результатом рассмотрения является решение о дальнейшей судьбе инициативы.

Плагин «Структура — Управление проектами в масштабе» — для визуализации структуры инициатив со связанными с ними функциями и их приоритетами WSJF. Atlassian Confluence — источник внутренней документации Lucidchart и его плагины для Jira и Confluence — для рисования диаграмм.

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

Обратная связь.

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

Это важная часть постоянного улучшения процессов.

Техническое обучение.

С переходом на удаленное планирование возникли специфические запросы, такие как качество интернет-коммуникаций (приоритизация и оптимизация маршрутов для JIRA и Confluence) и наличие телевидения и аудио (мы используем комплекты Logitec Group, микрофоны Jabbra и персональные наушники в различных комбинациях, веб-камеры, программное обеспечение для видеоконференций Zoom).

Фасилитаторы.

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

Аудитория.

Соответственно полный список всех приглашенных.

Проверьте список.

Полный список важных задач со сроками и обязанностями.

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

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

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

На данный момент количество групп распределено между тремя офисами по формуле 4х4х2, а удаленные пользователи подключаются к нужному столу через выделенный канал Zoom. В конце раскрытия каждой из инициатив координатор должен убедиться, что все необходимые данные, такие как, например, критерии приемки, описание технического решения, риски, зависимости, потребность в новой инфраструктуре, доступны.

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

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

Во второй половине первого и второго дня наступает время неторопливых занятий в соответствии с приоритетами.

У меня есть несколько отдельных структур для выполнения фиксации.

Первый из них представляет собой структуру, содержащую список функций и историй, планируемых к совершению:



К сожалению, в этой структуре присутствуют остатки материала, не вошедшие в комментарий за текущий квартал, поэтому выборка не репрезентативна.

В любом случае, в поиске я могу выбрать интересующую меня инициативу в порядке приоритета по номеру, который в процессе поиска вводится в отдельное поле для каждой функции и истории, изменить статус необходимых задач с Запланировано на Зафиксируйте и поместите их в нужную итерацию, тем самым зафиксировав:



В результате задача исчезнет из этой структуры и появится в новой, отражающей растущий коммит:



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

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

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

.

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

Для этого я использую плагин Bulk Clone Professional for Jira — он добавляет в меню «Массовое изменение» пункт, обеспечивающий коллективное клонирование, и имеет нужные мне возможности, такие как клонирование ссылок, обновление ссылок между вновь созданными клонами, обновление эпические ссылки, добавление префикса в заголовок и автоматическое добавление метки:



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

Во-первых, я клонирую абсолютно все задачи в отдельный проект Global Backlog, так как в нем мы храним эпики, а мне нужно иметь актуальные связи эпик-история в свежеклонированных задачах.

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



В целом, преимущества, которые дает такой подход: Как бы тривиально это ни было, ИТ-специалисту проще напечатать новые функции и истории, чем писать их маркером на липком листе бумаги.

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

Благодаря клонированию исходная копия коммита сохраняется для истории, и вы всегда можете к ней вернуться.

Это экономит много времени и сил на подготовке планирования – работа с бумагой отнимает силы.

Конечно, здорово, что вам больше не нужно заполнять задачи в Jira с бумажек.

Но мне пока не ясно, интересна ли эта тема зрителям, и если да, то чем именно.

Если увижу интерес, буду готов раскрыть нужные темы.

И еще — сложно поверить, что такое возможно, но хотелось бы избежать всей этой суеты вокруг agile, фреймворков, эффективных и «эффективных» менеджеров.

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