Максим Цепков - Менеджмент цифрового мира

В Kanban тоже есть несколько хороших визуальных представлений. Одно из них – кумулятивная диаграмма потока, на которой каждый день по вертикали откладывают число задач, находящихся на каждой стадии, как показано на рисунке. В результате по горизонтали мы можем увидеть, сколько времени в среднем занимает каждая фаза и, в том числе выделить непропорционально большие фазы, как это показано на приведенном примере диаграммы, на котором видно, что задачи очень долго отлеживаются на согласовании у CEO. Пример взят из уже упоминавшегося выше доклада Алексея Пименова на AgileDays-2019 « Скрытая механика работы Kanban Method».

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

Это все – конкретные примеры, и их можно приводить довольно долго. Но это именно примеры, а не универсальная система метрик. Конечно, было бы очень привлекательно получить именно универсальную систему, однако опыт развития IT говорит о том, что ее не существует. Однако, выработка системы метрик для конкретной компании или конкретной команды – вполне обозримая задача, есть много разных докладов на конференциях о конкретных системах метрик. И основную ценность в них представляет не конкретная система метрик, а логика, в которой к ней шли. Собственно, это – частное проявление пути Kanban: мы внедряем не конкретный процесс, а запускаем эволюционное развитие процесса, в данном случае – экспериментируя с разными метриками и индикаторами для повышения предсказуемости работы и мониторинга здоровья. На этом я закончу разговор метриках.

Каденции и синхронизация.

Как известно, в Scrum со спринтом связан ряд встреч: daily scrum, планирование, демо, ретро, а помимо них есть и другие встречи, такие как story mapping для планирования релизов. Все они обеспечивают синхронизацию процесса и взаимодействие со стейкхолдерами. Как легко догадаться, эти функции являются необходимыми для организации потока создания ценности и должны быть выполнены при любом способе организации процесса. В Kanban для выполнения этих функций используются каденции – регулярные встречи, каждая из которых посвящена определенному вопросу и имеет свой собственный ритм, зависящий от соответствующего потока работы.

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

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

– Пополнение списка задач – обсуждение, какие именно задачи сейчас являются наиболее приоритетны и должны быть включены в работу. Обычно раз в 1—2 недели.

– Планирование поставки – представление сделанного и передача результата клиентам

– Обзор качества сервиса и способов его улучшения.

– Операционная встреча по качеству взаимодействия со смежниками.

– Обзор рисков, связанных с блокировками выполнения задач и их влиянием на работу сервиса.

– Обзор и обновление стратегии.

Заметим, что все они в том или ином виде есть в Sсrum, только привязаны к спринту, за исключением последней.

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