0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p><em>Проект Константина Гавриша, выпускника курса <a>"Delivery Manager"</a>. </em></p>
1
<p><em>Проект Константина Гавриша, выпускника курса <a>"Delivery Manager"</a>. </em></p>
2
<p><strong>LinkedIn</strong>: <a>https://www.linkedin.com/in/konstantin-havrysh-3a056370/</a></p>
2
<p><strong>LinkedIn</strong>: <a>https://www.linkedin.com/in/konstantin-havrysh-3a056370/</a></p>
3
<p>Представьте. Вы - delivery-менеджер в сфере геймдева.У вас небольшой отдел из 30 программистов, десяти QA, пяти девопсов и пяти тимлидов. Отдел разрабатывает пять проектов, каждым из которых руководит тимлид.</p>
3
<p>Представьте. Вы - delivery-менеджер в сфере геймдева.У вас небольшой отдел из 30 программистов, десяти QA, пяти девопсов и пяти тимлидов. Отдел разрабатывает пять проектов, каждым из которых руководит тимлид.</p>
4
<p>Только этот отдел вам достался в совершенно неработоспособном состоянии. Процессов нет, что и как делают команды - никто не знает, коммуникация между тимлидами - отсутствует, а топ-менеджмент не понимает, что происходит в отделе. Проекты то и дело переживают кризисы, но никто не знает, откуда эти кризисы берутся и почему разрешаются.</p>
4
<p>Только этот отдел вам достался в совершенно неработоспособном состоянии. Процессов нет, что и как делают команды - никто не знает, коммуникация между тимлидами - отсутствует, а топ-менеджмент не понимает, что происходит в отделе. Проекты то и дело переживают кризисы, но никто не знает, откуда эти кризисы берутся и почему разрешаются.</p>
5
<p>Итак, моя цель -<strong>сформировать долгосрочный план по управлению и стабилизации отделов разработки</strong>.</p>
5
<p>Итак, моя цель -<strong>сформировать долгосрочный план по управлению и стабилизации отделов разработки</strong>.</p>
6
<p><strong>Мой план</strong></p>
6
<p><strong>Мой план</strong></p>
7
<ol><li><strong>Знакомство с проектами</strong></li>
7
<ol><li><strong>Знакомство с проектами</strong></li>
8
</ol><ul><li>Ознакомиться с уставом проектов. Если устава нет - составить. Затем наладить связь с теми, кто принимает решения. Сейчас нужно понять, у кого какие возможности, с кем предстоит работать, к кому обращаться.</li>
8
</ol><ul><li>Ознакомиться с уставом проектов. Если устава нет - составить. Затем наладить связь с теми, кто принимает решения. Сейчас нужно понять, у кого какие возможности, с кем предстоит работать, к кому обращаться.</li>
9
</ul><ul><li>Ознакомиться с общими процессами в проектах:<strong>с процессом "доставки"</strong>[продукта], с<strong>процессом постановки задач</strong>, с<strong>методологиями</strong>и используемыми инструментами.</li>
9
</ul><ul><li>Ознакомиться с общими процессами в проектах:<strong>с процессом "доставки"</strong>[продукта], с<strong>процессом постановки задач</strong>, с<strong>методологиями</strong>и используемыми инструментами.</li>
10
</ul><p>Цели первого этапа:</p>
10
</ul><p>Цели первого этапа:</p>
11
<ul><li>понять цели и задачи каждого проекта: как их фиксируют, как доводят до руководителей и команд;</li>
11
<ul><li>понять цели и задачи каждого проекта: как их фиксируют, как доводят до руководителей и команд;</li>
12
<li>понять общий путь релизов внутри проекта: скорее всего пути релизов нет, но лучше всё же проверить.</li>
12
<li>понять общий путь релизов внутри проекта: скорее всего пути релизов нет, но лучше всё же проверить.</li>
13
</ul><p>Всё это пригодится в дальнейшей работе.</p>
13
</ul><p>Всё это пригодится в дальнейшей работе.</p>
14
<p>Так как в проектах нет<strong>процесса доставки и процесса постановки задач</strong>, мы настроим их в первую очередь. В геймдеве распространён "скрамбан", точная документация - редкость, а значит<strong>методология Waterfall не подходит</strong>. Впрочем, внедрять в нестабильную команду чистую Kanban-методологию - тоже не выход.</p>
14
<p>Так как в проектах нет<strong>процесса доставки и процесса постановки задач</strong>, мы настроим их в первую очередь. В геймдеве распространён "скрамбан", точная документация - редкость, а значит<strong>методология Waterfall не подходит</strong>. Впрочем, внедрять в нестабильную команду чистую Kanban-методологию - тоже не выход.</p>
15
<p>Но, с другой стороны, когда команда маленькая и нестабильная,<strong>agile-практики (ретроспективы, итоги спринтов) помогут выявить проблемы</strong>. </p>
15
<p>Но, с другой стороны, когда команда маленькая и нестабильная,<strong>agile-практики (ретроспективы, итоги спринтов) помогут выявить проблемы</strong>. </p>
16
<p>Методологию можно выбрать одну на все проекты, а внедрять - коллегиально, с помощью руководителей. Предположу, что на этом этапе:</p>
16
<p>Методологию можно выбрать одну на все проекты, а внедрять - коллегиально, с помощью руководителей. Предположу, что на этом этапе:</p>
17
<ul><li>получится объединить руководителей в некое подобие горизонтальной структуры</li>
17
<ul><li>получится объединить руководителей в некое подобие горизонтальной структуры</li>
18
<li>в ходе интеграции и коллегиального обсуждения прояснятся какие-то важные подробности. </li>
18
<li>в ходе интеграции и коллегиального обсуждения прояснятся какие-то важные подробности. </li>
19
</ul><p>Однако я бы пока не делегировал обязанности: можно сломать процесс на ранних этапах. </p>
19
</ul><p>Однако я бы пока не делегировал обязанности: можно сломать процесс на ранних этапах. </p>
20
<p><strong>II. Процесс доставки</strong></p>
20
<p><strong>II. Процесс доставки</strong></p>
21
<p><strong>На процесс доставки</strong>можно не тратить много времени на этом этапе: CI и CD1 не всегда работают в геймдеве. Но важно задокументировать такой процесс и назначить ответственного: руководителя или проект-менеджера при поддержке QA. Процесс описываем в виде последовательности действий:</p>
21
<p><strong>На процесс доставки</strong>можно не тратить много времени на этом этапе: CI и CD1 не всегда работают в геймдеве. Но важно задокументировать такой процесс и назначить ответственного: руководителя или проект-менеджера при поддержке QA. Процесс описываем в виде последовательности действий:</p>
22
<p><strong>кто делает - кого информируем</strong></p>
22
<p><strong>кто делает - кого информируем</strong></p>
23
<p>Когда этапы I и II останутся позади, мы уже разработаем:</p>
23
<p>Когда этапы I и II останутся позади, мы уже разработаем:</p>
24
<ul><li>высокоуровневый устав проекта</li>
24
<ul><li>высокоуровневый устав проекта</li>
25
<li>процесс разработки</li>
25
<li>процесс разработки</li>
26
<li>процесс доставки</li>
26
<li>процесс доставки</li>
27
</ul><p><strong>III. Зоны ответственности</strong></p>
27
</ul><p><strong>III. Зоны ответственности</strong></p>
28
<p>Дальше определяем зоны ответственности, выстраиваем матрицу RACI2. При помощи руководителей каждого проекта ещё раз фиксируем основные процессы, выявляем или назначаем ответственных. Процессы в матрицу может вносить как devrel-менеджер, так и руководитель проекта. Скорее всего сами процессы в матрице будут одинаковыми, потому что у проектов одна предметная область - геймдев. </p>
28
<p>Дальше определяем зоны ответственности, выстраиваем матрицу RACI2. При помощи руководителей каждого проекта ещё раз фиксируем основные процессы, выявляем или назначаем ответственных. Процессы в матрицу может вносить как devrel-менеджер, так и руководитель проекта. Скорее всего сами процессы в матрице будут одинаковыми, потому что у проектов одна предметная область - геймдев. </p>
29
<p>На данном этапе детализировать процессы необязательно. Пока что наша задача - высокоуровневая настройка.</p>
29
<p>На данном этапе детализировать процессы необязательно. Пока что наша задача - высокоуровневая настройка.</p>
30
<p>Выделяем в матрице следующие процессы:</p>
30
<p>Выделяем в матрице следующие процессы:</p>
31
<ul><li>формирование состава версии</li>
31
<ul><li>формирование состава версии</li>
32
<li>декомпозиция</li>
32
<li>декомпозиция</li>
33
<li>эстимация</li>
33
<li>эстимация</li>
34
<li>разработка</li>
34
<li>разработка</li>
35
<li>приёмка версии</li>
35
<li>приёмка версии</li>
36
<li>подготовка релиза</li>
36
<li>подготовка релиза</li>
37
<li>релиз</li>
37
<li>релиз</li>
38
<li>пострелизный анализ</li>
38
<li>пострелизный анализ</li>
39
</ul><p><strong>(!)</strong>Мы создали важные документы и процессы, суть которых нужно ясно объяснить членам всех команд. Эту миссию я бы делегировал руководителям проектов. Потом можно оценить, как руководители справились с миссией. </p>
39
</ul><p><strong>(!)</strong>Мы создали важные документы и процессы, суть которых нужно ясно объяснить членам всех команд. Эту миссию я бы делегировал руководителям проектов. Потом можно оценить, как руководители справились с миссией. </p>
40
<p>Если руководители где-то не справились, то, вероятно, проблема в них самих.В конце материала мы ещё вернёмся к этой теме. Но если "с верхами" всё проходит успешно, то мы получаем задокументированные процессы и выявляем ответственных.</p>
40
<p>Если руководители где-то не справились, то, вероятно, проблема в них самих.В конце материала мы ещё вернёмся к этой теме. Но если "с верхами" всё проходит успешно, то мы получаем задокументированные процессы и выявляем ответственных.</p>
41
<p>Дальше можно начинать работу. По умолчанию считаем, что руководители проектов правильно объяснили процессы командам.</p>
41
<p>Дальше можно начинать работу. По умолчанию считаем, что руководители проектов правильно объяснили процессы командам.</p>
42
<p><strong>IV. Состояние проектов</strong></p>
42
<p><strong>IV. Состояние проектов</strong></p>
43
<p>Чтобы оценить состояние проектов, понадобятся метрики. Метрики стоит выделять, исходя из уставов и текущего статуса проектов. Для геймдева характерны такие продуктовые метрики:</p>
43
<p>Чтобы оценить состояние проектов, понадобятся метрики. Метрики стоит выделять, исходя из уставов и текущего статуса проектов. Для геймдева характерны такие продуктовые метрики:</p>
44
<ul><li>LTV3</li>
44
<ul><li>LTV3</li>
45
<li>retention4</li>
45
<li>retention4</li>
46
<li>удовлетворённость пользователей</li>
46
<li>удовлетворённость пользователей</li>
47
</ul><p>Также можно выделить проектные метрики:</p>
47
</ul><p>Также можно выделить проектные метрики:</p>
48
<ul><li>попадание в сроки </li>
48
<ul><li>попадание в сроки </li>
49
<li>процент "вернувшихся" задач</li>
49
<li>процент "вернувшихся" задач</li>
50
<li>процент багов, попавших в продакшн</li>
50
<li>процент багов, попавших в продакшн</li>
51
<li>общая скорость движения к цели (не в рамках спринта)</li>
51
<li>общая скорость движения к цели (не в рамках спринта)</li>
52
</ul><p>Все эти цели, так или иначе, можно связать с основными направлениями в разработке проектов, и, частично, с матрицей RACI. А значит после нескольких спринтов можно получить уже "живые" метрики и проанализировать, какие из них просаживаются. </p>
52
</ul><p>Все эти цели, так или иначе, можно связать с основными направлениями в разработке проектов, и, частично, с матрицей RACI. А значит после нескольких спринтов можно получить уже "живые" метрики и проанализировать, какие из них просаживаются. </p>
53
<p><strong>Просадка продуктовых метрик </strong></p>
53
<p><strong>Просадка продуктовых метрик </strong></p>
54
<p>Если просаживаются продуктовые метрики, а существенных багов на проде нет, то скорее всего проблема в общем видении целей проектов. То есть продукт не подходит аудитории. </p>
54
<p>Если просаживаются продуктовые метрики, а существенных багов на проде нет, то скорее всего проблема в общем видении целей проектов. То есть продукт не подходит аудитории. </p>
55
<p><strong>Просадка проектных метрик</strong></p>
55
<p><strong>Просадка проектных метрик</strong></p>
56
<p> Вероятно проблема в команде. Но сначала убедимся, что процессы не нарушаются. Если нарушаются, выявляем конкретных нарушителей с помощью руководителей направления. Если нарушений нет, значит у команды не хватает компетенций или мотивации. </p>
56
<p> Вероятно проблема в команде. Но сначала убедимся, что процессы не нарушаются. Если нарушаются, выявляем конкретных нарушителей с помощью руководителей направления. Если нарушений нет, значит у команды не хватает компетенций или мотивации. </p>
57
<p>К тому, как взять<strong>на контроль</strong>нарушителей, мы тоже вернёмся в конце.</p>
57
<p>К тому, как взять<strong>на контроль</strong>нарушителей, мы тоже вернёмся в конце.</p>
58
<p><strong>Провалы руководителей, недоверие к руководителям</strong></p>
58
<p><strong>Провалы руководителей, недоверие к руководителям</strong></p>
59
<p>Самый плохой вариант. Я бы предложил уведомить о проблеме высшее руководство. Дальше - пытаться понять причины провалов руководителя. Тут нам поможет, например, оценка мотивации или оценка по Адизесу. Все решения принимаем вместе с высшим руководством, то есть становимся посредниками между командным руководителем и топ-менеджментом. </p>
59
<p>Самый плохой вариант. Я бы предложил уведомить о проблеме высшее руководство. Дальше - пытаться понять причины провалов руководителя. Тут нам поможет, например, оценка мотивации или оценка по Адизесу. Все решения принимаем вместе с высшим руководством, то есть становимся посредниками между командным руководителем и топ-менеджментом. </p>
60
<p>Итак, на текущем этапе мы:</p>
60
<p>Итак, на текущем этапе мы:</p>
61
<ul><li>настроили базовые процессы</li>
61
<ul><li>настроили базовые процессы</li>
62
<li>поняли, как обстоят дела с метриками: есть ли просадки и почему</li>
62
<li>поняли, как обстоят дела с метриками: есть ли просадки и почему</li>
63
<li>поняли, каким руководителям доверять, а каким - нет</li>
63
<li>поняли, каким руководителям доверять, а каким - нет</li>
64
</ul><p><strong>Контроль за нарушениями</strong></p>
64
</ul><p><strong>Контроль за нарушениями</strong></p>
65
<p><strong>Просадка продуктовых метрик.</strong>Обычно за продуктовые метрики отвечают сотрудники от продюсера и выше. Это очень высокий уровень. Собираем аргументы в виде метрик и обсуждаем с отвественными. Причин у таких просадок - много: неправильно проанализировали рынок, неправильно постановили глобальные цели проекта, неправильно объяснили цели команде и проч. Окончательное решение проблемы здесь за топ-менеджментом и продюсерами. Мы только выступаем посредниками и, возможно, защитниками команды (не проекта).</p>
65
<p><strong>Просадка продуктовых метрик.</strong>Обычно за продуктовые метрики отвечают сотрудники от продюсера и выше. Это очень высокий уровень. Собираем аргументы в виде метрик и обсуждаем с отвественными. Причин у таких просадок - много: неправильно проанализировали рынок, неправильно постановили глобальные цели проекта, неправильно объяснили цели команде и проч. Окончательное решение проблемы здесь за топ-менеджментом и продюсерами. Мы только выступаем посредниками и, возможно, защитниками команды (не проекта).</p>
66
<p><strong>Просадка проектных метрик.</strong>Сначала пытаемся разобраться в причинах. Собираем личные метрики и оцениваем их с помощью HR. Возможно стоит провести несколько встреч с сотрудником, дать ему высказаться. Дальше действуем по обстоятельствам. Если проблема в мотивации, повышаем её, опираясь на тип личности. Если в навыках, решаем с руководителем, что делать: увольнять сотрудника или менять нагрузку. </p>
66
<p><strong>Просадка проектных метрик.</strong>Сначала пытаемся разобраться в причинах. Собираем личные метрики и оцениваем их с помощью HR. Возможно стоит провести несколько встреч с сотрудником, дать ему высказаться. Дальше действуем по обстоятельствам. Если проблема в мотивации, повышаем её, опираясь на тип личности. Если в навыках, решаем с руководителем, что делать: увольнять сотрудника или менять нагрузку. </p>
67
<p>Бывает, что сотрудник - ценен для проекта. Тогда с помощью руководителей проектов и подразделений мы выстраиваем индивидуальный план развития, чтобы улучшить показатели.</p>
67
<p>Бывает, что сотрудник - ценен для проекта. Тогда с помощью руководителей проектов и подразделений мы выстраиваем индивидуальный план развития, чтобы улучшить показатели.</p>
68
<p><strong>Резюме</strong></p>
68
<p><strong>Резюме</strong></p>
69
<ul><li><strong>Самостоятельно разрабатываем высокоуровневые настройки:</strong>устав, методологии. </li>
69
<ul><li><strong>Самостоятельно разрабатываем высокоуровневые настройки:</strong>устав, методологии. </li>
70
<li><strong>Знакомимся с командой</strong>, чтобы в дальнейшем делегировать. </li>
70
<li><strong>Знакомимся с командой</strong>, чтобы в дальнейшем делегировать. </li>
71
<li><strong>Настраиваем основные процессы производства.</strong></li>
71
<li><strong>Настраиваем основные процессы производства.</strong></li>
72
<li><strong>Устанавливаем метрики.</strong>На основе метрик ищем проблемные моменты, решаем их исходя из контекста. Важно фиксировать процессы, информировать команду, зарабатывать доверие. </li>
72
<li><strong>Устанавливаем метрики.</strong>На основе метрик ищем проблемные моменты, решаем их исходя из контекста. Важно фиксировать процессы, информировать команду, зарабатывать доверие. </li>
73
</ul><p><strong>Глоссарий </strong> </p>
73
</ul><p><strong>Глоссарий </strong> </p>
74
<p>CI и CD1 - непрерывная интеграция (Continuous Integration) и непрерывная доставка (Continuous Delivery)</p>
74
<p>CI и CD1 - непрерывная интеграция (Continuous Integration) и непрерывная доставка (Continuous Delivery)</p>
75
<p>RACI2, матрица RACI (Responsible, Accountable, Consulted, Informed) - методика распределения полномочий и ролей в бизнес-процессах</p>
75
<p>RACI2, матрица RACI (Responsible, Accountable, Consulted, Informed) - методика распределения полномочий и ролей в бизнес-процессах</p>
76
<p>LTV3 - Lifetime Value, прогноз дохода, который бизнес получит от отношений с клиентом</p>
76
<p>LTV3 - Lifetime Value, прогноз дохода, который бизнес получит от отношений с клиентом</p>
77
<p>retention4 - коэффициент удержания клиентов. Применяется в маркетинге</p>
77
<p>retention4 - коэффициент удержания клиентов. Применяется в маркетинге</p>
78
<p>Также, возможно, вам будет интересен<a>еще один проект</a>на аналогичную тему.</p>
78
<p>Также, возможно, вам будет интересен<a>еще один проект</a>на аналогичную тему.</p>
79
79