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