В статье решил собрать некоторые популярные приемы по приоритизации фич. Никаких изобретений велосипедов не будет. Возможно, некоторым новичкам так будет удобно. Если вы зубр ИТ и работа с приоритизацией у вас уже проросла в подкорку, едва ли статья будет вам полезна. Она просто обзорная, никакого обколачивания многолетнего опыта об эти инструменты и инсайтов из практики не будет.
Зачем вообще приоритизировать фичи?
Этот вопрос, пожалуй, выглядит чуть ли не риторическим в современных реалиях. Кажется уже практически любой, кого ни спроси:
- слегка округлит глаза «а чего вы спрашиваете, не знаете что ли?»;
- скажет, что время и деньги ограничены, вот и фичи придется ограничивать, а значит решать, какие делать сначала, какие потом. Может еще треугольник проекта пальцем в воздухе нарисует;
- скажет, что в принципе некоторые фичи могут быть бесполезны, перегружать продукт и надо от них отказываться.
Вроде все так. Тем не менее, когда доходит до дела, процесс приоритизации оказывается весьма непростым для всех участников. Можно на любом бытовом примере вспомнить, например, когда вы выступали в роли заказчика, как начинает хотеться «и того и другого и можно без хлеба» и недорого и быстро. И даже когда собираются в одной переговорке все грамотные, знающие разные умные инструменты, все равно непросто договориться.
Но мы сейчас пока не про сложности, возникающие на практике, а просто про приемы. Если гуглить приоритизацию, то в топе наткнемся, например, на RICE и ICE Scoring, Предлагаю с них и начать.
RICE Scoring:
Допустим, вы, пользуясь инструментом «проницательный прищур», отделили очевидно срочное и очевидно важное от очевидно не являющимся таковым. Как ранжировать то, что кажется одинаково срочным и важным. Например, перейти от качественной оценки к количественной и сравнить показатели. Что, собственно, и предлагает нам этот метод.
Оцениваются 4 фактора:
REACH – охват. Количество людей, на которых это повлияет за выбранный период времени. Резонно упаковать это количество
IMPACT – влияние. Надо оценить, что это нам дает как продукту. Например, в ключевых метриках. Конверсия, ретеншн, привлечение и т.д. Может (вдруг) надо оценить важность функции, которую нам предписывает сделать какой-нибудь регулятор. Т.е. она никак не улучшит наши ключевые показатели и нашу жизнь. Она нужна для того, чтобы этот самый регулятор не сделал нашу жизнь сильно неприятней. В связи с тем, что показатели важности сложно точно оценить и сравнить друг с другом, также используется шкала. Например, от 1 до 5. Или до 3, если этого достаточно. В общем, как договоритесь, с какой удобней работать.
CONFIDENCE – уверенность. Выражается в процентах, насколько нам известны данные по трем остальным факторам. Соответственно, будет тем больше, чем более аргументированные у нас данные и тем меньше, если они гипотетические. Т.к. ее тоже не удастся получить точно, поделив что-то на что-то, то выходит по сути та же самая шкала, о которой вы вместе договоритесь. Допустим 80-100% это условное «5» пятибалльной шкалы.
EFFORT – трудозатраты. Тут достаточно привычные человекочасы (дни, недели и т.д.). Понять «сколько ресурсов команды будет это стоить».
После оценки полученные цифры подставляются в формулу:
После чего, соответственно, расставляются по убыванию.
ICE Scoring:
Оцениваются факторы:
IMPACT – влияние.
CONFIDENCE – уверенность.
EASE – простота. Речь о реализации. По сути величина обратная трудозатратам.
Соответственно, после оценки, подставляем в формулу:
И ранжируем.
IMPACT/EFFORT или Lean Prioretization
Матрица 2х2:
Еще бывает оси называют VALUES и COSTS. Но суть остается та же: по Y влияние по ключевому показателю, по X затраты.
Распределив фичи по квадрантам получаем приоритезацию:
- Quick wins - важное и легкореализуемое;
- Fill ins - по той же логике, это можно сделать быстро
- Major projects - самое большое, страшное и тяжелое
С тем, что попало в Thankless tasks следует попрощаться.
Метод Вигерса:
В книге "Разработка требований к программному обеспечению" (Software Requirements), считающейся фундаментальной для отрасли, Карл Вигерс (помимо описания прочих моделей) предлагает наряду с BENEFITS (ценностью) и COSTS (затратами) оценивать PENALTY (ущерб), в случае, если фича не будет реализован. А также, как аналог CONFIDENCE - RISK (риск). Показатели оцениваются по шкале от 1 до 9.И по этой модели, каждая фича оценивается бинарно:
IMPACT MAPPING:
Собственно, это инструмент стратегического планирования, но с практически "вшитой" приоретизацией, т.к. предполагает оценку IMPACT (влияние) и всегда держать в фокусе именно его, а не смотреть на "саму фичу". Можно ознакомиться с этим подходом в книге Гойко Аджича "IMPACT MAPPING", в которой он в том числе описывает (как и Вигерс и много кто) подход покупки фичи: простую и популярную методику, согласно которой участникам предлгается распределить игровую валюту между фичами. И, естественно, "купить все" денег не хватит.
Что еще?
Можно еще рассмотреть метод Кано, MoSCoW, objective chain, WSJF, но я, пожалуй, приводить их здесь не буду. Вот и результат эксперимента: впихнуть все в одну шпаргалку дело не очень благодарное. Она получается объемной. Лучше еще одну напишу.
Стоит сказать, что, в общем-то везде упоминается, что ни один из методов не является волшебной таблеткой, содержит свои сложности (например оценка по шкале) и нюансы. Как, например, при покупке фичи, участник легко может "вложить все деньги в одну" просто в попытке повысить ее ценность, чтобы "протащить" ее. И все сводится к опыту модератора, умению "отказать и не обидеть" и так далее. Об этом тоже отдельно напишу. Например нюансы, которые указывает тот же Г.Аджич.
Закончить статью хочу мыслью К.Вигерса: "Не обязательно каждый раз использовать сложный метод. Старайтесь, чтобы ваш процесс определения приоритетов был насколько возможно простым, но не более того". В общем, оптимальный метод - тот, который работает наилучшим образом именно у вас. И опять мы никуда не денемся от проверки практикой - пробовать, делать выводы, переходить к другому и так по кругу.
Статья подготовлена в рамках прохождения акселератора Poduct University
