Что делать в первую очередь? Простая приоритизация задач при помощи риса
Когда проще все сжечь
Реализация проекта или создание продукта связаны с выполнением задач, тестированием идей и гипотез. Зачастую их накапливается огромное количество, и встает извечный вопрос (нет, не кто виноват и что делать): что делать в первую очередь? Если в организации не установлены явные правила, то будет работать «правило джунглей»: прав тот, кто громче кричит. Соответственно, с наивысшим приоритетом пойдут задачи того заказчика, который имеет перевес в голосе и в «корпоративном весе».
В этой статьей расскажу, как мы пытались сделать правила приоритизации явными и без драки на ножах, а также о простом методе RICE, в основе которого лежит балльная система.
Как мы изобрели велосипед, в очередной раз…
Волею судеб я попал на позицию руководителя программы проектов, которые охватывали изменения в большом куске важной операционной деятельности компании (кровавый энтерпрайз). С чем мы заходили в программу проектов, где огромную часть занимал проект «Автоматизация»:
задачи на разработку ставились несколькими заказчиками уровня «генеральный минус один» и их «офицерами»;
отсутствовали правила приоритизации для заказчика, приоритет ставился командой разработки после беглой оценки и утверждался или не утверждался на специальном собрании;
степень описания бизнес-требований накопившихся задач на разработку была кардинально разношерстной: от просто наименования до детально описанных требований, которые нередко не учитывали системных ограничений или зависимостей от смежных процессов и систем;
профильное подразделение бизнес-анализа не участвовало в процессе постановки задач (не спрашивайте почему — так исторически сложилось к тому моменту времени).
система была legacy и снята с поддержки производителем;
входное количество задач было больше 2000 и постоянно пополнялось.
Как вы, наверняка, догадались, собрания по приоритизации и хоть какому-то упорядочиванию списка задач нередко проводились на повышенных тонах и не приводили хоть к какому-либо результату.
Когда пытаешься обосновать приоритетность задачи самому себе
С горой задач нужно было что‑то делать и мы не придумали ничего лучше, чем придумать (где мои таблетки от тавтологии) свою собственную систему присвоения приоритетов: «Высокий», «Средний» и «Низкий» — правила присвоения этих приоритетов и соответствующую им очередность выполнения. Приоритет присваивался исходя из уровня задачи (стратегическая, регуляторная, тактическая и прочая), требуемого срока реализации, оценки от команды в трудочасах, статуса (на каком этапе техпроцесса находится задача) и еще пары критериев. «Высокий приоритет», разумеется, без обсуждения присваивался задачам регуляторным, а вот дальше начиналась игра полутонов: стратегические задачи могли попасть во вторую очередь, а тактические — в первую или в третью, а с эпиками, которые не были декомпозированы, вообще непонятно, что было делать, поэтому их оценивали наравне с задачами. К концу одного часа такого собрания по приоритизации эффективность рассмотрения, естественно, падала почти до нулевых значений. А стоимость подобных собраний, как вы могли догадаться, была космической. Состоялась пара таких подходов, и дальше мы приняли решение планировать месячные итерации под краткосрочные цели бизнес‑заказчиков и тем самым достаточно органично разгребли гору задач примерно за 7 месяцев. Но можно было и по‑другому.
Где ты был раньше со своим рисом?
При чем тут рис?
В приоритизации помогает балльная система. Оценка каждой задачи в конечном итоге позволяет сформировать последовательный план действий. Предлагаю рассмотреть, как провести оценку при помощи RICE на конкретных примерах.
Оценка задач согласно методике проводится по четырем факторам:
Из первых букв складывается аббревиатура‑название методики — RICE.
Определяем охват (Reach)
Что такое «охват»? Простыми словами — на какое количество пользователей повлияет изменение ПО. Фактор измеряется количеством людей/событий за период времени. Причем совсем примерные оценки, взятые с потолка, не подойдут. Берите только реальные данные, привязанные к определенным метрикам продукта или уже известное количество пользователей, которые работают с конкретным функционалом или модулем ПО.
Пример. В нашем конкретном случае, где ПО уже работает, а количество пользователей неизменно, за единицу времени возьмем квартал, количество пользователей 680, и какое‑то количество событий:
1. 680 пользователей будут совершать действие в ПО 3 раза в месяц. Значит, Охват=680×3*3=6120.
2. 680 пользователей совершают действие в ПО 1 раз за месяц. Значит, Охват=680×3=2040.
3. 680 пользователей окажутся под влиянием изменения в ПО 1 раз, и больше никакого результата не последует. Значит, Охват=680×1=680.
Все результаты вносим в сводную таблицу.
Пример сводной таблицы
Определяем влияние (Impact)
Сложно измеримый фактор в методике: потому как это не совсем объективная оценка. Но такая оценка все равно лучше, чем предвзятое отношение к задачам или многочасовое ломание копий. Рассматривайте влияние на каждого конкретного клиента или пользователя или группу пользователей. Для количественного выражения влияния предлагается использовать шкалу множественного выбора:
Адекватная оценка влияния крайне важна, так как на установленное значение умножается итоговый результат.
Пример. В нашем конкретном случае:
1. На каждого пользователя будет оказано среднее влияние. Значит, балл — 1.
2. Во втором варианте на каждого пользователя будет оказано массовое влияние влияние. Значит, балл — 3.
3. В третьем варианте на каждого пользователя будет оказано минимальное влияние. Значит, балл — 0,25.
Все результаты также вносим в сводную таблицу в колонку «Влияние».
Внесли оценку Impact
Определяем уровень уверенности в оценках (Confidence)
Задачи и, особенно, идеи бывают интересными и перспективными, некоторые при поверхностном рассмотрении кажутся созданными под галлюциногенными грибами, но данных для подтверждения нет. Чтобы не впутаться в авантюру, определите уровень уверенности в оценках. Уверенность указывают в процентах. 100% — высокая уверенность, 80% — средняя и 50% — низкая. Все, что ниже 50% — иллюзии, от которых лучше сразу отказаться и не тратить на них ни время, ни деньги.
Пример. В нашем конкретном примере:
1. В первом случае нам известно за счет исторических данных, что наша оценка может получить 100% по Confidence.
2. Во втором случае ситуация аналогична первому случаю: Confidence — 100%.
3. А вот с третьим случаем не все так железобетонно. Параметр «Confidence» здесь получит 80%.
Процентную выражение переводим в натуральные числа, поскольку так будет проще считать итоговый балл по формуле. Исходя из этого сводная таблица будет выглядеть следующим образом.
Внесли оценку Confidence
Определяем усилия (Effort)
Придется посчитать, сколько времени уйдет на реализацию. В методике RICE данный показатель измеряется месяцами. Если на реализацию задачи уйдет 1 месяц, в таблице, соответственно, указывают 1. Конечно, с высокой точностью до дня определить временные затраты сложно, но примерные значения рассчитать получится.
Пример. В нашем конкретном случае:
1. В первом варианте команда оценила усилия в 3 месяца.
2. Во втором варианте оценка составила 1 месяц.
3. И третий вариант также получил оценку в 1 месяц.
Вносим значения в сводную таблицу.
Внесли оценку Effort
Считаем итоговый балл
Итоговое значение считаем по формуле: (Reach x Impact x Confidence) / Effort. Что же говорят нам сухие беспристрастные цифры:
1. В первом варианте оценка составит=6120×1*⅓=2040.
2. Оценка второй задачи составит=2040×3*1/1=6120.
3. Третий вариант согласно формуле получит оценку=60×0,25×0,8/1=136.
Считаем итоговую оценку
Смотрим на общую картину
Итоговый показатель демонстрирует значимость задач. Самый высокий показатель — 6120 — говорит о том, что третья задача принесет больше пользы за время работы, поэтому ее реализуем самой первой. После оценки всех задач можно отсортировать рассматриваемые задачи по убыванию и еще раз окинуть взглядом полученные оценки. Не кажутся ли они завышенными или заниженными? Если по отношению к каким‑то задачам возникают сомнения, необходимо пересмотреть оценку каждого параметра и внести в матрицу новые вводные.
В качестве заключения
Разумеется, оценка по методике RICE — это не панацея. Нередко в реальной производственной практике приходится сначала реализовывать задачи с низким приоритетом из‑за разных обстоятельств. И, конечно же, по разным причинам свой конкурс красоты некоторые задачи будут проигрывать из раза в раз. Однако RICE — это один из инструментов, который позволяет достаточно быстро выполнить оценку, а время, как известно, деньги. И лучше взять существующее проверенное правило, чем потратить драгоценное время на изобретение собственной методики.
После Demo заказчику
