Материал для тех, кто пытается что-нибудь менеджерить, начиная с собственных ресурсов и заканчивая департаментами в корпорациях или корпорациями в целом.
По причине 2022 года возникла постоянная смена стратегических направлений из-за повышенной турбулентности всего мира.
В этих условиях каждое планирование работы команд и приоритизация бэклога (списка задач) превращается в ад из бессмысленных звонков, споров, презентаций, экселей, переписок и прочего.
В итоге:
Фичи (задачи с понятной ценностью для бизнеса и клиента), начатые в рамках предыдущих стратегических приоритетов, брошены;
Ценностей ни бизнес, ни клиент не получили;
Все поработали впустую;
Правила игры непонятны;
Большая часть приоритетов выглядит классически авторитарными;
Все демотивированы.
Снова начался поиск ответа на вопрос «ну, и как планировать и приоритизировать работу?».
Капля воды в начале
Я давно искал ответы на эти вопросы в методах работы и моделях приоритизации. Перетестил RICE, PIE, ICE, Kano, матрицу Эйзенхауэра, weighted scoring и даже кое-что самодельное. В 2017 я познакомился с методологией WSJF (weighted shortest job first). Через год тестирования механизма: Kanban (метод работы, при котором проще попадать в ожидания) плюс WSJF – всё заработало. Это было в относительно небольшой компании, в рамках малой пропускной способности и ограниченных ресурсов на всех уровнях – от фич до программ (например, полноценный запуск нового продукта) или направлений бизнеса…
Суть
Придя в Хоум Кредит Банк, я попал в идущий полным ходом процесс внедрения SAFe, в котором также используется приоритизация WSJF.
Год с лишним в Хоуме мы адаптировали методологию к подходам в банке. Естественно, часто внутренний заказчик требует выполнить ту или иную задачу в директивном порядке, и именно в борьбе с директивной парадигмой нам очень помогает WSJF, т.к. он позволяет сравнить несравнимые задачи и за счет сильного влияния трудозатрат / размера работы на итоговый приоритет подсказать инициатору, что делать в первую очередь, а чего не делать. Причем, если внутренний заказчик продолжает настаивать на своем директивном решении, на выходе он всё равно не получает желаемую фичу к желаемой дате.
Вот основные выводы по использованию WSJF:
Оперируем только фичами
Ценности эпиков всегда декомпозируем до фич
Все возражения со стороны проджектов, PMO, LACE, стратегов и прочих важных ребят, убираем аргументом, что ценность эпика доносится набором фич, а так как ресурс не безграничен, мы декомпозируем всё до фич, чтобы донести в понятный отрезок времени понятный объем ценности;
Приоритезируем бэклог силами продакта без привлечения финансовых департаментов
Даже size может прикинуть сам продакт на базе того, как много занимали подобные задачи ранее;
Чем больше в фиче учтено параметров, тем вероятнее фича доберется до прода (до конечного клиента)
Заодно учим всех стейков/заказчиков/продактов делать хоть какую-то работу перед тем, как подключать разработку;
На WSJF переводим все стримы/вертикали/департаменты/команды участвующие в конкретном «поезде»
Важно, чтобы лица оперирующие программами/поездами/эпиками, также использовали WSJF, иначе будет конфликт приоритетов фич и эпиков/программ;
Рассчитываем все параметры WSJF изначально в деньгах
Это позволит прозрачно сравнивать друг другом внутри одного параметра все фичи в бэклоге и уже навешивать им значения из псевдо ряда Фибоначчи;
Все параметры должны или могут падать как в доход, так и в расход
Например, если мы запустили новую прибыльную комиссионную услугу и она прогнозно в половине случаев будет генерить доп. обращения в чат и по телефону, такие обращения упадут в расход, помимо комиссионного дохода;
Все авторитарные «джокеры» в виде «прямая задача от инвестора / влиятельного босса» или такие штуки как «стратегический приоритет компании» выражаются просто как продолжение ряда Фиббоначи в параметре RR | OE value с соответствующей градацией,
Например:
влиятельный босс = 34
председатель правления / ген. дир / страт. приоритет компании = 55
инвестор = 89
Таким образом, у фич с фактической пользой остаётся надежда на конкуренцию за прод даже перед джокерами;
Если кто-то по какому-то из параметров своей фичи не указал ничего – тогда считаем этот параметр единицей
Например, time critically по фиче «дизайн новых выписок» продакт или бизнес-овнер не поставил и не описал, тогда это и будет time critically 1 и относительно него будут оцениваться time critically других фич
Далее не всем интересный перечень того, что и в каком из параметров WSJF мы пробуем учесть.
User | Business value = доход + экономия - убыток
Доход – сколько заработаем на фиче;
Экономия – сколько денег мы перестанем терять благодаря этой фиче (например, откажемся от какой-нибудь лицензии, снизим смски, расходники – любые сокращения расходов);
Расход – новые периодические или единоразовые затраты (лицензия/интеграция вендора или что-то такое);
Churn rate – влияние на отток клиентов;
tNPS – как повлияет реализация фичи на соотношение промоутеров/детракторов банка/приложения;
SUM – как мы изменим single usability metric по приложению/сайту/банкомату/отделению и чему угодно;
ARPU – уровень влияния на доходность одного клиента;
CAC – влияние фичи на стоимость привлечения клиента;
LTV/LTP/CLV/LTP – влияние фичи на срок жизни клиента, его пожизненную ценность для банка;
Bounce rate – влияние на потерю клиентов на определенном шаге;
Acquisition rate – влияние фичи на приток клиентов;
CR – влияние на конверсию в целевое действие;
Digital – влияние на оформление цифровых продуктов;
Remote – влияние на переток в удаленное обслуживание;
Usage – влияние на использование продукта (лучше завязать на LTV);
FTE – влияние на ФОТ;
Sell – влияние на кросс-сейл и ап-сейл;
VAS – влияние на проникновение и объем доп. сервисов и их допросами
Средний чек – метрики на будущее;
Среднее число покупок – метрики на будущее;
Branch – влияние на поток в отделения банка;
CustEx – влияние на поток в контактный центр/живых сотрудников поддержки.
Time criticality = насколько быстро ценность фичи протухнет, если её не сделать сейчас
Это, пожалуй, самый абстрактный параметр, который сложно выразить в деньгах:
Отставание – от рынка и от конкурентов;
Опережение / отстройка от рынка – насколько мы можем стать пионерами или выделиться;
Смысл – насколько со временем фича потеряла смысл;
Можно жить – насколько можно продолжить жить без этой фичи.
RR | OE value = сколько срежем рисков и откроем возможностей
Страт. приоритет / джокер – фича связана с ключевым приоритетом компании или её требует выполнить кто-то из джокеров;
Потенциал – влияние на перспективу использовать эту доработку в дальнейших фичах/решениях;
Резервы – влияние на резервы для кредитования;
Вероятность штрафа/санкций – шанс возникновения штрафа/санкции, необходимо учитывать охват попадающих в кейс со штрафом;
Штраф – влияние на исполнение регуляторных требований и предписаний;
Рост бизнеса / выход на новый PAM, TAM, SAM, SOM и вот это вот всё.
Job Size = ресурс
Трудозатраты команды;
Траты на внешнего подрядчика;
Срок работ.
Ключевая мысль
Чем больше продакт считает по задаче, тем более меритократический бэклог получается на выходе. Это максимизирует эффективность продуктовых команд в парадигме закона Парето.
Пару слов вдогонку
WSJF эффективнее начинает работать когда:
Все стейкхолдеры/бизнесовнеры и вот эти вот все ребята поворкшопились, поняли как работает методика и им даже необязательно лезть внутрь, просто они понимают как команда приоритизирует бэклог;
Как следствие, у них меньше вопросов, почему фичи без описанных гипотез выгоды и целевых метрик получают единицу по тому или иному параметру;
И все пытаются выразить эффект в деньгах. Тогда cost of delay (стоимость задержки от нереализации фичи) становится ещё более прозрачным для бизнеса параметром.
Эпилог
За счет этой методологии мы снизили число созвонов, обсуждений, споров и выяснений в процессе планирования вдвое. И убрали ряд крупных мероприятий, по часу тратящих время продактов, стейкхолдеров, разработчиков.
