Друзья, всем привет!

Сегодня я расскажу, как совмещаю на работе две роли: продакта и проджекта. Это текстовая версия доклада, который я делал для митапа в Юmoney. В статье я рассказываю, что делаю, как проджект. Описание моих обязанностей как продакта будет в другом посте.

Для начала напомню об опыте: начинал я в 2006 году с управления проетками в собственной веб-студии, потом работал проджектом личного кабинета ФЛ alpari.ru. Был скрам-мастером в alfalab, agile-коучем, тренером и консультантом в СкрамТрек, руководителем группы Agile в S7 Airlines, руководителем проектного офиса в СберЗдоровье. Сейчас я продакт-менеджер в Ренессанс Страховании. Общий стаж управления проектами – 19 лет.

Мой продукт – это веб-приложение для клиентов компании юридических лиц.

Состав продуктовой команды

Продуктовая команда у нас состоит из продакт-менеджера и разработчиков. Это постоянный состав.

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

Совмещение ролей продакта и проджекта

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

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

Вот так выглядят обязанности, которые я выполняю:

Как продакт я делаю:

• Управление дискавери
• Управление стратегией развития продукта.
• Формирование видения продукта.
• Генерация и валидация гипотез.
• Управление процессом дискавери.
• Управление бэклогом продукта.
• Юнит-экономика продукта.
• Рост метрик продукта.

Как менеджер проектов я делаю:

• Управление деливери
• Организация процесса разработки.
• Разделение бэклога на версии продукта.
• Канбан-доска.
• Фокус на результате.
• Карта пользовательских историй.
• Дорожная карта в виде диаграммы Гантта.
• Фасилитация всех встреч.

Сегодня я подробно остановлюсь на обязанностях проджект-менеджера.

Организация процесса разработки по Скраму

Не смотря на то, что я потратил много лет на изучение и применения Канбана, здесь для управления процессом разработки я выбрал Скрам. Этот выбор обусловлен тем, что:

1. Вся команда умеет работать по Скраму, соответственно никого не нужно ему учить.
2. Механика Скрама содержит все необходимые встречи, чтобы процесс разработки был прозрачный.
3. Длина спринта в две недели задает ритм, которому хочется следовать и реализовывать фичи за такой короткий срок.

Разделение бэклога на логические части

Чтобы всё успевать, я разделил бэклог на несколько логический частей. У нас есть бэклог спринта, куда попадают задачи из разных частей бэклога. Есть бэклог MVP. Он содержит все задачи, которые нужно сделать, чтобы отключить старый личный кабинет. Есть бэклог с видением продукта, где мы вдвоем с дизайнером рисуем прототипы будущего ЛК, чтобы тестировать их на пользователях. И есть весь отсальной бэклог куда попадют хотелки от разных стейкхолдеров.

Управление потоком работы

Для управления потоком работы внутри спринта мы сделали вот такую Канбан-доску:

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

Вот так мы проводим дейлики:

1. Идем справа на лево сверху вниз.
2. Проходимся по всем задачам, которые сейчас в работе.
3. Договариваемся, что нужно сделать, чтобы завершить задачи, которые близки к завершению.

Подготовка к Дэйли

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

Разделение рабочего процесса на дискавери и деливери

Как я уже говорил, в обоих ролях я отвечаю за сквозной (end-to-end) процесс разработки. В него входит дискавери и деливери:

Здесь хорошо видно, что я, аналитик и дизайнер делают на этапе анализа, и что делает остальная команда на этапах разработки и тестирования. Сквозной процесс позволяет нам видеть весь путь фичи от начала до конца и управлять им.

Карта пользовательских историй

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

На данном слайде виден набор фичей для MVP и другие фичи в общем бэклоге продукта.

Уточнение бэклога продукта и оценка работ

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

Дорожная карта в MS Project

Оценка в человеко-часах позволяет мне легко перенести оцененную работу в MS Project:

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

Управление ресурсами в MS Project

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

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

Планирование квартала

Планирование квартала также осуществляется в MS Project. Я разбил продукт на версии и заполнил бэклог каждой версии необходимыми задачами. Вот так выглядел наш черновик бэклога на второй квартал:

Мониторинг внешних зависимостей

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

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

Обзор спринта

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

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

Ретроспектива

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

Резюме

Роль проджект менедера помогает мне управлять деливери и командой.

Что хочется подчеркнуть: работа проджекта очень важна. Без нее наша разработка бы просто встала и не двигалась.

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

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

На этом у меня всё,

ваш Игорь.