Про бизнес и метрики

Приборная панель современного авиалайнера отображает несколько десятков различных показателей. Вся эта информация требуется пилотам для принятия тех или иных решений во время полета.

Управленческие решения в бизнесе также принимаются на основании объективных показателей – метрик. Но чем больше компания, тем сложнее организовать контроль всех необходимых показателей. Многообразие всевозможных метрик, с одной стороны, дают простор для выбора, с другой – сбивают своей избыточностью.

Мониторинг даётся компаниям не бесплатно, и чтобы лучше отделить зёрна от плевел (даже после изучения понятий ванильных, NorthStar, и прочих метрик), предлагаю посмотреть на метрики ни как на данные в рамках одной команды (продукта), а как систему взаимосвязанных потоков информации.

Метрика бывает двух типов:

• бизнесовая, то есть отражающая показатели успешности бизнеса;
• процессная – отражающая показатели процесса создания продуктов.

В свою очередь, бизнесовые метрики могут подразделяться на основные и сопутствующие.

Основные – те, которые в явном виде отражают успешность бизнес-части (например, количество продаж и доход), сопутствующие – те, изменение которых влияет на изменение основных (например, посещаемость сайта).

Возможно, самым простым способом определения Основных бизнес-метрик будет взятие их из квартального отчета для генерального директора организации :)

Помимо этого, метрики обладают следующим списком атрибутов:

Стадия - может быть двух видов:

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

Длина (обратной связи) – временной интервал между совершенным действием и проверкой полученного результата метрики (другими словами – через какой промежуток времени считается целесообразным измерение полученного результата)

Стадия метрики и её длина находят своё отражение в цикле Деминга–Шухарта (PDCA):

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

Сопутствующие метрики, в отличие от основных (которые спускаются «сверху» путём декомпозиции) могут быть выбраны и установлены на любом из уровней иерархии компании (и также декомпозированы до команд).

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

Другими словам: например, перед компанией стоит задача получить доход в размере 1 млрд. рублей. Эта цель декомпозирутся по двум подразделениям – каждому заработать по 500 млн. Ввиду разного направления бизнеса подразделений, один ставит себе (самостоятельно) одну сопутствующую метрику (например, MAU), второй – другую (например, количество товаров в одном чеке при продаже). Команды, в свою очередь, также свободны в выборе тех дополнительных (сопутствующих) метрик, мониторинг которых поможет им в продвижении к достижению значения основной метрики.

Также, сопутствующие метрики становятся крайне востребованы при работе с «длинными» основными метриками, когда полученный результат таковых становится доступен через месяц, квартал или даже год. В таких случаях полезно иметь на вооружении ряд сопутствующих метрик, которые хоть и косвенно относятся к результатам основной метрики, но «короче» по длине обратной связи, и позволяют повысить управляемость процессом.

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

Совместно с релизным расписанием, такие метрики, как velocity помогают команде (и выше) понять количество попыток повлиять на бизнесовые метрики (через выпуск новых фич) за определенный промежуток времени.

Чтобы обеспечить эту прозрачность, запланированные фичи (задачи) должны быть оценены и приоритизированы. Помимо этого, при совместном выводе несколькими командами одного (либо связанного) функционала – через процессные метрики обеспечивается общее понимание отсутствия или наличия проблем в процессе разработки.

Другими словами, например, две команды работают над функционалом, который планируют вывести в релиз через полтора месяца. Используя метрики сгорания релиза (т.е. отношение суммы оценок оставшихся задач к velocity) – команды способны на ранних стадиях увидеть потенциальное непопадание к назначенной дате, либо несинхронное завершение работ (при работе над разными бэклогами)

В отличие от бизнесовых метрик, ожидание от которых спускается сверху–вниз (в иерархической структуре организации), данные о процессных метриках (результаты) «поднимаются» снизу–вверх (например, Lead Time).

В случае крупных организаций с иерархической структурой, процессным метрикам больше внимания уделяется на уровне команд, которое плавно сменяется фокусом на бизнесовые по мере «поднятия» вверх по иерархическому дереву компании.

Другими словами, очевидно, что участники команды на своём уровне больше внимания будут уделять процессным метрикам, тогда как на уровне правления основные обсуждения будут посвящены бизнесовой составляющей.

Agile–подход предполагает получение максимального результата через работу с данными от обоюдо–направленных метрик.

Особо хотелось бы отметить важность направления движения информации: данные о бизнесовых метриках «спускаются» (декомпозируются) сверху–вниз (в нашем случае – от уровня руководства компании к Командам), в свою очередь, данные о процессных метриках «поднимаются» снизу–вверх.

Именно такой формат отличает проектный подход (где «сверху» спускаются ожидания и по бизнесовым и по процессным показателям) от Agile–подхода.

Для диагностики состояния культуры использования метрик в работе организации предлагается следующий чек–лист:

• Определён список основных бизнес метрик (ЧКД, P&L и пр.);
• Бизнес–метрики декомпозированы от уровня руководства компании до Команд;
• Определены сопутствующие метрики, позволяющие производить мониторинг достижения основных метрик (количество продаж в определенном канале и пр.);
• Определён список процессных метрик (ТТМ, Velocity и пр);
• Для каждой метрики определён период обратной связи;
• Определены и автоматизированы источники информации по метрикам;
• Определены события, на которых обсуждаются ожидания и полученные показатели метрик;
• Планирование любой работы осуществляется на основании всех доступных на данный момент метрик;
• Для каждой заводимой (например, в Jira) задачи есть понимание (например, пометка), на какую метрику она будет влиять.
  

Дополнительно, для оценки доступности каждой из метрик:

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

После заполнения чек–листа становятся очевидны пути улучшений.

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

Отчет о продажах на столе генерального директора и BurnDown Chart на стене у разработчиков – это не цифры из разных миров, это взаимозависимая информация, позволяющая держать ситуацию под контролем.

Поэтому не существует главной или идеальной метрики, наблюдение за которой решало бы все проблемы в компании. Метрики в принципе не решают проблем – их решают люди, основываясь на полученных показателях.