Правила спасения смысла в быстро меняющихся приоритетах

Материал для тех, кто пытается что-нибудь менеджерить, начиная с собственных ресурсов и заканчивая департаментами в корпорациях или корпорациями в целом.

По причине 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 эффективнее начинает работать когда:

1. Все стейкхолдеры/бизнесовнеры и вот эти вот все ребята поворкшопились, поняли как работает методика и им даже необязательно лезть внутрь, просто они понимают как команда приоритизирует бэклог;

2. Как следствие, у них меньше вопросов, почему фичи без описанных гипотез выгоды и целевых метрик получают единицу по тому или иному параметру; 

3. И все пытаются выразить эффект в деньгах. Тогда cost of delay (стоимость задержки от нереализации фичи) становится ещё более прозрачным для бизнеса параметром.

Эпилог

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