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

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
Боли с оценками по срезам⁠: объём, сложность, важность и срочность⁠.

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

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

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

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