Как стать автором
Обновить
0

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

Время на прочтение5 мин
Количество просмотров2.7K

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

По причине 2022 года возникла постоянная смена стратегических направлений из-за повышенной турбулентности всего мира.

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

В итоге:

  • Фичи (задачи с понятной ценностью для бизнеса и клиента), начатые в рамках предыдущих стратегических приоритетов, брошены;

  • Ценностей ни бизнес, ни клиент не получили;

  • Все поработали впустую;

  • Правила игры непонятны;

  • Большая часть приоритетов выглядит классически авторитарными;

  • Все демотивированы.

Снова начался поиск ответа на вопрос «ну, и как планировать и приоритизировать работу?».

Капля воды в начале

Я давно искал ответы на эти вопросы в методах работы и моделях приоритизации. Перетестил RICE, PIE, ICE, Kano, матрицу Эйзенхауэра, weighted scoring и даже кое-что самодельное. В 2017 я познакомился с методологией WSJF (weighted shortest job first). Через год тестирования механизма: Kanban (метод работы, при котором проще попадать в ожидания) плюс WSJF – всё заработало. Это было в относительно небольшой компании, в рамках малой пропускной способности и ограниченных ресурсов на всех уровнях – от фич до программ (например, полноценный запуск нового продукта) или направлений бизнеса…

Суть

Придя в Хоум Кредит Банк, я попал в идущий полным ходом процесс внедрения SAFe, в котором также используется приоритизация WSJF.

ещё числитель называют "стоимость задержки" или cost of delay
ещё числитель называют "стоимость задержки" или cost of delay

Год с лишним в Хоуме мы адаптировали методологию к подходам в банке. Естественно, часто внутренний заказчик требует выполнить ту или иную задачу в директивном порядке, и именно в борьбе с директивной парадигмой нам очень помогает 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 (стоимость задержки от нереализации фичи) становится ещё более прозрачным для бизнеса параметром.

cost of delay = user | business value + time criticality + rr | oe value
cost of delay = user | business value + time criticality + rr | oe value

Эпилог

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

Теги:
Хабы:
Всего голосов 6: ↑4 и ↓2+4
Комментарии5

Публикации

Информация

Сайт
home.bank
Дата регистрации
Численность
свыше 10 000 человек
Местоположение
Россия

Истории