Построение собственного отдела для управления портфелем проектов OTUS
2026-03-10 23:42 Diff

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

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

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

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

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

Мой план

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • LTV3
  • retention4
  • удовлетворённость пользователей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

Глоссарий       

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

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

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

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

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