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

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

Сбор болей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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