Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России

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

Что такое и для чего нужен канбан-метод?

Канбан-метод — это метод управления потоками интеллектуальных задач. Его цель — помочь визуализировать работу, повысить эффективность процессов и постоянно совершенствоваться (проводить эволюционные изменения).

Есть три основных принципа управления изменениями и шесть Канбан-практик, общих для любых применений Канбана. Принципы:

• Начните с того, что есть сейчас ( то есть возьмите текущий процесс в том виде в котором он есть)

• Придите к соглашению об эволюционном развитии (договоритесь что будете меняться)

• Поощряйте проявления лидерства на всех уровнях (поощряйте идеи и желание менять на всех уровнях)

Для чего же нужен Kanban?

• В первую очередь — запустить эволюционные процессы в команде. Как это происходит: он помогает визуализировать и понять, что происходит в команде прямо сейчас — а уже это понимание дает ресурс для изменения процессов. 

• Сделать рабочий процесс прозрачным, а процесс поставки предсказуемым. 

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

• И как следствие - гарантировать поставку точно вовремя в соответствии с ожиданиями Заказчиков

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

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

В обоих случаях причина — создание ложных ожиданий и хаотичная смена приоритетов.

Шесть базовых практик канбана

Практика 1. Визуализация

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

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

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

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

Например, на этапе аналитики мы можем зафиксировать некоторые критерии готовности элементов:

• Описаны Usecase-сценарии

• Создана структура таблиц/сущностей в БД

• Есть готовые мокапы в Figma

• Информация зафиксирована в Wiki

Эти критерии зависят от вашего контекста и договоренностей внутри команды.

Теперь необходимо визуализировать саму работу по каждому этапу. Эта часть делится на два этапа.

Этап 1. Визуализируем конечные поставляемые элементы на этапах, как уже показано на рисунке выше, на зеленых карточках. То есть мы берем все задачи, которые у нас есть, и помещаем их на доску. Вот пример формата такой карточки:

Этап 2. Визуализируем, что происходит с каждым элементом на каждом этапе. Тут возможно два варианта: 

• либо по задаче планируется что-то сделать до завтра, то есть ведется активная работа и мы можем сформулировать, что конкретно мы сделаем и кто именно это сделает;

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

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

После того, как мы вывесим все задачи на доску и отразим текущий статус по ним, может получиться примерно такая картина:

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

Практика 2. Ограничение количества задач

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

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

Поэтому на каждом этапе надо обозначить четкие лимиты. Их трудно просчитать на старте — как правило, они определяются эволюционно и эмпирически: мы смотрим, как движется работа, какие есть возможности на каждом этапе, и уже исходя из этих данных выставляем определенные ограничения. 

Однако от какой-то реалистичной цифры надо отталкиваться, поэтому в самом начале можно воспользоваться простой формулой:  

Work in progress = People - 1

И если у вас на этапе аналитики работает два аналитика, то и первоначальный лимит будет равен одной задаче, например одну задачу могут делать два аналитика или в какой то момент аналитик может быть задействован на другом этапе или вовсе отсутствовать. Лимит распространяется целиком на этап: суммарно на задачи «В процессе» и «Готово».

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

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

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

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

Практика 3. Управление потоком работы

Чтобы задачи завершались быстро, равномерно и предсказуемо, а команда фокусировалась на результате, нужно в первую очередь следить за работой и потоком задач, а не за людьми.

А чтобы научиться управлять потоком задач, необходимо постоянно смотреть, как этот поток движется: изучать метрики потока и управлять работой. Один из инструментов управления работой — ежедневные собрания (канбан-митинг), на которых команда планирует работу на день и обновляет доску. 

Синхронизация происходит справа налево. Команда берет крайнюю правую задачу, которая находится ближе всего к колонке «Готовое», и задает вопрос: «А что мы сделаем, чтобы передвинуть эту задачу в следующую колонку?». Так разбирается каждая задача, а потом составляется план по работе с ней, фиксируются блокеры (то есть внешние задачи, от которых зависит завершение вашей задачи) и краткий план их устранения. Это и есть управление потоком.

Практика 4. Сделать правила явными

Все нюансы работы с канбан-системой должны быть явными, конкретными, недвусмысленными и понятными для всех — плюс их необходимо зафиксировать и визуализировать: каким образом работает наша система, по каким правилам, какие критерии готовности каждого этапа мы определили — что мы должны сделать на каждом из этапов, чтобы считать его завершенным — как мы определяем срочные задачи, как часто пополняем downstream из бэклога, кого приглашаем на пополнение и так далее. 

Практика 5. Вводите петли обратной связи

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

Основные каденции: 

• Канбан-митинг. На нем происходит планирование работы и управление потоком. Об этом формате мы уже говорили выше.

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

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

Каденций в Kanban методе больше, но мы рассмотрели самые основные.

Практика 6. Улучшай и эволюционируй

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

Фактически шестая практика аккумулирует данные от предыдущих пяти практик и позволяет выполнять главную цель канбан-метода — постоянные эволюционные улучшения на основе метрик и экспериментов. 

Метрики в канбан-системе

Решения по улучшениям мы должны принимать на основе данных — как и продуктовые решения. А значит, эти данные необходимо собирать и использовать. 

В Канбане есть много метрик: накопительная диаграмма потока, контрольные карты, спектральная диаграмма, время решения блокировок и др. Я расскажу о двух основных:

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

• Распределение времени выполнения задачи. Считается от момента, когда мы вытягиваем задачу из бэклога и берем в работу, до перемещения в колонку «Готовое». 

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

Пример: на распределении мы видим, что команда выполнила 34 задачи. 

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

• С вероятностью в 90% мы можем утверждать, что задача будет сделана менее, чем за 24 дня, потому что выполнение 90% задач уложилось в этот срок.

Как правило прогнозы стоит давать с вероятностью в 90% и заключать Service level agreement именно на этом уровне — это достаточная вероятность для прогноза.

В чем вести Канбан

Существует достаточно много инструментов для ведения рабочего процесса — обычно это разного рода онлайн-доски: Jira, Trello, Youtrack и другие. 

Если вы работаете в офисе и собираетесь с командой вместе, я рекомендую использовать физические доски, вокруг них вы собираетесь и обсуждаете работу которую необходимо сделать. Коммуникация face-to-face и физическое передвижение карточек бесценно. Второй вариант - аналог физических досок  — это сделать доску в  Miro и начать вести процесс по ней. Этот подход позволяет увидеть все на плоской картине.

Однако вы также можете вести процесс и в Jira создав необходимые доски и правила работы с ними. Либо в любом другой таск-трекере.

Если понравилась статья, переходи в мой телеграм-канал и забирай больше пользы о Kanban методе и других подходах к организации процессов

В заключение напомню об открытом уроке, который пройдёт 21 мая в OTUS: «Исполнение и контроль проекта». На уроке углубимся в жизненно важные аспекты успешного исполнения и контроля проектов. Начнем с обзора методов организации ресурсов и команды проекта. Если актуально, записывайтесь бесплатно по ссылке.