Кросс-функциональный фреймворк приоритизации для крупного бизнеса

Розничный гигант сократил время планирования разработки в 9 раз (с 18 до 2 недель) и увеличил в 5 раз количество важных фич без расширения команды разработки.

Ключ? Внедрение кросс-функциональной приоритизации.

Эта впечатляющая эффективность открыла неожиданные выгоды помимо скорости и влияния.

Скачать статью: [PDF]Попробуйте шаблон с бесплатным аккаунтом Prioplan: [SignUp]

Неожиданные выгоды

«Наконец у нас появился единый процесс принятия решений», — сказал разработчик. «Как будто включили свет — понятные приоритеты, никаких бесконечных дискуссий».

«Каждый приоритет на 100% оценен и согласован всеми, а не просто основан на интуиции или силовой игре. Теперь мы доверяем системе».

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

«Мы теперь общаемся. Команды разработки и бизнеса. Это совершенно новый уровень понимания и уменьшения конфликтов».

«Я нашёл задачу, спрятанную в бэклоге Jira, которая помогла повысить выкуп заказов на X процентных пункта; при нашем объёме это означает миллионы дополнительной выручки. Эта жемчужина осталась бы скрытой, если бы я не оценил задачи через наш новый процесс приоритизации».

О компании

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

Несогласованные приоритеты истощали ресурсы разработки

Отдел разработки ритейлера столкнулся с непростой реальностью:

• Перегрузка: Каждые шесть месяцев они получали 2000+ запросов, что намного превышало возможности и подчёркивало необходимость предельно чёткой фокусировки.

• Рост или эффективность: Масштабирование команды разработки — не панацея. Эффективность капитала — король, особенно в турбулентные времена.

• Чёрная дыра переговоров: Выделение 18 недель (4,5 месяца) в год на обсуждение и согласование приоритетов означало плавание в море неопределённости относительно того, что важно, просто, сложно или ещё актуально.

• Зыбучие пески: К моменту релиза быстро меняющаяся бизнес-среда часто делала задачи устаревшими. Заинтересованные лица нередко обнаруживали, что финальный продукт больше не соответствует их потребностям, подчёркивая срочность процесса приоритизации, адаптирующегося в реальном времени.

• Нереализованный потенциал: Ценные ресурсы разработки не тратились на критичные для бизнеса задачи.

Цели приоритизации:

1. Минимизировать издержки планирования.

2. Обеспечить лазерную фокусировку мощности разработки на том, что действительно двигает бизнес.

От таблиц к тупику: почему WSJF не справился

Начиная цифровую трансформацию, ритейлер изначально выбрал фреймворк Weighted Shortest Job First (WSJF), используя таблицы для приоритизации. Однако этот метод не оправдал себя:

• Три месяца были потрачены без финализации приоритетов.

• Широкие субъективные критерии: WSJF основан на общих концепциях вроде «риск», «размер задачи» и «критичность», которые могут интерпретироваться по-разному разными ролями и отделами. Эта субъективность привела к несогласованности и разочарованиям, когда ценные сложные задачи упускались в пользу кажущихся «проще».

• Быстрые победы против реальной ценности: Недостатки WSJF в растущем бизнесе. Формулы, вроде деления на трудозатраты, могли приоритизировать небольшие незначительные задачи вместо стратегически критичных. Это создало бэклог, заполненный быстрыми победами, игнорируя важные, но сложные проекты вроде юридических и комплаенс-задач.

• Болото таблиц: Таблицы быстро превратились в кошмар — медленные, подверженные ошибкам и требующие постоянных ручных обновлений. Поддержка согласованности данных с Jira стала утомительным упражнением копипаста, мешая эффективности и прозрачности.

Основные выводы из ограничений WSJF:

1. WSJF и подобные фреймворки не подходят для сложности крупных организаций.

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

Этап I: Единая приоритизация вместо изолированного принятия решений

После первоначальных трудностей с WSJF розничный гигант понял, что нужен принципиально другой подход.

Ключевое понимание

Самым большим виновником был не сам фреймворк, а традиционный изолированный процесс принятия решений.

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

Их радикальное решение: внедрить процесс «Summitinals». Вместо изолированных решений они пригласили всех к столу приоритизации. Были услышаны все голоса — от дизайнеров до инженеров, маркетологов, юристов, поддержки, логистики и даже некоторых менеджеров розничных магазинов. Это создало более короткий цикл обратной связи, обеспечивая согласованность всех и раннее выявление потенциальных препятствий.

Преимущества единой приоритизации

Переход к целостному процессу приоритизации не только упростил принятие решений, но и принёс значительные преимущества:

• Проверка актуальности: Обеспечивает актуальность Задач, подтверждая, что решаемые проблемы остаются приоритетами для бизнеса.

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

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

Этот подход создаёт культуру прозрачности и сотрудничества, где каждый голос услышан, и каждое решение проверено на влияние и актуальность.

«Никто в бизнес- и разработке не сомневался, что задачи, выбранные для разработки, были самыми приоритетными и значимыми для бизнеса». Руководитель центра компетенций методологии продуктового подхода

Этап II: Создание кастомного кросс-функционального фреймворка приоритизации

Разрабатывая уникальный фреймворк приоритизации, ритейлер принял принцип, позволяющий истинное кросс-функциональное сотрудничество. Ссылки на шаблон — в конце статьи.

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

Золотое правило

Лучший фреймворк приоритизации отражает процессы компании и понятен каждому принимающему решения.

В результате компания создала проприетарный фреймворк, резонирующий с её уникальными потребностями и динамикой.

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

«Успешно учли разнообразные интересы многих заинтересованных сторон и получили приоритизированную очередь запросов за разумное время». Руководитель анализа данных

Бизнес-критерии

Ключевые результаты (KR): прямое влияние на KPI продукта/процесса/функции/компании.

Вес: 3

Этот критерий должен быть переименован в конкретный продуктовый результат или метрику. Цель: Определить задачи для улучшения конкретной численной бизнес-метрики в том же или, максимум, следующем сезоне. Основа оценки: Рассмотреть, влияет ли задача напрямую на результаты, ориентированные на BI/KPI. Даже если задача не сразу изменяет показатели эффективности, она заслуживает более высокой оценки на основе этой стратегической согласованности, если вносит вклад в цели, связанные с KPI. Этот критерий обеспечивает согласованность приоритизации со стратегическими целями, фокусируясь на задачах, дающих ощутимые улучшения критичных бизнес-метрик.

Шкала:

• 1: Никакого прямого влияния на метрики.

• 2: Незначительное влияние, вряд ли заметно в метриках.

• 3: Небольшое влияние, возможно заметное в метриках.

• 5: Умеренное влияние с определённой уверенностью.

• 8: Значительное ожидаемое влияние, подтверждённое расчётами.

• 13: Крупное ожидаемое влияние на компанию/функцию с расчётами эффективности и подтверждениями KPI.

• 21: Существенное ожидаемое влияние, уверенно подтверждённое данными пилота, бенчмарками и ссылками.

Примеры задач:

• 1: Отслеживание просмотров правил выбора продукта.

• 2: Улучшение отображения продукта на iPhone 4s.

• 3: Улучшение качества отображения правил выбора продукта на всех мобильных устройствах.

• 5: Добавление правил выбора продукта.

• 8: Отображение доступности продукта по размерам.

• 13: Заказ нескольких размеров для доставки.

• 21: Внедрение заказа продуктов по всему сайту.

Удовлетворённость клиентов (CSAT): оценивает удовлетворённость пользователей и количество затронутых изменением пользователей.

Вес: 1

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

Фокус оценки: Внутренняя ценность задачи в генерации удовлетворённости пользователей.

• 1: Никакого влияния на радость пользователей.

• 2: Едва заметные улучшения для немногих.

• 3: Небольшой сегмент пользователей оценит изменение.

• 5: Заметно для четверти клиентов, половины бизнес-пользователей или руководителей отделов.

• 8: Половина клиентов, все бизнес-пользователи или руководители функций заметят улучшения.

• 13: Все клиенты, бизнес-пользователи и руководители функций с нетерпением ждут изменения.

• 21: Функция очень востребована с постоянными запросами от клиентов, бизнес-пользователей и даже незапрошенной обратной связью от общественности.

Примеры задач:

• 1: Отслеживание доставки email.

• 2: Улучшение отображения email для Lotus Notes.

• 3: Включение alt-текста для изображений в email.

• 5: Адаптация отображения email для Gmail.

• 8: Отправка уведомлений с учётом часовых поясов.

• 13: Введение центра уведомлений в мобильном приложении.

• 21: Управление подписками на уведомления в мобильном приложении.

Возможности: потенциал стратегических инвестиций и устранения препятствий разработке.

Вес: 1

Расчистить путь для разработки или открыть новые возможности роста компании. Включает задачи, являющиеся частью более широких стратегических инициатив (согласованных с BI/KPI), способствующих такой разработке. Может не влиять на выручку в краткосрочной перспективе.

• 1: Не открывает новых возможностей.

• 2: Предлагает незначительные возможности.

• 3: Создаёт локальные возможности для бизнес-процессов/функций продукта.

• 5: Предоставляет существенные возможности для развития бизнес-процессов/функций продукта.

• 8: Открывает возможности с потенциальным будущим влиянием на функцию или бизнес-процесс, видимым в будущих метриках.

• 13: Открывает значительные возможности с предвидимым крупным влиянием на компанию или функцию, отражённым в будущих метриках.

• 21: Раскрывает критичные возможности для выполнения долгосрочных стратегических планов компании.

Примеры задач:

• 1: Размещение статичного баннера на странице продукта.

• 2: Возможность менять баннеры на страницах продуктов сайта из админ-панели.

• 3: Настраиваемые баннеры на всех фронтах на страницах продуктов из админ-панели.

• 5: A/B-тестирование двух баннеров на страницах продуктов на всех фронтах из админ-панели.

• 8: Тестирование двух и более баннеров на страницах продуктов на всех фронтах.

• 13: Тестирование баннеров с автоматическим выбором победителя и минимизацией потерь выручки во время тестирования.

• 21: Автоматический выбор коммуникаций, мест размещения и пользователей на всех фронтах с тестированием лучшего алгоритма выбора.

Юридические: Потенциальные юридические риски, репутационный ущерб и штрафы, связанные с задачей.

Вес: 2

Фокус: Определяет влияние задачи на юридическое положение, включая иски пользователей, репутационный ущерб от юридических споров и штрафы за несоблюдение законов.

Шкала:

• -10: Значительно увеличивает юридические риски.

• -6: Существенно увеличивает юридические риски.

• -2: Незначительно увеличивает юридические риски.

• 0: Нейтральное влияние на юридические риски.

• 2: Слегка снижает юридические риски.

• 6: Значительно снижает юридические риски.

• 10: Резко снижает юридические риски.

Примеры:

• -10: Введение практик сбора данных, не соответствующих требованиям.

• -6: Внедрение функции с потенциальными проблемами конфиденциальности.

• -2: Небольшие изменения контракта, требующие юридического пересмотра.

• 0: Никакого влияния на юридические риски.

• 2: Улучшение соответствия доступности.

• 6: Усиление мер безопасности данных.

• 10: Внедрение отраслевых стандартов шифрования.

Критерии разработки

Риски разработки: IT-риски вроде снижения производительности команды, увеличения обслуживания или уязвимостей безопасности.

Вес: 2

Рассматривает риски вроде снижения производительности команды, необоснованного увеличения усилий по обслуживанию, создания ручных процессов, повышения хрупкости системы, снижения производительности, уменьшения безопасности и других связанных IT-рисков.

Шкала:

• -10: Значительно повышает IT-риски.

• -6: Существенно увеличивает IT-риски.

• -2: Слегка повышает IT-риски.

• 0: Не влияет на IT-риски.

• 2: Незначительно снижает IT-риски.

• 6: Заметно снижает IT-риски.

• 10: Резко снижает IT-риски.

Примеры:

• -10: Введение сложной, необслуживаемой кодовой базы.

• -6: Внедрение функции с известными уязвимостями безопасности.

• -2: Добавление новой зависимости, требующей дополнительного обслуживания.

• 0: Никакого влияния на IT-риски.

• 2: Рефакторинг кода для улучшения обслуживаемости.

• 6: Внедрение лучших практик безопасности.

• 10: Миграция на безопасную облачную инфраструктуру.

Архитектура: Определяет, соответствует ли задача целевой архитектуре или решает технический долг.

Вес: 2

Фокус оценки: Заслуги задачи в отношении архитектурного вклада или сокращения долга.

• -10: Резко увеличивает долг (крупный обходной путь).

• -6: Значительно увеличивает долг (существенный обходной путь).

• -2: Слегка увеличивает технический долг (небольшой обходной путь).

• 0: Нейтральное влияние на архитектуру; не продвигает и не отступает от целевого решения.

• 2: Незначительно сокращает долг.

• 6: Существенно движется к целевой архитектуре, включая устранение пробелов в автоматизации.

• 10: Напрямую достигает целевой архитектуры.

Примеры:

• -10: Интеграция устаревшей системы с основной платформой через кастомный код и прямые соединения.

• -6: Использует «тупиковую» технологию, несовместимую с целевой архитектурой и требующую дополнительных усилий для миграции в будущем.

• -2: Небольшой рефакторинг кода из-за дублирования. Краткосрочный технический долг, который можно быстро решить в ближайшем будущем.

• 0: Обновление документации или мелкие исправления багов.

• 2: Консолидация источников данных в единую платформу, способствующая более чистой и обслуживаемой архитектуре.

• 6: Соответствует микросервисной архитектуре и снижает долгосрочный технический долг.

• 10: Завершение крупномасштабной миграции на облачное PaaS-решение.

Проработанность: Прогресс, достигнутый по задаче, минимизация отказа от начатых задач.

Вес: 1

Цель: Определить, сколько задачи выполнено, чтобы приоритизировать продолжение и завершение уже начатой работы, обеспечивая эффективное использование ресурсов и минимизацию потерь от отброшенных задач.

• 55: Близка к завершению, осталось менее 10% работы. Требуется минимум усилий для финиша.

• 35: Выполнена существенная работа, более 40% завершено. Эффективнее завершить, чем отказаться.

• 5: Достигнут некоторый прогресс, не количественно определённый, но достаточный, что отказ приведёт к потерянным усилиям.

• 0: Стадия подготовки с описанием задачи и критериями приёмки (AC), предварительно проверенными командой.

• -10: Описание задачи и AC подготовлены, но не проверены, указывая на готовность к работе с некоторыми неопределённостями.

• -15: Отсутствует чёткое описание кроме заголовка, со значительными неясностями относительно требований и выполнения задачи, требующими дополнительного уточнения и планирования.

Примеры:

• 55: Написать юнит-тесты для уже реализованной функции.

• 35: Обновить элемент интерфейса для заказа покупки в мобильном приложении.

• 5: Достигнут некоторый прогресс, не количественно определённый, но достаточный, что отказ приведёт к потерянным усилиям.

• 0: Обновить проектную документацию с последними изменениями.

• -10: Улучшить скорость загрузки страницы корзины.

• -15: Исправить проблемы сайта.

Критерии уверенности

Исследование: Измеряет уверенность в задаче с подтверждающими данными.

Вес: 20

Жизненно важно для использования данных взаимодействия пользователей для информирования маркетинговых и омниканальных стратегий.

• 0 — Никаких новых инсайтов; чисто основано на предположениях.

• 21 — Собраны новые данные о поведении пользователей, указывая на задачи, основанные на доказательствах, с потенциалом свежих инсайтов.

Срочность: Обеспечивает гибкость во фреймворке для приоритизации и быстрого решения задач с срочными, высокорисковыми последствиями.

Этот критерий исключительно назначается тимлидам или менеджерам и активируется в срочных ситуациях.

Вес: 20

Шкала: 0 или 1.

Пример оценки (1 балл): Назначать задачам с немедленными значительными рисками, такими как:

• Обнаруженные уязвимости, которые могут привести к утечкам данных.

• Угрозы приостановки приложения платформами вроде App Store или Meta.

• Юридические предписания от регулирующих органов.

• Высокий риск существенных штрафов.

Критерии трудозатрат

Критерии Front End, Back End, Mobile, UX: Время, необходимое для разработки веб- и мобильных продуктов.

Это пример четырёх критериев: добавьте/измените/удалите все ненужные, отражающие структуру вашей команды разработки.

Вес: 1

• 1 — Без усилий: усилия не требуются.

• 2 — Полдня или меньше.

• 3 — Один день.

• 5 — Два дня (половина спринта).

• 8 — Четыре-пять дней (один спринт).

• 13 — Больше одного спринта, но меньше двух.

• 21 — Два спринта и больше.

Совет

Каждый критерий использует нелинейную шкалу оценки вроде 1, 2, 3, 5, 8, 13 и 21 — последовательность Фибоначчи.

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

Этап III: Оптимизация процесса оценки

Сила владения: назначение ответственных оценщиков

Розничный гигант начал с назначения чемпионов для каждого критерия приоритизации. Представьте: гармоничное сочетание планирования покера оценки и стратегического предвидения, где каждая ключевая область — Бизнес, IT, Исследования и Срочность — получает выделенного маэстро. Изначально это был квартет, но ансамбль вырос до оркестра из 16-20 человек на команду, играющих гармонично.

Магия синхронизации с Jira

Ещё один усилитель процесса — интеграция с Jira Server в реальном времени с двусторонним синком. Бэклог Jira каждой команды динамически синхронизируется, пульсируя обновлениями в реальном времени в Prioplan. Появляется новая Задача в Jira — мгновенно она появляется в Prioplan. Обновление бэклога в последнюю минуту? Обновляется в реальном времени — попрощайтесь с оценкой устаревших задач.

Представьте: конец ручному перетаскиванию задач. Это было не просто обновление; это революционизировало эффективность команд, оптимизировав рабочий процесс как никогда.

Фокус небольшими порциями

Столкнувшись с пугающей обширностью бэклога Jira, сам объём задач когда-то казался невозможным. Решение? Стратегическая сегментация. Они разрезали гигантский бэклог на перевариваемые кусочки, ментальную очистку, превратившую разросшуюся гору задач в аккуратно организованные управляемые холмы. Каждый сегмент, теперь вмещающий 25-50 задач, был чётко определён и подготовлен для оценки.

Этот подход привёл к созданию 150 отдельных Досок Prioplan небольшого размера для каждой команды, кульминацией стала агрегированная мастер-Доска, показывающая сквозные приоритеты. Это изменило игру, упростив процесс и принеся новую ясность коллективным усилиям.

Принятие разных перспектив

Признание и обсуждение разных точек зрения бесценно в командной приоритизации. С помощью отчёта согласованности команды они быстро это замечали. Расхождения в оценках ценности задач могли подчеркнуть недопонимание или разные восприятия важности задачи, сигнализируя о необходимости уточнения. С 20 оценщиками на Доску только 5-10% функций требовали дальнейшего обсуждения. Это затем решалось в звонках, приводя к финализированной оценке, напрямую влияющей на фасилитаторов вроде тимлидов или владельцев продукта.

Искусство актуальности

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

Оказалось, что примерно 5-10% задач вызывали дебаты, золотую возможность для более глубокого погружения и богатого понимания, кульминацией которого стала та самая важная Финальная оценка.

Признавая, что приоритеты могут быстро устареть, компания приняла практику сброса оценок каждые три месяца. Это регулярное «обновление» обеспечивало вывод из оборота устаревших задач и закрытие, фокусируясь только на актуальных Задачах.

Этап IV: Кросс-функциональная приоритизация — рост влияния на бизнес на 500%

Да, вы правильно прочли. Поразительная доставка задач с в 5 раз большим влиянием на бизнес. Как произошла такая трансформация? Всё сводится к стратегической приоритизации задач с помощью Prioplan, мнение, подтверждённое CTO клиента:

«Просто приоритизируя задачи в Prioplan, мы открыли новый уровень продуктивности. Настоящая магия была в сочетании правильного инструмента с нашим задуманным процессом».

Планирование в 9 раз быстрее

Кросс-функциональная приоритизация сжала время принятия решений с изматывающих 18 недель (четырёх с половиной месяцев) в год до двух недель. Этот квантовый скачок был достигнут через:

• Специализированные инструменты: Использование синка в реальном времени между Jira и инструментом приоритизации оптимизировало процесс.

• Динамические обновления критериев: Адаптация критериев приоритизации к меняющемуся бизнес-ландшафту обеспечила постоянную согласованность.

• Автоматическое обнаружение несогласованности: Мгновенное выявление расхождений держало фокус острым и актуальным.

• Упрощённый процесс: Прямой подход означал меньше сбоев и узких мест.

Устранение задач с низким влиянием

После приоритизации они наблюдали:

• 30% текущих задач разработки были удалены из-за низкого приоритета, перераспределяя ресурсы на проекты с высокой ценностью.

• 50% задач с наивысшим приоритетом были не готовы к немедленной разработке, позволяя упреждающее решение проблем или консолидацию задач.

• 60% задач, находящихся в очереди на продакшен, были деприоритизированы, потеряв актуальность из-за меняющихся бизнес-контекстов.

Колоссальный рост продуктивности

Дело не только в удалении ненужных задач, но и в оптимизации всего рабочего процесса с тем же размером команды.

• Время выполнения сокращено на 40% (это недели экономии)

• Время цикла доставки сокращено на 50%

• Скорость разработчиков увеличена в 2 раза

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

Внедрение кросс-функционального подхода к приоритизации: пошаговое руководство

С готовыми шаблонами и подробными рекомендациями принятие этого метода в вашей организации несложно. Хотя шаги ниже основаны на настройке Prioplan, основные принципы можно опробовать с таблицами.

1. Начните с шаблона: Создайте Доску приоритизации, используя шаблон фреймворка. Это служит вашей основой.

2. Импортируйте ваш бэклог: Загрузите сегмент вашего бэклога (30-50 задач) из вашего таск-трекера (например, Jira Cloud/Server, Asana, Linear, ClickUp, GitHub, Trello, YouTrack). Опционально настройте синк результатов приоритизации обратно в ваш таск-трекер для бесшовного рабочего процесса.

3. Настройте критерии: Тщательно пересмотрите все критерии. Будут ли эти критерии резонировать с вашей командой во время обсуждений? Знакомы ли термины, или их нужно подправить? Скорректируйте описания в соответствии с языком вашей команды, удалите ненужное и добавьте критерии, которых может не хватать.

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

5. Вовлеките команду: Пригласите всех участников оценить задачи. Эти коллективные усилия критичны для всеобъемлющей оценки.

6. Уточните с согласованностью: Используйте раздел согласованности для корректировки оценок по необходимости, обеспечивая консенсус и решая расхождения.

7. Оцените результат: Просмотрите приоритизированный список задач. Точно настройте веса и количество критериев по необходимости для дальнейшего уточнения приоритетов.

---

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

Скачать кейс в PDF.

Попробуйте Prioplan с Enterprise фреймворком — зарегистрируйтесь бесплатно со всеми пресетами.

FAQ

Не слишком ли затратен процесс по времени, чтобы быть оправданным?

Принятие этого фреймворка трансформирует приоритизацию проектов. Команды часто обнаруживают, что то, что казалось «перспективным», может не выдержать кросс-функциональной проверки, в то время как упущенные функции «было бы неплохо» появляются как возможности с высоким ROI. Настоящий выигрыш? Раскопка скрытых жемчужин в бэклоге, которые могли быть упущены иначе.

Как люди, не глубоко вовлечённые в проект, могут эффективно оценивать задачи?

Сила кросс-командной приоритизации в инклюзивности — объединении всех, кто может повлиять на выполнение задачи, а не только узкого круга продукта/роста/технического направления. Мы столкнулись с проблемами неясных описаний задач для людей в других ролях. Опция «не могу оценить» привела к тому, что многие задачи были отправлены на переописание авторами. Изначально встреченная сопротивлением, эта практика в итоге создала «позитивное давление» на авторов задач для уточнения, консолидации или удаления задач, естественно улучшая проработку бэклога с чёткой мотивацией.

Каково идеальное количество участников процесса приоритизации?

• 4 человека обеспечивают хороший старт с минимум одним представителем от каждого центрального подразделения (Бизнес, Разработка, Аналитика, Срочность).

• 10 человек достигают более всеобъемлющего охвата, обеспечивая минимум одного оценщика на критерий.

• 20+ человек оптимально, позволяя нескольким оценщикам на критерий перекрёстно проверять оценки и выявлять несогласованности.

Что если некоторые роли, вроде юристов, не могут оценить конкретные задачи?

Это совершенно нормально и управляется несколькими подходами:

• Они могут пропустить задачу для переоценки позже, особенно если это сочтётся необходимым при проверке.

• Задавать вопросы для уточнения задачи.

• Настроить синк бэклога Доски для уточнения выбора задач для оценки.

Как решить дилемму «все задачи срочные и наивысшего приоритета»?

Используйте функцию покера оценки для сокрытия оценок от других. Это поощряет непредвзятую оценку и помогает приоритизировать действительно критичные задачи, смягчая тенденцию отмечать всё как срочное и высокоприоритетное.