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

Введение

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

В результате время потрачено, а структурированная и последовательная работа с задачами не начата.

Да, действуй уже

В своей практике убедился, что иметь в портфеле две различные практики выставления приоритетов для задач более чем достаточно. Для себя таковыми выбрал MoSCoW и RICE, сейчас объясню почему.

MoSCoW

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

Так легко разложить их на 4 кучки:

1. Обязательны к реализации

2. Желательно сделать, но только после пункта 1

3. И те, что хотелось бы сделать, чтобы мир стал чуточку лучше, но это если силы останутся

4. Вот даже и не собирались их сейчас делать

Как правило такая ситуация имеется в части исправления не критических ошибок в продукте, его доработке “налету”. 

А еще, когда ты только накидываешь образ прототипа своего продукта, его первый MVP. Тогда уже есть понимание, ради какой функции, собственно, все делается. Каких еще сателитных функций сразу вкинуть, чтобы впечатление у “первых последователей” не испортилось. А вот дизайн пользовательского интерфейса или цвет кнопок в пень еще не сдались.

RICE

Формула его простая:

где R - покрытие (Reach), то количество пользователей, потребность которых мы закрываем рассматриваемой разработкой
I - влияние (Impact), принято брать из диапазона 3%; 2%; 1%; 0,5%; 0,25%
E - затраты на разработку (Effort), обычно указывают в часах
C - уверенность, учитываем возможные ошибки при определении трех других показателей, обычно берется из диапазона 1; 0,8; 0,5.

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

Однако, как показывает практика, с этой методикой легко споткнуться при оценке задач для разработки внутренних сервисов. Какая доработка важнее: которая облегчит жизнь 10-ти пользователям из уровня подчинения N-2? или 15-ти линейных сотрудников? Какой сервис выбрать дорабатывать вперед: который запускается раз в год (S&OP)? или запускаемый каждый день (запрос справок). А вот эту вообще Павел Евгеньевич попросил поскорее сделать - ему очень надо.

ROI - вернемся к первооснове

Чтобы найти решение любых “неразрешимых” вопросов (простите за тавтологию), нужно отойти на шаг или больше назад, до тех пор, пока не доберетесь до “развилки”, места принятия ключевого решения (все та же “Теория ограничений” от Элияху Голдратта).

В нашем случае - это оценка экономической эффективности от внедрения. Чаще всего ее оценивают с помощью величины возврата инвестиций (ROI), который определяется как отношение изменения прибыли к понесенным для этого затратам.

Рассмотрим детально наш практический случай, когда разработка осуществляется внутри компании силами IT-подразделения и нацелена на улучшение внутренних процессов, и приведем формулу для расчета ROI к удобному для оценки виду. Тогда в качестве затрат можем использовать произведение средней ставки занятого IT-специалиста (AvgSalary) на количество потраченных часов (E). И формула для расчета ROI примет вид:

Любое изменение бизнес-процессов или сервисов внутри компании, за редким исключением, не оказывает прямого влияния на прибыль. А изменяет эффективность использования выделенного бюджета. Что в свою очередь приводит в основном к снижению затрат компании на поддержание оптимизируемого процесса.

Изменение эффективности использования бюджета выразим через величину этого бюджета (BudgetFull) и его приращения (I):

Важно учитывать регулярность запуска рассматриваемой части бюджета в работу, то есть частоту обращений к бюджету (f):

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

Заменим величину, обратную риску, на уверенность (C), тогда изменение эффективности использования бюджета определится из:

Приходим к следующей формуле для оценочного расчета возврата инвестиций:

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

Сразу видна аналогия с классической формулой RICE. В открытых источниках историю происхождения формулы для RICE не нашел, но подозреваю, что логика при ее составлении была аналогичная.

Как использовать

Разберем каждый множитель в уравнении.

B - величина бюджета отдела, отделов или группы лиц, на эффективность деятельности которых мы хотим повлиять в рамках определенного периода (месяц, квартал, год и т.д.). Выражена в рублях, тыс. руб., евро или некой у.е., удобной для работы в рамках вашей компании. Главное - она одинаковая в рамках всего вашего бэклога, сравниваем сравниваемые вещи, а не коричневое с теплым. Нет данных по ФОТ или стоимости основных средств, так как коммерческая или гостайна и прочее? Не беда - берём данные Росстата или любого работного сервиса, данные любой торговой площадки. Главное, вы правильно поняли, - источник одинаковый в рамках всего вашего бэклога, сравниваем сравниваемые вещи. Отличие выбранного источника от “реальности” в вашей компании будет влиять только на масштаб сравниваемых величин, а большая из них все равно будет оставаться большей. И ЗП Павла Евгеньевича, которому “очень надо”, смело добавляем к величине B, так и учтем его приоритет в сравнении с мольбами нескольких сотен рядовых сотрудников.

f - частота изменяемого сервиса, количество запусков за тот же период, который определен для величины B.

I - влияние, так как на практике влияние внутренних доработок не превышает 3-4%, то можно использовать принятый для RICE диапазон для аналогичной величины (откинув знак процента): 3%; 2%; 1%; 0,5%; 0,25%.

C - уверенность, величина, обратная риску: 100% (100% - 0%); 80% (100% - 20%); 50% (100% - 50%). При уверенности менее 50% (то есть риск ошибки в оценке свыше 50%) - не занимаемся этой задачей сейчас, так как похоже на авантюру. Ждем уточнений по исходным данным. Можно указывать в % или в долях - не имеет значения, главное - одинаково для всего бэклога.

E - затраты, часы разработчиков.

Послесловие

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

Аналогичным способом можно вывести другие варианты расчёта RICE и обеспечить приоритетами свой уникальный процесс разработки.