Page Content
Работа в условиях неопределённости сопряжена с запросами на изменения нескольких заинтересованных лиц. Возникает конфликт за ресурсы менеджера и команды, возникает конкуренция за влияние на менеджера. Ниже делюсь инструментом приоритизации различной деятельности.
Сбор болей
Важно понимать, что декларируемые запросы могут являтся следствием причин. Фокусируйтесь на болях и причинах, а не способах решения. Решая конкретную задачу порождённую болью, утоляем одну боль или даже часть, решая причину — упреждаете группу болей. На практике это значит, что нужно сгруппировать боли и решить их разом одним набором задач.
«Боль» — универсальная мера запроса, понятная вербализация отсутвующих возможностей. Боль не говорит «Что именно делать?», — даёт понимание скоупа для развития.
Соберите запросы представителей всех возможных групп. Собранные боли породят задачи различного уровня, — это нормально.
Ниже упрощённый вымышленный пример оценки болей и приоритизации деятельности по формированию департамента разработки (все совпадения случайны):
- невнятная модель управления продуктом;
- сложности с пониманием ролей и ценности менеджеров;
- несформулированность ролей сотрудников команды продукта и их зон ответственности;
- вопросы ресурсного планирования (люди, инструменты, деньги, время);
- отсутствие прозрачности проектных целей (цель, план, роль, состав команды, информация, ответственный);
- команда хочет видеть честный план развития продукта;
- нет понимания что и для чего делать;
- непонятно когда задачи будут сделаны, у них неопределённая судьба;
- отсутствуют критерии качества реализации функционала.
Формирование таблицы
Разделите запросы по парам «Процесс — Объект». Если боль относится к нескольким парам «Процесс — Объект» — продублируйте боль.
| Боль | Процесс | Объект |
|---|---|---|
|
— невнятная модель управления продуктом; — сложности с пониманием ролей и ценности менеджеров; — несформулированность ролей сотрудников команды продукта и их зон ответственности; | управление продуктом | команда управления продукта |
|
— вопросы ресурсного планирования (люди, инструменты, деньги, время); — отсутствие прозрачности проектных целей (цель, план, роль, состав команды, информация, ответственный); | управление внедрением | команда внедрения |
|
— команда хочет видеть честный план развития продукта; — нет понимания что и для чего делать; | целеполагание долгосрочное | продукт |
|
— непонятно когда задачи будут сделаны, у них неопределённая судьба; — отсутствуют критерии качества реализации функционала; | целеполагание среднесрочное | команда продукта |
Декомпозиция задач
Опишите задачи для изменения процесса и предложите администратора изменений процесса. Если задачи одной пары «Процесс — Объект» требуется решить двум и более сотрудникам — разделите боли и задачи на сотрудников согласно полномочиям.
| Боль | Процесс | Объект | Цель | Задачи | Исполнитель |
|---|---|---|---|---|---|
|
— невнятная модель управления продуктом; — сложности с пониманием ролей и ценности менеджеров; | управление продуктом | команда управления продукта | Команда управления. DoD: роли однозначно распределены и приняты уполномоченными менеджерами продукта. |
— сформировать ролевую структуру управления продуктом, обозначить ценности и задачи каждой роли; — распределить роли между менеджерами; | Business Owner |
| — несформулированность ролей сотрудников команды разработки продукта и их зон ответственности; | управление разработкой | команда разработки продукта | Ролевая структура. DoD: группы прав соответствуют ролевой и организационной структуре. |
— актуализировать организационную и ролевую структуру; — актуализировать группы прав, отразить их всех инструментах; — обозначить персональные продукты каждого сотрудника; | CSDO |
|
— вопросы ресурсного планирования (люди, инструменты, деньги, время); — отсутствие прозрачности проектных целей (цель, план, роль, состав команды, информация, ответственный); | управление внедрением | команда внедрения | Команды в проектной деятельности. DoD: сформулирована структура проектного направления. |
— актуализировать организационную и ролевую структуры; — актуализировать группы прав, отразить их всех инструментах; — обозначить персональные продукты каждого сотрудника; — сформулировать и донести идею важности общего результата; — реализовать мониторинг командных результатов; | CSDO |
|
— команда хочет видеть честный план развития продукта; — нет понимания что и для чего делать; | целеполагание долгосрочное | команда управления продукта | Управление продуктом как бизнесом. DoD: сформулированы метрики деятельности подразделения как бизнес-единицы; реализован «мониторинг» и демонстрация результатов. |
— организовать мониторинг и анализ бизнес-показателей; — вовлечь менеджеров с функцией развития в мониторинг ключевых бизнес-показателей; | Business Owner |
|
— непонятно когда задачи будут сделаны, у них неопределённая судьба; — отсутствуют критерии качества реализации функционала; | целеполагание среднесрочное | команда управления продукта | Управление продуктом во взаимодействии с командой разработки. DoD: внедрён инструмент приоритизации BackLog. |
— определить квартальные и месячные планы (продуктового) развития продукта; — описать методологию приоритизации задач с понятными критериями; — внедрить инструмент приоритизации деятельности; — изменить паттерн взаимоотношений между владельцем продукта и командой разработки | Product Owner |
|
— непонятно когда задачи будут сделаны, у них неопределённая судьба; — отсутствуют критерии качества реализации функционала; | целеполагание среднесрочное | команда разработки продукта | Управление продуктом во взаимодействии с командой разработки. DoD: внедрён инструмент приоритизации BackLog. |
— внедрить инструмент приоритизации деятельности; — изменить паттерн взаимоотношений между владельцем продукта и командой разработки; | Head of Development |
Реальные таблицы состоят из ≈ 100+ строк с уникальными парами «Процесс — Объект».
Оценка болей и приоритизация деятельности
Далее приступаем к приоритизации деятельности. Под деятельностью понимаем разрешение болей. Боли оценим по следующим критериям: объём, сложность, важность и срочность.
В качестве оценок рекомендую использовать степени 10: 10^0, 10^1, 10^2, 10^3, где
- 10^0 = 1 — незначительно;
- 10^1 = 10 — мало;
- 10^2 = 100 — неопределённо или значительно;
- 10^3 = 1000 — много.
Важно понимать, для принятия управленческого решения не нужна количественная оценка с невероятной точностью, для принятия решения нужна оценка достаточной точности, как правило достаточно качественной оценки.
Зная DoD и задачи можем качественно оценить объём, сложность, важность и срочность утоления боли.
| N | Боль | Процесс | Объект | Цель | Задачи | Исполнитель | Объём | Сложность | Важность | Срочность |
|---|---|---|---|---|---|---|---|---|---|---|
| 001 |
— невнятная модель управления продуктом; — сложности с пониманием ролей и ценности менеджеров; | управление продуктом | команда управления продукта | Команда управления. DoD: роли однозначно распределены и приняты уполномоченными менеджерами. |
— сформировать ролевую структуру управления продуктом, обозначить ценности и задачи каждой роли; — распределить роли между менеджерами; — нанять недостающих менеджеров; | Business Owner | 1000 | 100 | 1000 | 100 |
| 002 | — несформулированность ролей сотрудников команды продукта и их зон ответственности; | управление разработкой | команда разработки продукта | Ролевую структура. DoD: группы прав соответствуют ролевой и организационной структуре. |
— актуализировать организационную и ролевую структуру; — актуализировать группы прав, отразить их всех инструментах; — обозначить персональные продукты каждого сотрудника; | CSDO | 1000 | 10 | 100 | 10 |
| 003 |
— вопросы ресурсного планирования (люди, инструменты, деньги, время); — отсутствие прозрачности проектных целей (цель, план, роль, состав команды, информация, ответственный); | управление внедрением | команда внедрения | Команды в проектной деятельности. DoD: сформулирована структура проектного направления. |
— актуализировать организационную и ролевую структуры; — актуализировать группы прав, отразить их всех инструментах; — обозначить персональные продукты каждого сотрудника; — сформулировать и донести идею важности общего результата; — реализовать мониторинг командных результатов; | CSDO | 1000 | 10 | 100 | 10 |
| 004 |
— команда хочет видеть честный план развития продукта; — нет понимания что и для чего делать; | целеполагание долгосрочное | команда управления продукта | Управление продуктом как бизнесом. DoD: сформулированы метрики деятельности подразделения как бизнес-единицы; реализован «мониторинг» и демонстрация результатов. |
— организовать мониторинг и анализ бизнес-показателей; — вовлечь менеджеров с функцией развития в мониторинг ключевых бизнес-показателей; | Business Owner | 100 | 100 | 100 | 10 |
| 005 |
— непонятно когда задачи будут сделаны, у них неопределённая судьба; — отсутствуют критерии качества реализации функционала; | целеполагание среднесрочное | команда управления продукта | Управление продуктом во взаимодействии с командой разработки. DoD: внедрён инструмент приоритизации BackLog. |
— определить квартальные и месячные планы (продуктового) развития продукта; — описать методологию приоритизации задач с понятными критериями; — внедрить инструмент приоритизации деятельности; — изменить паттерн взаимоотношений между владельцем продукта и командой разработки | Product Owner | 100 | 10 | 10 | 10 |
| 006 |
— непонятно когда задачи будут сделаны, у них неопределённая судьба; — отсутствуют критерии качества реализации функционала; | целеполагание среднесрочное | команда разработки продукта | Управление продуктом во взаимодействии с командой разработки. DoD: внедрён инструмент приоритизации BackLog. |
— внедрить инструмент приоритизации деятельности; — изменить паттерн взаимоотношений между владельцем продукта и командой разработки; | Head of Development | 100 | 10 | 100 | 1 |
Данная таблица — не догма, она не диктует приоритеты, — это инструмент, который помогает приоритизировать деятельность в зависимости от контекста.
Примеры возможных контекстов и дальнейших действий в нашем вымышленном примере с организацией разработки:
- «формализовать продукт» — фильтруем по процессу «управление продуктом» и сортируем по важности и срочности, запускаем в работу задачи с меньшим объёмом и сложностью;
- «сохранить команду» — фильтруем по объекту «команда» и сортируем по срочности, запускаем в работу задачи с различной сложностью и максимальной важностью.
Аналогичные таблицы я строю для приоритизации фичей в продукте и формирования команды.