Как вы выделяли важное в последнее время? Опишите ваш метод приоритизации проектов и задач с использованием материала раздела.
Для начала стоит сказать что я выделяю важное на двух системых уровнях: уровень команд (я менеджер продукта, у меня три команды разработки) и личный уровень.
Мысль в сторону:
Здесь интересный момент. Является ли мой личный уровень → уровень, на котором я работаю я (т.е. уровень сотрудник) … (здесь я хотел написать нижележащим/меньшим по отношению к команде, но что такое “нижележащим”? лучше используем термины из раздела) меньшим масштабом крупности, чем уровень команды? Да, совершенно точно. Факт руководительства этих команд описывает отношения подчинения/распоряжения ресурсами.
В таком случае, мне нужно описать метод выделения важного на двух уровнях - команда и сотрудник (я).
Уровень “команда”.
Мысль в сторону 2:
Нет, все-таки, дребезжит у меня что-то 
Агент, исполяющий роль менеджера команды, к какому уровню/масштабу крупности относится? Сам по себе он является сотрудником. Но вместе с командой - он принадлежит уровню команда. Окей, остановимся на этом, отношу себя при приритизации работ для команды к уровню - команда.
Последний уровень приоритизация работ (т.е. выбор того, что берем в спринт, а что нет) происходит у нас командно, на общей встрече под названием планирование спринта.
Входами у метода планирования спринта являются:
- Незавершенная работа с предыдущего спринта
- Расчет ресурсов команды на следующий спринт (вычисляемое из доступности людей на следующий спринт)
- План работ (роадмап) команды на ближайшие 2-3 спринта (обновляется раз в месяц)
То есть основной вход для выбора приоритетов задач командой на следующий спринт - план работ на следующие 2-3 спринта.
Кто составляет этот план и каким образом?
Этот план составляют агенты-владельцы следующих ролей:
- Менеджер продукта
- Менеджер проектов
- Операционный менеджер команды разработки (тим лид)
- Бизнес-системные аналитики
Входами у метода планирования работ на ближайшие 2-3 спринта (обновление роадмапа) являются:
- Договоренности (считай, приоритеты) с вышестоящими менеджерами (руководители департамента) - вышестоящий уровень крупности
- Запросы от других команд (команд в окружении), т.е. тот же масштаб крупности что и наша команда
- Описания продуктовых проблем и их серьезность/severity, т.е. приоритизация “внутри себя”
Стоп. Здесь я осознал, что я перемешал (т.е. описываю одновременно) методы планирования работ и методы выбора важного. Работы планируются исходя из (1) списка приоритетов (разметки работ по важности), (2) доступных ресурсов, (3) примерной оценки трудозатрат на работы.
Поэтому предыдующий абзац “Входами у метода планирования работ” стоит переименовать на “Входами у метода выбора важного” (периодичность обновления важности - раз в 4 недели)
Т.е. фактически метод выбора важного для уровня “команда” учитывает и приоритеты из большего масштаба крупности (позразделение), и из этого же самого масштаба крупности (“команда” собственная или стронняя).
Являтеся ли это проблемой? Исходя из рассуждений в разделе - да, т.к. приоритизация на уровне “команда” может произойти в сторону “лоббиста” определенной команды.
Как этого можно избежать?
- А) Всю приоритизацию проводить через уровень выше “поздразделение”. Неэффективный метод: (1) получаем бутылочное горлышко в виде менеджера подразделения, (2) приоритеты будут выставлять под влиянияем искажений/bias менеджера подразделения.
- Б) Необходимо каждый запрос от других команд, а также описание продуктовых проблем, трассировать на объекты, заранее приоритизированные на уровне выше команды. Т.е. на характеристики продукта, приоритизированные менеджерами подразделения (простыми словами - метрики). Например, запрос от других команд / продуктовая проблема affects area: (client retention, client acquisition, regulatory compliance, etc.).
В случае Б выбор будет всегда более рациональным.
Каким образом применить это на практике? Есть ли у нас вот такой список приоритизированных метрик (пока что используем это слово, но я чувствую что оно не самое подходящее)? Нет. Смогу ли я каждый из них трассировать? Думаю да.
Итого
Описал метод выбора важного на уровне команда. Поразмышлял на тему как оптимизировать выбор. Получится ли это применить на практике - не уверен, требуется дальнейшая работа по проектированию методов выбора важного.