Напишите нам

Определение бизнес-ценности SAFe Business Value

Перевод оригинальной статьи от SAFe.

Первая часть статьи "Метрики SAFe: результаты, поток, компетенции".
Вторая часть статьи "Метрики потока".

Частый вопрос руководителей уровня команды команд – как определить продуктивность команды? Давно понимают, что количество строк кода не говорит об эффективности. Но и количество стори поинтов или идеальных часов тоже не сообщает, какая польза бизнесу предоставлена. Полезный и простой вариант – назначение бизнес-ценности командным целям, а затем определение фактического достижения.
Зачем команды формулируют цели на квартал
1. Подтверждается понимание командами того, чего хотят добиться бизнес-владельцы.
2. Фокусироваться на том, “что” нужно получить, а не “как” это сделать.
3. Обобщение плана на управляемый уровень детализации - желательно не более 10 пунктов.
4. Получение в конце квартала информации о продуктивности программы путем присвоения каждой цели бизнес-ценности - об этом ниже (ART, Release train, PI).
Нужно выбрать proxy для определения бизнес-ценности
Для наших фичей в бэклоге программе мы рассчитали WSJF, чтобы упорядочить их. Почему бы не использовать WSJF в качестве бизнес-ценности?
1. Фичи могут распределиться между командами.
2. В бэклоге команды могут появиться истории, связанные с эпиками, но не фичами.

Критерии, которые полезно учитывать при определении бизнес-ценности:
  1. Ценность для пользователя и удовлетворенность клиента.
  2. Критичность по времени – Можно ли выполнить в следующем квартале, или нужно сделать сейчас? И почему?
  3. Риски – Поможет ли это снизить риски или повысить будущую предсказуемость?
  4. Доля рынка – Позволит ли это привлечь новых или удержать текущих хороших клиентов?
  5. Операционная эффективность – Поможет ли это снизить операционные расходы?
  6. Штрафы – Будут ли штрафы, если не сделаем? Какие?
  7. Новые знания – Поможет ли это проверить гипотезу?
  8. Постоянные улучшения – Поможет ли это улучшить нашу систему?
Соответствие Team Objective и Feature
  • Некоторые фичи могут быть поставлены одной командой, и однозначно 1-1 соответствуют цели этой команды (Team’s PI objective). Однако цель стоит формулировать в виде получаемого результата, поскольку зачастую эту же цель можно достичь и фичей меньшего размера.
  • Некоторые фичи требуют взаимодействия нескольких команд, и у этих команд появится соответствующая цель на квартал.
  • Дополнительно у команды могут появиться технические цели (enabler), упрощающие последующие доработки: PoC, инфраструктура, архитектура, производительность и пр.
Рис. 1 Соответствие между фичами и целями команд
Примеры целей команды приведены в таблице ниже.
Присвоение BV при планировании инкремента программы
Во время планирования инкремента программы в ходе личного общения с командой владельцы бизнесов присваивают значение “бизнес-ценности” каждой из целей команды (PI Planning, Team's PI Objectives, Business owners, Business value, BV). Цели команды – это результаты, которых команда собирается достичь.

Такой живой диалог между бизнес-владельцами и командой во время планирования квартала крайне полезен, поскольку помогает:
1. Укрепить взаимоотношения между Agile-командами и владельцами бизнесов.
2. Выявить общие риски, для работы по которым необходимо вовлечение всех участников.
3. Лучше понять бизнес-цели и их ценность.
4. Транслировать стратегию и контекст, объясняющий присвоенные целям веса.
5. Эти оценки используются командами для планирования последовательности реализации.
6. После планирования при реализации команды смогут самостоятельно децентрализованно производить корректировки скоупа, по-прежнему предоставляя максимально возможную пользу.
7. Дополнительно, эти оценки будут использованы для расчета метрики предсказуемости программы в конце квартала (PPM, Program Predictability Measure).
Бизнес-ценность именно присваивается, а не рассчитывается. Это гипотезы бизнес владельцев о том, что принесет наибольшую ценность организации. Обратная связь по этим гипотезам будет получена уже через квартал – небольшой срок для крупной корпорации.
Владельцы бизнесов оценивают каждую цель команды, используя шкалу от 1 (самая низкая) до 10 (самая высокая).
Цель с оценкой 10 в 2 ценнее, чем цель с оценкой 5.
Оценки не обязательно выравнивать между командами, тогда у каждой команды есть своя “10”, или даже несколько таких “десяток” – элементов бэклога команды с наивысшим приоритетом. Однако можно и выравнять.

Целями команды могут быть (Team's PI Objectives):
  • Пользовательские фичи (features) – основная часть целей команды. Они сразу же и напрямую приносят ценность пользователям, клиенту, рынку. Поэтому обычно бизнес-владельцы присваивают им наивысшие значения ценностей.
  • Технические задачи (enablers) включают улучшение инфраструктуры, развитие сред разработки, изменение архитектуры, повышение качества. Их выполнение позволяет командам в дальнейшем встречать меньше технических препятствий и быстрее создавать бизнес-ценность. Владельцы бизнесов обращаются за советом к техническими специалистами, чтобы присвоить бизнес-ценность таким целям.

BV присваивается и обязательным, и необязательным целям (committed & uncommitted). Иногда BV необязательной цели больше, чем BV обязательной – это ОК. Так бывает, когда какая-то зависимость, риск и блокер не позволяют команде пообещать достижение важной цели.

Business value проясняет ценность задач, но не подразумевает последовательность выполнения задач. Последовательность определяется далее в ходе PI Planning, когда команды совместно создают общий план квартала на PI Board, учитывая зависимости, доступную трудомощность и общие вехи.
Оценка фактической BV при инспекции и адаптации PI
В конце квартала программа (ART, релизный поезд) проводит встречу “Инспекции и адаптации” (Inspect and Adapt, I&A), чтобы оценить и проанализировать прогресс и системные проблемы.
Встреча состоит из трех частей:
  • Демонстрация инкремента программы (PI System Demo)
  • Качественные и количественные оценки
  • Ретроспектива и решение проблем
Перед демонстрацией или во время нее владельцы бизнесов снова встречаются с каждой Agile-командой (как и при планировании) и оценивают фактически полученную бизнес-ценность
для каждой цели команды.

Команда может ощущать дискомфорт, потому что их оценивают. Поэтому эта оценка производится в диалоге между командой и владельцами бизнеса.
Смотрят на:
  1. Качество – цель достигнута частично.
  2. Содержание – цель достигнута частично, если, например, планировали повысить скорость на 50%, а повысили только на 30%.
  3. Своевременность – цель достигнута не вовремя, например, необходимо было запустить сервис раньше.

Actual BV может быть равной Planned BV, ниже нее или нулю.
  • Если команда достигла цели, то ABV устанавливается равной PBV, даже если бизнес-владелец уже не считает эту цель настолько ценной для бизнеса – ведь не получится оценить предсказуемость достижения цели, если цель изменяется.
  • Если команда вообще не достигла цели, то ABV = 0.
  • Если команда достигла цели частично, то происходит обсуждение между бизнес-владельцем и командой. Например, если достижение цели предполагало реализацию нескольких фичей, а команда поставило лишь часть из них, то бизнес-владелец присвоит какое-то значение ABV < PBV. Не используется подход “либо полное значение PBV, либо 0” – если команда доставила частичную ценность, то ее заслуги стоит признать.
Важно, чтобы бизнес-ценность определялась только уровне командных целей PI.

Далее для каждой команды рассчитывается суммарный фактический размер предоставленной бизнесу ценности. При подсчете учитываются и обязательные, и необязательные цели (committed & uncommitted), как показано на рисунке ниже. Напомню, что при подсчете плановой BV необязательные цели не учитываются.
Рис. 5 Необязательные цели тоже учитываются в фактическом размере предоставленной бизнесу ценности
Использование BV для расчета метрики предсказуемости программы PPM
PPM – одна из метрик потока. Мы подробнее рассмотрели эти метрики здесь.

  1. Бизнес-ценность определяется только уровне целей каждой команды. При планировании квартала – плановые, в конце квартала – фактические.
  2. Затем значения бизнес-ценности целей суммируются для каждой отдельной команды – см. “Totals 50 / 45” на рисунке выше.
  3. Затем вычисляется отношение "actual / planned" для каждой команды – это предсказуемость команды – см. “Achievement = 90%" на рисунке выше.
  4. Затем по предсказуемостям всех команд программы вычисляется средняя – это метрика предсказуемости программы (МПП, PPM) – см. рисунок ниже.
Рис. 6 Предсказуемость программы по кварталам – средние по значениям предсказуемостей команд
Надежные команды и программы работают в диапазоне 80–100% предсказуемости. Это позволяет бизнесу и заинтересованным сторонам планировать эффективно. Подробнее об этой метрике читайте с статье “Метрики потока”.
Использованные источники
Для написания этой короткой прикладной статьи собраны части информации из 6 разных статей SAFe (ниже) и 6 видеороликов, которых нет в свободном доступе:
Подойдет ли вам?
Напишите нам, мы с вами свяжемся и подскажем, насколько такой подход применим в вашей ситуации.
Связаться с нами
Возможно будет интересно
Метрики SAFe: результаты, поток, компетенции
Метрики потока

Внедрение Scaled Agile Framework

SAFe®