Приоритизация болей

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

Сбор болей

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

«Боль» — универсальная мера запроса, понятная вербализация отсутвующих возможностей. Боль не говорит «⁠Что именно делать⁠?», — даёт понимание скоупа для развития⁠.

Соберите запросы представителей всех возможных групп⁠. Собранные боли породят задачи различного уровня⁠, — это нормально⁠.

Ниже упрощённый вымышленный пример оценки болей и приоритизации деятельности по формированию департамента разработки (⁠все совпадения случайны⁠):

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

Формирование таблицы

Разделите запросы по парам «Процесс — Объект». Если боль относится к нескольким парам «Процесс — Объект» — продублируйте боль.

Сортированные боли по паре «Процесс — Объект»
Боль Процесс Объект
— невнятная модель управления продуктом;
— сложности с пониманием ролей и ценности менеджеров;
— несформулированность ролей сотрудников команды продукта и их зон ответственности⁠;
управление продуктом команда управления продукта
— вопросы ресурсного планирования (люди, инструменты, деньги, время);
—  отсутствие прозрачности проектных целей (цель, план, роль, состав команды⁠, информация, ответственный);
управление внедрением команда внедрения
— команда хочет видеть честный план развития продукта;
— нет понимания что и для чего делать⁠;
целеполагание долгосрочное продукт
— непонятно когда задачи будут сделаны, у них неопределённая судьба;
— отсутствуют критерии качества реализации функционала;
целеполагание среднесрочное команда продукта
Сортированные боли по паре «Процесс — Объект»

Декомпозиция задач

Опишите задачи для изменения процесса и предложите администратора изменений процесса⁠. Если задачи одной пары «Процесс — Объект» требуется решить двум и более сотрудникам — разделите боли и задачи на сотрудников согласно полномочиям.

Боли с описанными целями и задачами изменений.
Боль Процесс Объект Цель Задачи Исполнитель
— невнятная модель управления продуктом;
— сложности с пониманием ролей и ценности менеджеров;
управление продуктом команда управления продукта Команда управления. 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
Боли с оценками по срезам⁠: объём, сложность, важность и срочность⁠.

Данная таблица — не догма⁠, она не диктует приоритеты, — это инструмент⁠, который помогает приоритизировать деятельность в зависимости от контекста⁠.

Примеры возможных контекстов и дальнейших действий в нашем вымышленном примере с организацией разработки:

  • «формализовать продукт» — фильтруем по процессу «управление продуктом» и сортируем по важности и срочности⁠, запускаем в работу задачи с меньшим объёмом и сложностью⁠;
  • «сохранить команду» — фильтруем по объекту «команда» и сортируем по срочности⁠, запускаем в работу задачи с различной сложностью и максимальной важностью.

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