Аналитика Kanban: какие метрики отслеживать команде

Начните аналитику Kanban с четырёх показателей: сколько работы начато, сколько завершено, как долго выполнялись готовые задачи и сколько времени уже провели в процессе незавершённые. Затем договоритесь, какое решение команда принимает при изменении каждого показателя. Так на встрече появится конкретный вопрос: какой задаче помочь сегодня и что изменить в процессе.

Ниже — пример настройки такого разбора. Он подходит команде, у которой уже есть доска и понятные статусы. Если каждый участник по-своему понимает начало и завершение работы, сначала нужно договориться об этих границах.

Какие вопросы должна закрывать аналитика

Выбирайте показатель под вопрос, на который пока трудно ответить. Руководителя может интересовать срок новой заявки, исполнителей — растущая очередь согласования, заказчика — предсказуемость выпуска. Один график не заменяет все эти ответы.

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

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

Согласуйте границы измерения

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

Не меняйте эти определения незаметно. Когда команда переносит финиш с «Передано на проверку» на «Принято», показатели до и после изменения описывают разные участки. Отметьте дату изменения правил и не объясняйте разницу исключительно ускорением или замедлением команды.

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

Состояния доски и события перехода помогает описать рабочий процесс. Аналитика будет опираться на эти договорённости, поэтому настройка начинается с них.

Четыре показателя для первого отчёта

В The Kanban Guide редакции мая 2025 года минимальный набор включает WIP, Throughput, Work Item Age и Cycle Time. Определения можно проверить в руководстве. Все четыре показателя привязаны к согласованным границам начала и завершения.

WIP показывает количество начатых и ещё не законченных задач. Throughput — число завершённых задач за выбранную единицу времени. Cycle Time — прошедшее время между стартом и финишем. Work Item Age — время от старта незавершённой задачи до текущего момента.

Возраст особенно полезен для действий сегодня: он обращает внимание на ещё открытые карточки. Статистика завершённых задач описывает уже случившееся. Используйте оба взгляда, чтобы хорошие результаты небольших задач не скрывали работу, которая давно остаётся открытой.

Lead Time можно добавить, если нужно видеть путь от поступления запроса, включая очередь до старта. Выбранные границы подпишите прямо в отчёте. Подробности расчётов позволяют разобрать метрики потока; здесь используйте их как входные данные для решений.

Как читать показатели вместе

Рассматривайте изменение как повод проверить гипотезу. Если WIP вырос, а выпуск остался прежним, посмотрите, какая работа добавилась и где она находится. Причиной может оказаться новая партия запросов, задержка согласования или несвоевременное обновление статусов. По одному числу выбрать объяснение нельзя.

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

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

Расположение очередей по стадиям помогает прочитать диаграмму потока. Используйте её для поиска участка, который требует внимания, а причину выясняйте по задачам и разговору с участниками.

Пример еженедельного разбора

Представим учебную ситуацию: команда завершила за неделю восемь заявок, как и неделей раньше. WIP вырос с десяти до четырнадцати. Три открытые заявки находятся на согласовании дольше остальных. Эти числа придуманы для примера и не описывают отраслевую норму.

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

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

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

Где хранить данные и решения

Состояние карточки должно отражать фактическое положение работы. Если обновлять всю доску только перед отчётом, точность временных показателей придётся проверять отдельно. Назначьте понятный момент обновления: исполнитель закончил работу, проверяющий принял результат, появился блокирующий вопрос.

В Strive канбан-доска позволяет вести общие задачи по стадиям. Используйте карточки для контекста и договорённостей; перед выбором отчёта проверьте, какие даты и события конкретный инструмент сохраняет и позволяет выгрузить. Само наличие доски не означает наличия всех нужных аналитических графиков.

Если для начала нужна визуальная доска, в Канбано можно показать этапы работы. Рядом с карточками зафиксируйте правила переходов. Для первого ручного разбора достаточно согласованного реестра дат; автоматизацию выбирайте после проверки того, какие вопросы она должна закрывать.

Решение по результатам анализа оформляйте как проверяемое изменение: что делаем, кто отвечает, когда обсуждаем эффект и по каким признакам решим, оставлять ли правило. Например: «На следующей неделе назначаем согласующего при старте заявки; проверяем, остались ли карточки без владельца проверки».

Какие ошибки стоит исключить

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

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

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