Contents
Павел Кондратьев
Менеджер проектов в ГК Юзтех
Меня зовут Павел Кондратьев, я руководитель проектов в ГК Юзтех. Управляю разработкой мобильных и веб-приложений. В статье, которую я сделал с платформой управления проектами НЕДЕЛЯ, я хочу ответить на вопросы о том, как часто результат зависит от работы других команд, как синхронизировать разработку, грамотно управлять доставкой и ожиданиями в условиях постоянно меняющихся требований. Также я расскажу, как учитывать проектные риски и что с ними делать.
Статья была впервые опубликована на vc.ruв связи с актуальностью дублирую материал на хабре.
Уже год мы работаем с крупной цифровой клиентской платформой. С самого первого проекта команды, которыми я руковожу, сталкиваются с ситуацией, тормозящей процесс разработки: мы делаем итерацию, затем для продолжения работы приходится ждать, пока команда, с которой мы планируем интегрироваться, выполнит свою часть задач.
Agile-методологии хорошо зарекомендовали себя при реализации проектов автономной и сокращенной командой. Для управления командами до 10-12 человек гибкие методологии подходят даже для решения сложных задач в бизнес-системах. Вот в чем проблема, потому что Agile ориентирован на небольшие команды и в какой-то степени не дает ответа на вопрос — а что, если команд много?
В какой-то момент при разработке сервисов и продуктов, в которых зависимости тесно связаны друг с другом, мы потеряли сроки доставки. Мы поняли, что должны бороться с этим.
Мы решили подключить инструмент, который бы занимался этой проблемой — PI Planning Agile. Этот инструмент является частью Scaled Agile Framework (SAFe), который расширяет стандартный Agile с его ограничениями для работы с небольшими командами до подхода к управлению командами из 100 и более человек.
Как выглядит PI-планирование на практике
Расписание задач на квартал
Не вините меня за пример, который я подготовил. Конечно, там не все описано, и пример существует только для ознакомления на высоком уровне, но он помогает понять концепцию. Я думаю, это важнее.
Для просмотра доски расписания можно использовать любой популярный ресурс: Figma или Miro. Нам удобнее использовать последний, т.к. уже есть готовые шаблоны и ничего придумывать не надо, можно прямо во время звонка выполнить горячий старт. Однако, если вы внедряете этот инструмент, рекомендуется заранее записать задачи, которые вы запланировали для своей команды, чтобы объяснить своим коллегам, что от них ожидается. Перед планированием советую попросить их создать бэклог для каждой команды, сгруппировать карточки с задачами на квартал в пустое поле рядом с доской, чтобы потом их можно было отнести на доску планирования.
Шаг 1
Первое, что нужно сделать, это провести сеанс планирования PI. Это происходит так: владельцы продукта и менеджеры проектов собираются вместе и проходят ряд шагов. На временной шкале с вехами в виде командных спринтов они описывают задачи, которые планируют выполнить в квартале. На этом этапе важно разместить задачи таким образом, чтобы их последовательность выстраивалась в каждой командной строке с учетом приоритетов и технических ограничений, когда задача может быть выполнена только после выполнения другой.
Еще одним важным элементом является определение зависимостей между задачами разных команд и вехами: выполняется предварительное планирование.
Кстати, то, что происходило на доске, принято называть Agile release train — релиз-поезд. В компании может быть один или несколько поездов этого типа.
В примере выше все задачи отмечены белым цветом, что не дает визуального представления о том, где формируется узкое место и от каких команд строится зависимость. Пока известно только, как и какие задачи взаимосвязаны. Поэтому на следующем шаге нужно определить, кто ждет задание и кто должен его выполнить. Во время сеанса планирования выделяется время в районе 5-10 минут, чтобы все PO и PM могли распределить известные им задачи из бэклога на доске.
2-й шаг
После этого каждая команда должна подробно рассказать о задачах за 5-10 минут. На этом этапе могут появиться зависимости, которые ранее не предполагались. Зависимости должны быть немедленно исправлены ведущим. Блокирующая задача окрашена в красный цвет.
Теперь у нас есть таблица и визуализация обученных на ней зависимостей:
Мы видим, что задачи с номерами 2, 6, 7 и 9 являются блокирующими.
Любой блокировщик — это риск.
Поэтому постараемся в это время понять, можем ли мы повлиять на выявленные нами риски, например, сдвигая сроки.
Правила лучше всего установить в начале встречи. Например, мы сами решили, что задачи, находящиеся в одной колонке спринта с вехой, а также задачи из предстоящих спринтов считаются частью релиза. Соответственно, сдвиг задачи номер 9 вправо означает сдвиг даты выпуска, что в текущей ситуации неприемлемо. Мы не будем описывать все возможные ходы на текущем примере, просто поставим галочку, что уже на этом этапе, перемещая задачи по временной шкале, можно влиять на риски и значительно их снижать. И после?
Мы выявляем риски
На этом этапе необходимо выявить риски, которые есть у команды и проекта в целом, и конкретные проблемы, связанные с выполнением задач, от которых в частности зависят другие команды.
Справа от командной строки создаем листы, на которых перечисляем все известные нам на данный момент риски:
Отлично, у нас есть ряд вопросов, и теперь мы должны решить, что с ними делать. Если на сессии позволяет время, вы можете немного углубиться в проблемы. Если нет, то давайте разбираться, сможем ли мы решить задачи сразу нескольких команд в едином подходе, и кто сможет это сделать.
Давайте сначала попробуем сгруппировать риски.
Очевидно, у нас есть три группы проблем. Один связан с человеческими ресурсами, второй — с анализом и архитектурой, третий — инфраструктурный, например, нет поддержки тестирования.
Идём в ROAM совет.
БРОДИТЬ – аббревиатура букв разрешенная, обладаемая, принятая, ослабленная, где:
Решено – это не риск.
Обладает – на собрании не решили, что делать, или ничего не нужно делать.
Принял – учитывая, мы не можем повлиять на риск в настоящее время.
ослабленный – Требуется ответственное лицо и план по устранению риска.
В нашем случае мы определили сотрудников, которым нужно было обсудить с техническим директором вопрос набора дополнительных людей в команды. Мы также нашли человека, который взял на себя организацию встречи, чтобы контролировать сбор требований и разработку архитектуры. А проблема с ямами уже решена и никаких действий от нас не требуется. Итак, карта ROAM стала выглядеть так:
Встреча примерно в 1:30 и инструмент планирования PI позволили визуализировать проблемы, с которыми сталкиваются взаимозависимые команды, выявить риски и решить, что с ними делать.
Не менее важный шаг – идти в ногу со временем
История с планированием PI будет хорошо работать только в том случае, если вы поддерживаете актуальность информации о зависимостях и рисках. Опыт показывает, что определенные задачи смещаются во времени, появляются новые трудности и риски, связанные с техническими ограничениями или ротацией сотрудников в командах. Таким образом, актуальность данных и регулярность встреч являются основным фактором при планировании ПИ.
Встречи по планированию PI должны проходить не реже одного раза в 2 недели, сразу после окончания спринта, чтобы обновить доску, выявить возникающие риски и решить, как мы можем на них повлиять.
Результаты и выводы
Для нас, как руководителей проектов, использование PI Planning Agile позволило нам составить журнал задач, которые мы синхронизируем и отслеживаем выполнение по регулярным статусам, принимая различные оперативные решения. Мы обновляем матрицу рисков. Мы управляем ожиданиями.
Наша выгода от внедрения PI-планирования заключается в сокращении отклонений в сроках поставки.
Владельцы продукта, в свою очередь, стали более четко понимать график релизов, от кого они зависят и какие результаты могут показать топ-менеджерам.
Прозрачность процессов планирования и сроков является бизнес-преимуществом.
Через некоторое время, вспоминая разработку небольших проектов, я понимаю, что подход PI-планирования вполне может заменить, например, диаграмму Ганта. Инструмент отлично подходит для синхронизации заказов, показывая взаимосвязь между фазами обнаружения и доставки.
Если вы пробовали внедрить PI Board для синхронизации больших или средних команд, я буду рад, если вы поделитесь своим опытом в комментариях.
