Построение собственного отдела для управления портфелем проектов

Проект Константина Гавриша, выпускника курса «Delivery Manager». 

LinkedIn: https://www.linkedin.com/in/konstantin-havrysh-3a056370/

Представьте. Вы – delivery-менеджер в сфере геймдева.
У вас небольшой отдел из 30 программистов, десяти QA, пяти девопсов и пяти тимлидов. Отдел разрабатывает пять проектов, каждым из которых руководит тимлид.

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

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

Мой план

1. Знакомство с проектами

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

• Ознакомиться с общими процессами в проектах: с процессом «доставки» [продукта], с процессом постановки задач, с методологиями и используемыми инструментами.

Цели первого этапа:

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

Всё это пригодится в дальнейшей работе.

Так как в проектах нет процесса доставки и процесса постановки задач, мы настроим их в первую очередь. В геймдеве распространён «скрамбан», точная документация – редкость, а значит методология Waterfall не подходит. Впрочем, внедрять в нестабильную команду чистую Kanban-методологию – тоже не выход.

Но, с другой стороны, когда команда маленькая и нестабильная, agile-практики (ретроспективы, итоги спринтов) помогут выявить проблемы. 

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

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

Однако я бы пока не делегировал обязанности: можно сломать процесс на ранних этапах. 

II. Процесс доставки

На процесс доставки можно не тратить много времени на этом этапе: CI и CD¹ не всегда работают в геймдеве. Но важно задокументировать такой процесс и назначить ответственного: руководителя или проект-менеджера при поддержке QA. Процесс описываем в виде последовательности действий:

кто делает – кого информируем

Когда этапы I и II останутся позади, мы уже разработаем:

• высокоуровневый устав проекта
• процесс разработки
• процесс доставки

III. Зоны ответственности

Дальше определяем зоны ответственности, выстраиваем матрицу RACI². При помощи руководителей каждого проекта ещё раз фиксируем основные процессы, выявляем или назначаем ответственных. Процессы в матрицу может вносить как devrel-менеджер, так и руководитель проекта. Скорее всего сами процессы в матрице будут одинаковыми, потому что у проектов одна предметная область – геймдев. 

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

Выделяем в матрице следующие процессы:

• формирование состава версии
• декомпозиция
• эстимация
• разработка
• приёмка версии
• подготовка релиза
• релиз
• пострелизный анализ

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

Если руководители где-то не справились, то, вероятно, проблема в них самих.
В конце материала мы ещё вернёмся к этой теме. Но если «с верхами» всё проходит успешно, то мы получаем задокументированные процессы и выявляем ответственных.

Дальше можно начинать работу. По умолчанию считаем, что руководители проектов правильно объяснили процессы командам.

IV. Состояние проектов

Чтобы оценить состояние проектов, понадобятся метрики. Метрики стоит выделять, исходя из уставов и текущего статуса проектов. Для геймдева характерны такие продуктовые метрики:

• LTV³
• retention⁴
• удовлетворённость пользователей

Также можно выделить проектные метрики:

• попадание в сроки 
• процент «вернувшихся» задач
• процент багов, попавших в продакшн
• общая скорость движения к цели (не в рамках спринта)

Все эти цели, так или иначе, можно связать с основными направлениями в разработке проектов, и, частично, с матрицей RACI. А значит после нескольких спринтов можно получить уже «живые» метрики и проанализировать, какие из них просаживаются. 

Просадка продуктовых метрик 

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

Просадка проектных метрик

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

К  тому, как взять на контроль нарушителей, мы тоже вернёмся в конце.

Провалы руководителей, недоверие к руководителям

Самый плохой вариант. Я бы предложил уведомить о проблеме высшее руководство. Дальше – пытаться понять причины провалов руководителя. Тут нам поможет, например, оценка мотивации или оценка по Адизесу. Все решения принимаем вместе с высшим руководством, то есть становимся посредниками между командным руководителем и топ-менеджментом. 

Итак, на текущем этапе мы:

• настроили базовые процессы
• поняли, как обстоят дела с метриками: есть ли просадки и почему
• поняли, каким руководителям доверять, а каким – нет

Контроль за нарушениями

Просадка продуктовых метрик. Обычно за продуктовые метрики отвечают сотрудники от продюсера и выше. Это очень высокий уровень. Собираем аргументы в виде метрик и обсуждаем с отвественными. Причин у таких просадок – много: неправильно проанализировали рынок, неправильно постановили глобальные цели проекта, неправильно объяснили цели команде и проч. Окончательное решение проблемы здесь за топ-менеджментом и продюсерами. Мы только выступаем посредниками и, возможно, защитниками команды (не проекта).

Просадка проектных метрик. Сначала пытаемся разобраться в причинах. Собираем личные метрики и оцениваем их с помощью HR. Возможно стоит провести несколько встреч с сотрудником, дать ему высказаться. Дальше действуем по обстоятельствам. Если проблема в мотивации, повышаем её, опираясь на тип личности. Если в навыках, решаем с руководителем, что делать: увольнять сотрудника или менять нагрузку. 

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

Резюме

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

---

Глоссарий       

CI и CD¹ – непрерывная интеграция (Continuous Integration) и непрерывная доставка (Continuous Delivery)

RACI², матрица RACI (Responsible, Accountable, Consulted, Informed) – методика распределения полномочий и ролей в бизнес-процессах

LTV³ – Lifetime Value, прогноз дохода, который бизнес получит от отношений с клиентом

retention⁴ – коэффициент удержания клиентов. Применяется в маркетинге

Также, возможно, вам будет интересен еще один проект на аналогичную тему.