Команда условного сервиса управления проектами выбирает функционал для следующего этапа разработки: шаблоны проектов, импорт задач из CSV или генерацию плана с помощью ИИ.
Шаблоны нужны большему числу команд. Импорт помогает перенести работу из другого сервиса. Генерация плана выглядит перспективно, но её пользу ещё предстоит проверить.
В этой статье разберём шесть способов приоритизации функционала на одном условном продукте. Посчитаем RICE и ICE, определим состав релиза через MoSCoW и посмотрим, когда пригодятся Value/Effort, Kano и WSJF.
Содержание
- Как выбрать метод под свою задачу.
- RICE учитывает охват, влияние, уверенность и усилия.
- ICE помогает отобрать идеи для дальнейшей работы.
- MoSCoW определяет обязательный состав релиза.
- Value/Effort разделяет идеи по ценности и трудозатратам.
- Kano помогает разобраться в ожиданиях пользователей.
- WSJF учитывает, насколько дорого откладывать работу.
- Типичные ошибки при приоритизации.
- FAQ.
- Соберите карточки трёх вариантов функционала.
Как выбрать метод под свою задачу
Метод зависит от решения, которое вы принимаете. Выбрать функционал для разработки, определить обязательный состав релиза и выяснить ожидания пользователей — разные задачи.
Начните с цели продукта. В нашем примере команда хочет повысить долю пробных команд, переходящих на платный тариф. Влияние всех трёх вариантов функционала оцениваем относительно этой цели.
Обязательства с фиксированным сроком стоит выделить до расчётов: например, устранение критической ошибки или функцию, обещанную в договоре. Для них заранее определяют необходимый объём работы и резервируют ресурс. Оставшийся ресурс распределяют между кандидатами.
RICE учитывает охват, влияние, уверенность и усилия
RICE предложила команда Intercom. Название складывается из четырёх параметров: Reach — охват, Impact — влияние, Confidence — уверенность в оценках, Effort — усилия.
Формула:
RICE = Reach × Impact × Confidence / Effort
Для сравнения договоримся об общей рамке. За месяц в условный сервис приходят 1000 пробных команд. Единица Reach — пробная команда, или аккаунт, за один месяц. Отдельных сотрудников внутри команд в охвате не считаем. Impact оцениваем для одной такой команды относительно перехода на платный тариф.
Все числа и основания ниже придуманы для объяснения расчёта. Это не данные реального продукта.
Reach показывает, сколько команд затронет функционал
Шаблоны проектов пригодятся 500 пробным командам за месяц. Импорт задач — 250 командам, которые переносят существующие проекты. Генерацией плана предположительно воспользуются 800 команд.
Единица охвата во всех строках одинаковая: пробная команда. Если в одной строке считать команды, а в другой отдельных участников, сравнение исказится.
Период тоже общий. Месячный охват одного варианта функционала нельзя сравнивать с квартальным охватом другого.
Impact оценивает изменение для одной команды
В Intercom используют шкалу:
- 3 — очень сильное влияние;
- 2 — высокое;
- 1 — среднее;
- 0,5 — низкое;
- 0,25 — минимальное.
В нашем примере шаблоны ускоряют начало работы, но команда может создать проект самостоятельно. Ставим Impact = 1.
Импорт позволяет перенести рабочие задачи и продолжить пользоваться сервисом. Предполагаем более сильное влияние на переход к оплате: Impact = 2.
Генерация плана тоже получает 2. Пока это предположение команды. Его слабую подтверждённость учтём в Confidence.
Impact — относительная оценка. Значение 2 не означает рост конверсии на два процентных пункта или удвоение выручки.
Confidence отражает качество оснований для оценки
В исходном описании RICE предложены три ориентира: 100 % — высокая уверенность, 80 % — средняя, 50 % — низкая. В формулу их подставляют как 1, 0,8 и 0,5.
Условно примем такие основания:
- Для шаблонов есть данные об использовании похожего решения, проверка прототипа и оценка разработки. Ставим 1.
- Для импорта известен объём ручного переноса, есть интервью с пробными командами, но влияние автоматизации на оплату ещё не проверено. Ставим 0,8.
- Для генерации плана есть отдельные запросы и предположение команды. Пользовательской проверки пока нет. Ставим 0,5.
Confidence = 1 означает наибольшую подтверждённость входных оценок в этом сравнении. Это не гарантия результата и не измеренная вероятность успеха.
Если за оценкой стоит лишь мнение автора идеи, полезнее сначала проверить проблему и решение. Балл сам по себе новых свидетельств не добавит.
Effort считает суммарную работу команды
В RICE усилия измеряют в человеко-месяцах. Один человеко-месяц — работа одного человека с полной занятостью в течение месяца.
Для шаблонов заложим 0,25 человеко-месяца дизайна, 1 человеко-месяц разработки и 0,25 человеко-месяца тестирования. Всего 1,5.
Импорт оцениваем в 1 человеко-месяц, генерацию плана — в 4.
Человеко-месяцы и календарный срок различаются. Два специалиста, каждый из которых работает над задачей полмесяца, вместе затратят один человеко-месяц. Срок поставки зависит ещё и от последовательности работ, доступности людей и зависимостей.
В Effort включают суммарную работу всех ролей, необходимую для готового результата: проектирование, разработку, тестирование и другие затраты команды.
Считаем приоритет трёх вариантов функционала
Шаблоны: 500 × 1 × 1 / 1,5 ≈ 333.
Импорт: 250 × 2 × 0,8 / 1 = 400.
Генерация плана: 800 × 2 × 0,5 / 4 = 200.
Импорт получает больший балл, хотя его охват вдвое меньше, чем у шаблонов. По принятым оценкам он сильнее влияет на переход к оплате и требует меньше работы.
RICE даёт основание рассмотреть импорт первым. Перед включением в план остаётся проверить зависимости, обязательства и доступность команды. Сам балл не показывает ожидаемую выручку или число будущих оплат.
ICE помогает отобрать идеи для дальнейшей работы
ICE состоит из Impact — влияния, Confidence — уверенности и Ease — лёгкости реализации.
Используем вариант формулы:
ICE = Impact × Confidence × Ease
Каждый параметр оцениваем по шкале от 1 до 10. Чем выше Ease, тем проще полностью реализовать функционал.
Отдельного параметра Reach здесь нет. Охват можно включить в оценку общего влияния идеи на выбранную метрику. В RICE Impact относится к одной команде, поэтому механически переносить его в ICE нельзя. Заранее договоритесь, что именно означает влияние в вашем сравнении.
Для нашего примера оценим общий ожидаемый вклад каждого варианта функционала в переход пробных команд на платный тариф. Примем 5 по Impact за среднее влияние, 8 — за высокое. По Confidence 10 означает наиболее сильную доказательную базу, 8 — частичную, 5 — слабую. Оценки Ease отражают относительную сложность разработки.
Это условные ориентиры команды, а не универсальная шкала ICE. Оценки Impact в таблице самостоятельные: их не пересчитывали из RICE.
Импорт снова выходит первым. Генерацию плана опускают в списке слабая подтверждённость и сложность реализации.
ICE можно использовать для первичного отбора идей. Субъективность оценок сохраняется: полезно записывать основание рядом с каждым баллом. Confidence здесь тоже отражает силу свидетельств, а не измеренную вероятность успеха.
Если оцениваете функционал, Ease относится к полной реализации. Быстро показать генерацию плана в прототипе и встроить её в рабочий сервис — разные объёмы работы. Эксперименты можно приоритизировать отдельным списком, сравнивая стоимость и пользу проверок.
Встречается и вариант ICE со средним арифметическим: (Impact + Confidence + Ease) / 3. Он может дать другой порядок. Выберите один вариант и используйте его для всего списка.
MoSCoW определяет обязательный состав релиза
Допустим, команда выбрала импорт. Теперь предстоит договориться, что войдёт в ближайший релиз и чем можно пожертвовать при нехватке времени.
Для этого подходит MoSCoW. Название образовано от четырёх категорий.
Must Have — обязательное. Без этого релиз не выполняет свою задачу. Для импорта это загрузка CSV по заданному шаблону, чтение данных и проверка формата с понятными сообщениями об ошибках.
Should Have — важное, для чего есть приемлемый обходной способ. Например, гибкое или автоматическое сопоставление колонок. Пока его нет, пользователь готовит CSV по заданному шаблону.
Could Have — полезное дополнение, которое возьмут при наличии ресурса. В нашем условном релизе к этой категории можно отнести шаблоны проектов.
Won’t Have this time — согласованно исключённое из текущего релиза. Генерацию плана с ИИ откладываем. Вернуться к ней можно позже.
Здесь изменился вопрос: RICE помог выбрать функционал, MoSCoW помогает согласовать поставку. После уточнения состава импорта проверьте, соответствует ли ему прежняя оценка Effort.
Категории не ранжируют задачи внутри себя. Если в Should Have десять пунктов, их очерёдность придётся определить отдельно.
Когда почти всё оказывается в Must Have, проверьте последствия отказа от каждого пункта. Обязательность проще обсуждать через конкретное условие: «без этого данные не загрузятся» или «без этого пользователь потратит ещё две минуты».
Value/Effort разделяет идеи по ценности и трудозатратам
Матрица Value/Effort сравнивает два параметра: ценность и усилия. На одной оси размещают ожидаемую ценность для выбранной цели, на другой — трудозатраты.
Получаются четыре группы:
- Высокая ценность, небольшие усилия. Кандидаты на ближайшую работу.
- Высокая ценность, большие усилия. Крупные инициативы, для которых стоит уточнить эффект и поискать меньший объём решения.
- Низкая ценность, небольшие усилия. Дополнения, которые можно брать при наличии ресурса.
- Низкая ценность, большие усилия. Кандидаты на отказ или пересмотр.
В нашем примере импорт окажется ближе к высокой ценности и небольшим усилиям. Генерация плана — к высокой предполагаемой ценности и большим усилиям. Для неё разумный следующий шаг — проверить пользу до полной разработки.
Матрица удобна для первой сортировки большого бэклога. Шкалы и границы команда выбирает сама: например, что считать небольшими усилиями при её составе и загрузке.
Слабое место метода — оценка ценности. Если она основана на предпочтении руководителя, аккуратная матрица сохранит это предпочтение. Рядом с описанием функционала полезно указывать, откуда взялась оценка и что ещё предстоит выяснить.
Kano помогает разобраться в ожиданиях пользователей
Модель Kano связывает свойства продукта с удовлетворённостью пользователей.
Базовые свойства ожидаются по умолчанию. Их отсутствие вызывает недовольство, а наличие воспринимается как норма.
Линейные свойства дают больше удовлетворённости по мере улучшения. Например, сокращение времени переноса задач может быть ценным для команд с большими проектами.
Привлекательные свойства дают неожиданную пользу. Пользователь мог не ожидать генерацию плана, но оценить её после знакомства с решением.
Это возможные объяснения на нашем примере. Назначить категории на встрече продуктовой команды недостаточно.
В исследовании по Kano пользователям задают парные вопросы. Для импорта CSV они могут звучать так:
- «Как вы отнесётесь к тому, что в сервисе можно импортировать задачи из CSV?»
- «Как вы отнесётесь к тому, что в сервисе нельзя импортировать задачи из CSV?»
Для обоих вопросов используют одинаковый набор вариантов ответа: от «мне это нравится» и «так и должно быть» до безразличия, готовности мириться с ситуацией и недовольства. Категорию определяют по сочетанию двух ответов. Одного «хочу импорт» для классификации недостаточно.
Импорт может оказаться базовым ожиданием команд, которые переходят из другого сервиса. Для команд, начинающих первый проект, он может быть безразличен. Часть функций способна вызывать и обратную реакцию: например, усложнять привычный сценарий.
Результат зависит от сегмента и со временем меняется. Привлекательная сегодня функция может стать ожидаемой.
Kano помогает исследовать ценность, но не учитывает стоимость разработки и не задаёт порядок всего бэклога. Результаты исследования можно использовать при оценке Impact в RICE или ценности в Value/Effort.
WSJF учитывает, насколько дорого откладывать работу
Добавим условие к нашему примеру. Несколько команд планируют перейти в сервис к началу следующего месяца. Импорт нужен к этой дате: задержка может сорвать переход.
Для задач, у которых различается цена ожидания, применяют WSJF — Weighted Shortest Job First, взвешенную приоритизацию с учётом размера работы.
Общий принцип: разделить стоимость задержки на длительность работы. В версии Scaled Agile используют относительные оценки:
WSJF = (ценность для пользователя и бизнеса + критичность по времени + снижение рисков или открытие возможностей) / размер работы
Оценки сопоставляют внутри одного списка. Для нашего примера используем значения из ряда 1, 2, 3, 5, 8, 13.
Для импорта: (8 + 8 + 3) / 3 ≈ 6,3.
Его приоритет связан в том числе с датой перехода клиентов. У генерации плана такой срочности в условном примере нет.
Эти баллы не измеряют рубли и не показывают ROI. Они помогают сравнить относительную цену задержки. Маленькая задача с низкой ценностью может уступить более крупной, если откладывание последней обходится дороже.
WSJF требует содержательного обсуждения срочности. Если каждой идее поставить максимальную критичность по времени, этот параметр перестанет помогать выбирать.
Типичные ошибки при приоритизации
Подгонять оценки под выбранный функционал
У автора идеи обычно больше аргументов в её пользу, чем против неё. Без общей шкалы Impact растёт, а трудозатраты уменьшаются.
Сначала согласуйте ориентиры оценок. Рядом с баллом записывайте основание: аналитика, интервью, тест или предположение. Спор о числе тогда превращается в обсуждение данных.
Смешивать разные масштабы работы
«Сделать импорт» и «перестроить весь первый опыт пользователя» выглядят соседними строками, хотя вторая содержит несколько решений.
Определите результат и границы каждого варианта функционала. Если объём меняется после оценки, пересчитайте усилия и ожидаемый эффект.
Выдавать баллы за точный прогноз
RICE = 400 выглядит убедительнее слов «скорее всего, полезно». Однако исходные оценки остаются приблизительными.
Проверим диапазон оценки на нашем примере. Если импорт потребует 1,5 человеко-месяца вместо 1, его RICE составит 250 × 2 × 0,8 / 1,5 ≈ 267. Шаблоны с баллом 333 выйдут выше.
Следующий шаг — уточнить трудоёмкость импорта. Условная проверка диапазона помогает найти параметр, от которого зависит решение. Отклонять вариант функционала по одному из возможных значений преждевременно.
Оставлять оценку после изменения условий
Приоритет импорта изменится, если переход клиентов перенесут, появится готовое решение или разработка окажется сложнее.
Пересматривайте оценки при появлении новых данных и перед очередным планированием. Зафиксированная дата оценки помогает отличить свежие основания от старых предположений.
FAQ
Чем RICE отличается от ICE?
В RICE отдельно учитывают охват, оценивают влияние на одного пользователя или клиента и делят результат на усилия. В выбранном здесь варианте ICE перемножают влияние, уверенность и лёгкость реализации. Охват можно учесть внутри общего влияния на метрику. Шкалы и оценки двух методов нельзя механически переносить друг в друга.
Можно ли использовать несколько методов вместе?
Да, если каждый отвечает на свой вопрос. Kano помогает исследовать ожидания, RICE — сравнить варианты функционала, MoSCoW — согласовать состав выбранного релиза. Считать шесть рейтингов для каждого решения обычно избыточно.
Что делать, если для оценок нет данных?
Записать предположения и выбрать, какое из них сильнее всего влияет на решение. Охват можно уточнить по аналитике, проблему — через интервью, понятность решения — на прототипе. Оценка после проверки будет полезнее дополнительного знака после запятой.
Как учитывать срочную задачу от руководителя?
Уточнить причину срочности, срок и последствия задержки. Договорное обязательство учитывают как ограничение. Идею с предполагаемой коммерческой пользой сравнивают с другими кандидатами. Последствия выбора тоже фиксируют: какая работа сдвинется и какой ресурс займёт задача.
Соберите карточки трёх вариантов функционала
Возьмите три кандидата на разработку и заполните для каждого короткую карточку:
- Какую проблему и какого сегмента решает функционал.
- На какой бизнес-результат должна повлиять.
- Какие данные подтверждают проблему и ожидаемую пользу.
- Какой объём работы входит в оценку.
- Какие есть сроки, обязательства и зависимости.
- Какое предположение стоит проверить до разработки.
Сравните кандидатов подходящим методом. Если оснований достаточно, выберите функционал для следующего этапа разработки и запишите причину выбора. Если решение зависит от спорного предположения, назначьте его проверку: что выяснить, каким способом, кто отвечает и к какому сроку.
Для выбранного варианта функционала или проверки зафиксируйте основания и дату пересмотра приоритета. Вернуться к решению раньше стоит, если изменятся данные, объём работы или обязательства.
Когда неизвестно, за какую пользу клиенты готовы платить, исследование аудитории помогает уточнить основания для приоритетов. Когда функции спорят между собой из-за разных целей и сегментов, работа над продуктовой стратегией помогает определить общую рамку выбора. Эти задачи можно обсудить с «Фабрикой Гипотез».