PI-планирование: как с его помощью мы выстроили здоровую коммуникацию с заказчиком
Привет! Меня зовут Даша Семенова, я руководитель проектов в AGIMA. Уже пять лет настраиваю процессы у одного большого заказчика. Это еком, ребята продают свою продукцию, а многие из вас ее покупают. А если не покупаете, то точно слышали. В общем, бренд известный и важный для нас.
Но есть нюанс: первые пару лет мы ну никак не могли найти общий язык. Спорили, нервничали, притирались. Однако в итоге мы нашли лекарство, и им оказалось PI-планирование. В этой статье расскажу, почему этот инструмент такой полезный и как мы его используем.
Что такое PI-планирование и зачем оно нам
PI-планирование — это регулярная встреча всех команд проекта и его стейкхолдеров. Она помогает держать фокус на общей цели и синхронизировать действия нескольких команд сразу.
Но пришли мы к PI-планированию не сразу. Чтобы понять, за что мы полюбили этот инструмент, нужно узнать предысторию. Хотя бы кратко. Мы начали работать с компанией X шесть лет назад. И сначала дело не заладилось: мы как будто говорили на разных языках.
Небольшой пример. К нам мог прийти один из стейкхолдеров и сказать, что нам нужно реализовать его фичу. Будучи агентством полного цикла, мы всегда думаем о продукте в целом, а не по отдельным его составляющим. И всегда уточняем, чем подкреплены гипотезы, как фича будет влиять на продукт, в курсе ли остальные стейкхолдеры и т. д. Часто было так, что наши вопросы оставались без ответа, мы бросали всё и делали, а потом другие стейкхолдеры могли прийти и всё отменить. Всё как в басне «Лебедь, рак и щука». Очевидно, нужно было менять подход.
Чтобы починить процесс, нужно что-то менять. А в первую очередь — подход к планированию. Это была наша просьба: мы хотели понимать, что мы делаем и ради чего мы это делаем.
Наши аргументы убедили заказчика изменить подход к общей работе. Вскоре мы внедрили PI-планирование. По сути, это встреча, на которой мы разбираем задачи компании-заказчика: смотрим на ключевые KPI стейкхолдеров, распределяем приоритеты, синхронизируемся с другими аутсорс-командами на продукте.
Как проходит встреча по PI-планированию
Существуют разные подходы к ее проведению. Иногда встречи проходят офлайн. Нам такой вариант не подходит: во-первых, команда распределенная, а во-вторых, нам удобнее сразу работать в таск-трекере. Поэтому мы работаем онлайн.
У работы онлайн и офлайн свои минусы и плюсы. Когда встречи очные, можно заморочиться с оформлением, сделать всё красиво и эффектно. На такую встречу можно позвать всех сотрудников, если компания небольшая, и вместе с ними расставить приоритеты. Но организация такой встречи требует сил и времени. PI-планирование в онлайн-формате позволяет нам быть гибкими и экономить ресурсы. Форматы онлайн-работы тоже бывают разные: можно использовать Miro или Notion. Но нам достаточно таск-трекера.
В нашем таск-трекере есть функция, которая позволяет управлять бэклогом. Тут важно сказать, что PI-планирование идет от бэклога. То есть на этой встрече мы не пополняем нашу доску задачами. Всё это — предварительная работа. На самой встрече мы все вместе распределяем задачи из бэклога по двухнедельным таймбоксам. Во встрече участвуют тимлиды, менеджеры и все стейкхолдеры со стороны заказчика.
В среднем такая встреча длится около трех часов. Задач много, бэклог большой, а команд несколько. Задачи одних могут зависеть от задач других, и поэтому одна из функций PI-планирования — выявить и учесть эти зависимости при наполнении таймбоксов. При этом каждый участник может поделиться своими опасениями и прогнозами по срокам и ресурсам.
Примерно так выглядит наша доска. Здесь можно увидеть структуру планирования. В этом случае PI 12.0, а внутри него таймбоксы: PI 12.1, PI 12.2 и т. д.
Чтобы сэкономить время на встрече, нам присылают ссылку на список задач заранее. Мы с тимлидами проводим тестовый PI: просматриваем задачи и даем каждой оценку. Оценка эта верхнеуровневая — мы не можем заранее сказать, сколько часов уйдет на задачу. Поэтому используем T-shirt-размеры: XS, S, M, L и XL. С помощью этих значений мы, по сути, определяем, сколько релизов займет задача. Релизы у нас еженедельные.
PI-планирование проводит фасилитатор со стороны заказчика. Он демонстрирует экран, и вместе мы проходим список задач на следующий PI. При этом он кратко рассказывает про каждую бизнес-задачу, напоминает о целях компании. А затем мы озвучиваем оценку задачи и вместе обсуждаем ее приоритетность. Одни хотят реализовать фичу как можно скорее, другие готовы ждать.
Когда все заинтересованные люди пришли к консенсусу, мы выбираем, в какой таймбокс отправить задачу. Срочные задачи идут в ближайший, а менее горящие мы сделаем позже. Но важно, что сделаем именно в этом PI-периоде. У нас это полтора месяца.
Так мы проходим весь бэклог, а потом смотрим состав маленьких таймбоксов. Они не должны быть перегруженными или недонагруженными. Мы стремимся к тому, чтобы уравнять их по объемы работу. На этом всё: ближайшие полтора месяца мы полностью понимаем свои задачи, их дедлайны и примерный размер.
Горизонт планирования каждый выбирает для себя сам. Опираться стоит на релиз-менеджмент, количество задач и капасити команды. Нам подходит PI длиной в полтора месяца, и тут мы исходим из интересов заказчика. Он не может строить планы на больший период — такие времена. У кого-то горизонт планирования шире. Кроме того, заказчик генерирует много задач, и они масштабные. Поэтому регулярная синхронизация нам необходима.
Что делать, если что-то идет не по плану
Всегда бывают ситуации, когда после PI-планирования возникают срочные задачи. Или наоборот: задача, попавшая в PI не готова к реализации. Формально мы не можем менять состав PI и добавлять что-то новое. Но обходные пути существуют.
Например, мы уже распланировали PI, но заказчик не успел формализовать какие-то тикеты. В таком случае задача может перейти в следующий PI, но там она окажется в первом таймбоксе, то есть первой по приоритету.
Если же какую-то задачу нужно сделать в текущем PI, заказчик может попросить выделить кого-то из команды. Но в большинстве случаев мы просто перенесем другую, менее важную и срочную задачу в следующий таймбокс или PI.
Преимущества PI-планирования
У нас выделенная команда, и нужно обеспечивать для нее равномерную нагрузку.
Если задачи будут приходить стихийно, то в понедельник вся команда будет скучать, раскладывать пасьянсы или залипать на ролики в YouTube. Зато в четверг всем придется сидеть до полуночи над срочной фичей, работать в экстренном режиме и в итоге наделать кучу ошибок. То и другое одинаково плохо. PI-планирование позволяет грамотно распределить задачи. Причем для выкупной команды это важнее всего. Когда команда сидит без дела — заказчик теряет деньги.
Команды на разных уровнях должны понимать амбиции и цели бизнеса. Это делит ответственность на всех, воодушевляет и вдохновляет.
Представим ситуацию: все решения о развитии продукта принимают топ-менеджеры, а потом просто спускают отдельные задачи департаментам. Люди не понимают, зачем делают ту или иную фичу и в итоге делают ее так, как им кажется правильным. Руководитель видит, что реализация не соответствует общей концепции. Отсюда растут конфликты и бесполезные дискуссии. PI-планирования помогает избежать этого. Теперь все одинаково понимают цель и миссию, все стремятся к общему результату.PI-планирование позволяет распределять ресурсы: понимать, чего хватает, а чего не хватает.
Например, ты понимаешь, что задач на проекте больше, чем людей. Значит, пора выводить новых специалистов. Иногда наоборот: мы можем вовремя заметить, что задач не хватает, люди простаивают. Значит, пора пополнять бэклог или брать в работу задачи, которые давно ждали своего часа.
Кому подходит PI-планирование
Тем, у кого над продуктом работает несколько команд.
Как я писала выше, PI-планирование здорово помогает синхронизироваться. Задачи одних могут зависеть от задач других. Чтобы никто никого не ждал, можно заранее обсудить эти зависимости и расставить приоритеты. Еще это помогает заказчику определить, какая из его команд нагружена, а какая нет. Если кому-то задач не хватает, можно добавить.
А самое главное — все команде на продукте будут одинаково понимать цели бизнеса. Это делает, например, из пяти отдельных команд одну большую, потому что все они идут к одной и той же точке.
Тем, кто строит команду на аутсорсе.
Вернусь к нашему примеру. Мы с заказчиком X работаем на равных. Хотя наша роль в продукте — подрядчики, у нас не принято подходить к задачам дежурно. Мы хотим знать, что делаем и для чего. Однажды к нам пришел новый продакт-оунер от заказчика и попросил как можно скорее внедрить фичу, о которой мы до этого даже не слышали.
Команда заволновалась: откуда такая задача, зачем она и почему мы так спешим. Мы стали задавать вопросы, отказались брать ее в работу без предварительного обсуждения со всеми стейкхолдерами. И в итоге оказалось, что задача влетела в таймбокс без предварительной аналитики. А позже и вовсе выяснилось, что делать ее не нужно.
PI-планирование — это способ сделать из аутсорс-команды полноценную инхаус-команду. Мы будем понимать общий контекст и не позволим ошибки случиться. Можно считать, что это дополнительный фильтр.
Как PI-планирование помогло нам найти общий язык
Когда мы внедрили PI-планирование, половина наших разногласий с заказчиком отпала сама собой. Теперь мы работали в общем контексте. Мы понимали их цели и необходимость каждый отдельной задачи. Они понимали, почему мы задаем вопросы. По сути, нам удалось добиться статуса инхаус-команды — мы погружены в проект так же, как штатные специалисты.
Это хорошо, потому что позволяет нам относиться к задачам бизнеса как к своим собственным. Стейкхолдеры делятся с нами своими KPI, рассказывают о планах на будущее, спрашивают наше мнение по техническим вопросам. Поскольку мы отвечаем как раз за техническую реализацию продукта, нам важно понимать, что ждет проект через месяц или полгода. PI-планирование сказалось на нашем взаимопонимании и качестве работы.
В итоге мы работаем с заказчиком X уже шесть лет. Первоначальные разногласия уже забылись, сейчас мы ладим и строим общие планы. Конечно, PI-планирование было не единственным решением, которого могло нормализовать обстановку. Но оно было основополагающим. Благодаря PI мы вышли на диалог и начали понимать друг друга.
На этом всё. Если есть вопросы — задавайте в комментариях. Было бы интересно узнать и про ваш опыт работы с PI. Какие механики используете? Делитесь опытом.
А еще подписывайтесь на наш телеграм-канал про управление проектами — там мы пишем про инструменты управления, методологии и другие полезные штуки.
