«Как и на какие метрики смотреть в поисках зоны роста команды?» — на эту тему менеджеры проектов в нашей компании задумываются регулярно, так как менеджеры отвечают в том числе и за эффективность процессов. Правильный ответ на вопрос будет зависеть от контекста команды, заказчиков, продукта, рабочего процесса и много чего еще. Но можно выделить ряд метрик и отчетов, построенных на этих метриках, которые будут универсальны, и которые можно брать за основу для анализа. А поскольку hh.ru — компания, которая несколько последних лет применяет Kanban-метод, то и метрики ниже будут сильно пересекаться с тем, что этот метод предлагает.
Меня зовут Денис Николаев, и я менеджер проектов в hh.ru. В этой статье покажу, на какие основные отчеты смотрю я. Также добавлю примеры того, на что обращать внимание в этих отчетах, чтобы в дальнейшем работать над повышением эффективности.
Базовые термины
Прежде, чем мы начнем, давайте дадим пару определений:
Сервис — обслуживающая единица, представляющая собой одного или нескольких людей, совместно делающих работу (чаще всего нематериальную) по созданию продуктов.
Процентиль — это значение, которое заданная случайная величина не превышает с фиксированной вероятностью, заданной в процентах. Например, если мы говорим, что 85й процентиль lead time’а равен 100 дням, это означает, что 85% задач делается не дольше 100 дней.
Lead time — это время, потраченное на выполнение задачи: с момента взятия обязательств до полного выполнения.
Cycle time — время, которое задача находилась в работе в определенном цикле.
Класс обслуживания — категория, которую можно назначить входящему запросу, чтобы определить очередность его выполнения для достижения максимальной выгоды бизнесом.
Гистограмма lead time
Одна из базовых метрик — это lead time. Наш lead time начинается, когда любой член команды начинает работу над фичей, и завершается, когда клиент получает конечную ценность. Таким образом, наш lead time включает этапы Discovery (включающий 4 внутренних статуса), Delivery (4 статуса), AB-тест (3 статуса) и даже PostProduction (на этом этапе мы занимаемся всем тем, что не успели сделать на предыдущих этапах - удаляем код эксперимента, проводим маркетинговые активности и тд).
Я буду показывать отчеты на примере внутренней интегрированной с Jira системы, которую мы разработали, и которую я поддерживал и развивал последние пару лет. Не буду ее рекламировать для всеобщего использования, тк из-за сильной кастомизации под наши процессы мы в свое время отказались от идеи держать ее в виде open-source проекта. Все те же графики и их анализ можно строить и проводить в Excel, Grafana и тд. Также можно использовать Jira Metrics Plugin, разработанный моим коллегой Анваром Хакимовым. Этот плагин часто применяется в hh.ru и других компаниях для построения аналитических отчётов. Подробная документация, как пользоваться плагином, доступна на сайте проекта.
Первый график, который мы создали, — гистограмма lead time, чья основная цель — показать, сколько фич мы выпускаем за определенное время. На примере рисунка 1 видно, что 3 задачи делались 20-25 дней, 1 задача делалась 25-30 дней и тд.
Все данные на графиках вымышленные.
На основе этого графика можно сделать сразу несколько важных выводов. Во-первых, гистограмма показывает, как ваша система справляется с отклонениями. Если вы видите длинный или «толстый» хвост, это означает, что система непредсказуема и плохо работает с отклонениями. Однако иметь небольшие хвосты нормально, потому что иногда борьба с отклонениями стоит больше ресурсов (времени или денег), чем их негативные последствия. Кстати, определить «толстый» хвост можно не только на глаз, но и математически. Есть несколько способов сделать это, например, Kanban University предлагает считать хвост толстым, если его график оказывается выше графика экспоненты. Математически это вычисляется по формуле:
Кроме того, на этом графике мы можем увидеть различные процентили lead time. Чтобы отсечь нежелательные хвосты и увидеть более честную картину сервиса, как правило, используют значения от 80 до 99го процентиля. Мы используем 85й процентиль — это скорее исторически сложившаяся у нас (да и в целом на рынке) практика.
Например, на рисунке 1 мы видим, что Команда 1 хорошо справляется с «хвостами», и у неё нет сильных отклонений. А у Команды 2 на рисунке 2 нет явного пика, зато есть длинный хвост. Поэтому предсказать её lead time сложнее. Это означает, что по этому графику мы не можем с высокой долей определенности предсказать, сколько времени вторая команда потратит на следующую задачу. Однако для первой команды мы можем более точно предугадать lead time будущих задач с 85%-ной уверенностью.
Далее, если на графике видно более одного ярко выраженного пика, это может указывать на различные классы обслуживания. В нашем случае рисунок 2 имеет пологий график без выраженных всплесков. А вот на рисунке 1 визуально проявляются 2 пика. Но, во-первых, стоит еще накопить данных, так как задач относительно немного, а, во-вторых, только последующий качественный анализ задач позволит подтвердить или опровергнуть предположение о разных классах обслуживания.
В следующих примерах я буду более детально рассматривать метрики второй команды.
BoxPlot:
После того как мы проанализировали lead time, мы можем сосредоточиться на статусах, которые на него влияют. Рисунок 3 показывает 1-й, 25-й, 50-й, 75-й, 99-й и 100-й процентили для каждого статуса.
Во-первых, на графике можно обнаружить, что на некоторые статусы тратится больше времени, чем вы ожидали. Это типичная ситуация для буферных статусов. Часто вы не замечаете, сколько времени они занимают. Но они оказывают сильное влияние на lead time. Не важно, активно вы работаете над задачей или просто ждёте чего-то, ваш клиент всё это время ожидает фичи. Длительный буферный статус может объясняться тем, что следующий статус является узким местом в вашей системе, и его нужно оптимизировать. На рисунке 3 статус «Development: done» является самым продолжительным из буферных статусов, но при этом он не настолько большой, чтобы сказать, что у нас здесь явная проблема.
Во-вторых, вы можете обратить внимание на соотношение времени между различными статусами. На основе этой информации можно принимать управленческие решения. Например, если вы видите, что на тестирование уходит катастрофически больше времени, чем на разработку, это может подтолкнуть вас к перераспределению ресурсов.
В-третьих, как и в случае lead time, график позволяет следить за выбросами. В нашем случае есть непредсказуемые статусы, такие как «Solution Discovery: In Progress», «Development: In Progress» и даже «Feedback» (который не включён в lead time). Смотря на рисунок 3, можно предположить, что в 75% случаев мы проведем исследование/разработку/предоставление обратной связи довольно быстро. Однако последние 25% фич могут занимать значительно больше времени.
Как бонус, этот график позволяет определить статусы, которые вы больше не используете, что может подтолкнуть вас пересмотреть воркфлоу. Например, на нашем графике это “Problem Discovery: done” (пустые статусы AB-тестирования в нашем случае связаны с тем, что они появились совсем недавно).
Квартальный отчёт
На предыдущих шагах мы посмотрели на значения lead time, изучили, как на него влияют cycle time’ы. Задумайтесь на секунду, а как определить, хорошее оно или плохое? Может, сравнить разные сервисы? Я считаю это плохой идеей, потому что у разных сервисов разные стейкхолдеры, особенности, контексты, продукты, команды, люди и тд. Вместо этого мы можем сравнить наш сервис с... нашим же сервисом в прошлом. Сравнение кварталов позволяет отследить тенденцию. При этом сравнивать значения на дистанции меньше года не имеет смысла, чем больше этот период, тем точнее будет картина. Обращу внимание , что квартальные отрезки хорошо работают персонально с нашей продолжительностью разработки фич. Если ваши задачи меньше или больше, вам стоит скорректировать временные рамки.
График на рисунке 4 позволяет посмотреть как lead time, так и время различных циклов. На этом рисунке мы видим увеличение lead time (его 85-й процентиль, на самом деле), связанное с увеличением времени на разработку. Если обратиться к рисунку 2, мы можем определить несколько крупных задач, которые внесли вклад в увеличение lead time.
Контрольная диаграмма
Еще один способ измерения динамики — использование контрольной диаграммы (Control chart). Она позволяет оценить предсказуемость нашего сервиса и выявить сигналы, указывающие на рост или снижение энтропии системы. На рисунке 5 синяя линия показывает среднее значение за каждый период времени, а розовая область отражает стандартное отклонение. Более толстая розовая область говорит о худшей предсказуемости. Например, мы видим, что в третьем квартале предсказуемость ниже, чем в предыдущем периоде, и связано это в первую очередь с более серьезными выбросами.
Важно относиться к этой диаграмме с осторожностью, так как она наиболее полезна для сервисов, которые производят очень однотипные продукты (например, для фабрик). Сообщество спорит на тему, можно ли применять этот график в таких сложных системах, как тех, которые заняты разработкой ПО. На мой взгляд, если и да, то только предварительно фильтруя и сравнивая наиболее однотипные задачи (например, изначально одинаково оцененных). Очень подробно об этом отчете можно почитать, поискав блог Василия Савунова.
Кумулятивные диаграммы потока
А еще за динамикой cycle time’ов можно следить с помощью кумулятивной диаграммы (рисунок 6). В теории Канбан-метода она является одной из ключевых, и заслуживает отдельного внимания. Поэтому ее анализ я оставлю на будущую статью.
Табличный вид
После анализа глобальных метрик мы можем углубиться в локальные проблемы. Для этого нам нужно сосредоточиться на каждой проблемной фиче. Симптомом такой проблемы для меня, как правило, служит либо нахождение в каком-либо статусе более 25 дней, либо ошибка прогнозирования более 30%. По каждой такой фиче можно проанализировать, на каких этапах и в рамках каких подзадач у нас возникали проблемы. Нам очень помогает практика, когда в ходе работы над задачей разработчики фиксируют в jira возникшие проблемы. Если они вызывают остановку работы над задачей, то мы ставим задачу на блокировку и также отслеживаем это в последующем анализе. Для удобства все статусы всех задач фичи отображаем на таймлайне (рисунок 7).
Пропускная способность
Я редко анализирую задачи на уровне ниже фичи, но пропускная способность задач (а не фич) — это одна из метрик «здоровья», которую я отслеживаю. График на рисунке 8 показывает, сколько задач наша команда завершает каждую неделю. Если мы замечаем какие-либо аномалии, это сигнал о необходимости разобраться в их причинах. Например, на этом графике иногда отлавливаются даже отклонения, связанные с политической ситуацией в мире. В этом случае важно убедиться, что разовое изменение не становится впоследствии нормой.
Как сравнить Story points и время разработки?
Короткий ответ — никак. Фактически это плохо связанные между собой сущности. Ситуативно мы экспериментировали с измерением story points и их сравнением с потраченным временем. У нас даже есть отдельный график на эту тему. Но, на мой взгляд, в этом нет особой ценности. Мы пытались найти корреляцию между:
временем разработки и оценкой в story points;
количеством дней, потраченных на один story point, и общей оценкой фичи;
ошибками в оценках и самими оценками;
частотой изменения дедлайнов и оценкой фичи.
Результирующие графики показали слабую или отсутствующую корреляцию между этими параметрами. Я считаю, что это связано с ошибками в оценках, сложностью задач и среды, в которой мы работаем.
Заключение
В статье я обзорно прошелся по основным метрикам и возможным ключевым выводам, основанных на них. Если суммировать, как и на какие метрики смотреть в поисках зоны роста команды, то:
Проанализировать текущий lead time, опираясь на его гистрограмму.
Проанализировать влияние отдельных этапов на leadtime с помощью box plot – диаграммы.
Чтобы понять, насколько удовлетворительны полученные значения, изучить lead time и cycle time в динамике (например, сравните их по кварталам). В некоторых случаях по контрольной диаграмме можно также определить предсказуемость системы в динамике.
Перейти от общего к частному и проанализировать «проблемные» фичи.
Регулярно мониторить пропускную способность вашего сервиса.
В этой последовательности или в укороченных ее версиях я регулярно наблюдаю за поведением нашей системы. Многие отчеты сопровождены сноской, что в сообществе либо есть сомнения по поводу эффективности этих графиков, либо есть несколько трактовок. Поэтому метрики — это важный, но не единственный способ получить знания о системе. Например, сбор обратной связи - прекрасный инструмент, который важно использовать параллельно с метриками для получения полноценной картины. Поэтому я призываю наблюдать за метриками (возьмете ли вы описанные в этой статье или какие-то другие), внедрять их анализ в цикл непрерывных улучшений, и не ограничиваться только метриками.
