Каждый ответственный сотрудник в вашей компании, вероятно, имеет собственное мнение о том, что является наибольшим приоритетом бизнеса. Но какой проект на самом деле должен быть приоритетным? К счастью, есть отличные методы, которые помогут определить приоритет задач в бэклоге продукта.

Менеджер по продукту: безумству храбрых поём мы песню

Взгляните на менеджера по продукту как на невоспетого героя, который должен «пасти котов» и подталкивать всех по каждой задаче, чтобы обеспечить соблюдение сроков, закрытие задач, развёртывание кода и выпуск продуктов. Речь идёт не только о том, чтобы все были сосредоточены и уложились в срок, но и об обеспечении достаточной гибкости и упорства в работе над задачами при достижении целей в ситуации, когда требования заказчиков и пользователей меняются. Любой хороший менеджер по продукту должен отлично знать свой продукт, но как он решает, на чем и когда сосредоточиться?

В этой статье рассматриваются различные методы приоритизации. Тут не преследуется цель продвижения какого-то конкретного фреймфорка, подхода или идеологии. Это обзор различных способов интерпретации и расстановки приоритетов в бэклоге продукта.

Что такое бэклог продукта?

Бэклог продукта – это список задач, необходимых для выполнения стратегических планов дорожной карты развития продукта. Бэклог предназначен для того, чтобы приземлить бизнес-идеи на практические задачи, включающие инструкции что и кому делать. В то время как дорожная карта развития продукта представляет собой общую картину, описывая высокоуровневые цели и стратегии, предназначенные для ЛПР, бэклог продукта – это список конкретных дел, составленный (возможно) для тех, кто выполняет основную часть работы: продуктовой команды и разработчиков.

Какие задачи содержатся в бэклоге продукта?

Задачи в продуктовом бэклоге различаются в зависимости от особенностей работы команды. Те, кто использует идеологию Скрам, могут обратиться к формату пользовательских историй (user story). При таком подходе задачи в бэклог продукта ставятся с точки зрения конечного пользователя. Например:

«Как (тип пользователей) я хочу (чего они хотят достичь), чтобы я мог (результат, которого они хотят достичь)»

Вне зависимости от выбранного способа описания, типичные задачи или истории обычно включают:

• Исправление ошибок
• Инфраструктурные и функциональные обновления
• Разработка новой функциональности
• Изменения существующей функциональности
• Устранение технического долга
• Рефакторинг

Важность приоритезации бэклога

Бэклог продукта должен представлять собой список всех связанных с продуктом задач, которые необходимо выполнить команде, с указанием исполнителей и сроков. Проблема в том, что список не является исчерпывающим. Он должен быть гибким и обязательно будет меняться в зависимости от обстоятельств. Например, быстрый выпуск продукта конкурентом может означать, что теперь нужно выпустить обновление продукта раньше, чем ожидалось, чтобы не утратить преимущества, а это означает, что всё остальное откладывается.

Даже такие события, как презентации на выставках (виртуальных или очных), могут означать, что команды меняют приоритет в сторону задач, необходимых для продаж и маркетинга, в надежде заполучить новых клиентов. Но возникает проблема, когда список задач продолжает пополняться, а менеджер по продукту изо всех сил пытается поддержать темп, необходимый для просмотра и организации всех задач по предпочтениям и приоритетам. Эффективный бэклог продукта должен быть хорошо структурирован, организован так, чтобы его можно было легко прочитать и понять, а также должен соответствовать актуальным стратегическим потребностям бизнеса.

5 вещей, которые никто не упоминает

Есть много людей, которые зарабатывают деньги на организации команд разработчиков и захотят продать вам свой «безотказный» метод. Ещё есть множество ресурсов, привязанных к службам, которые вы уже используете. Но хотелось бы отметить несколько важных моментов. Независимо от того, какие методы управления бэклогом продукта вы выберете, для того чтобы они заработали, необходимо пять вещей:

1. Разумный уровень функциональности у компании. Высокая текучесть кадров или прогулы затрудняют выполнение задач. Однажды я работала в компании, где в моем отделе за пять месяцев было пять разных менеджеров. И каждый раз, когда приходил новый, менялись задачи и приоритеты.
2. Уважение и авторитет менеджера по продукту. Это означает, что, когда он устанавливает крайние сроки или организует очередь задач, это воспринимается так, как если бы это проделал сам генеральный директор (или, если вы фрилансер, человек, который платит вам зарплату).
3. ЛПР / высшее руководство достаточно делегируют ответственность на менеджера по продукту и хороших коммуникаторов – если что-то нужно изменить, они могут сформулировать причины, а не просто понизить рейтинг.
4. Члены команды обладают соответствующей квалификацией для выполнения задач (или компания готова нанимать более квалифицированных фрилансеров).
5. Существует процесс управления техническим долгом, особенно если он замедляет работу команд, вызывает ошибки и задерживает выпуск новой функциональности. Если технический долг не является приоритетом, будет сложнее сократить бэклог продукта или выполнять задачи.

Методы приоритизации бэклога

1. Матрица «Влияние/усилия» (Impact Effort).

Задачи распределяются на матрице с двумя осями: уровень усилий и уровень влияния. Это легко проделать на собраниях с использованием доски и стикеров. Есть также специальные шаблоны в распространённых ресурсах Edraw, Miro и SketchBubble. Это упражнение хорошо проводить с участием членов продуктовой команды из разных подразделений, поскольку оно даёт возможность противопоставить разные приоритеты друг другу.

Дополнительно можно познакомиться с хорошим критичным анализом этого метода от Итамара Гилада.

2. Ранжирование по стеку

Повсеместно распространённый метод – это ранжирование по стеку. Составляется список элементов, которым требуется приоритезация, затем ранжируется от наиболее важных (верхняя часть стопки) к наименее важным (нижняя часть стопки). Получаем стек задач для обслуживания.

Преимуществ: номер один может быть только один. Этот метод гарантирует, что в поставке всегда максимальная ценность, и команда никогда не работает над малоценными задачами. Кроме того, им легко пользоваться. Недостатки: чаще всего приоритеты определяются субъективно, на основе интуиции, подкреплённой некоторой аналитикой.

3. Метод MoSCoW

Метод MoSCoW – альтернатива расстановке приоритетов в терминах «Важно/Нужно/Хочется» (High/Medium/Low).

Четыре категории:

• Должны сделать (Must have): эти задачи критически важны для поставки в текущем периоде для достижения целей. Если хотя бы одно обязательное требование не выполнено, выполнение этапа следует считать неудачным.
• Нужно сделать (Should have): важно, но не критично для поставки.
• Могли бы сделать (Could have): эти задачи желательны, но не обязательны и должны иметь приоритет только в том случае, если другие задачи уже выполнены.
• Можно обойтись (Won’t have): эти задачи наименее критичны.

Проблема с методом MoSCoW заключается в том, что он не помогает, если необходимо выбрать среди нескольких задач в списке обязательных. Кроме того, легко увидеть, что новые версии имеют приоритет над рефакторингом, если рефакторинг всегда делегируется категориям «могли бы сделать» или «можно обойтись».

4. Средневзвешенная кратчайшая работа выполняется первой

Принцип средневзвешенного кратчайшего задания (Weighted Shortest Job First, WSJF) используется в гибкой разработке программного обеспечения для определения приоритетов элементов работы на основе принципов бережливого производства. Определение достигается путём деления стоимости задержки (Cost of Delay) на время, необходимое для выполнения задачи.

Есть много разных математических способов вычислить это, но эмпирический способ – подумать о том, что потеряет компания в целом, если что-то не будет сделано или цель не будет достигнута. Это может означать финансовую и репутационную потерю, невозможность перепродать связанный продукт или узкие места, такие как задержка связанных релизов. Конечно, всегда будет определённый уровень субъективности, но, возможно, меньший, чем попытка определить, какая задача для пользователей является наиболее важной.

5. Приоритезация на основе данных

Возможно, вы поддерживаете коммуникации с отделом продаж, чтобы получить обратную связь через отзывы клиентов, или следите за настроениями пользователей в социальных сетях, чтобы понять, с какими проблемами они сталкиваются. Но есть ещё один инструмент, который помогает понять поведение клиентов, включая потоки пользователей и их болевые точки: данные. Использование прикладных инструментов для количественной оценки экономических последствий реализации задач может помочь при их приоритизации.

Хорошо, мы расставили приоритеты для нашего бэклога. Что теперь?

Примите во внимание платформы, которые уже используются для общения коллектива и управления задачами и проектами. Не увеличивайте когнитивную нагрузку команды, заставляя использовать ещё один инструмент организации рабочего процесса. Это тем более важно для удалённых команд, особенно работающих в разных часовых поясах, т. е. асинхронно. Интегрируйте бэклог продукта в инструменты, которые уже используются, такие как Jira , Trello, Monday.com, Asana, Stepsize и т.п.

Автор Cate Lawrence
Источник

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы