Пошаговая инструкция: как построить канбан-систему в продуктовой команде и сделать процессы поставки более прозрачными и управляемыми

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

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

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

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

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

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

Итак, для чего нужен канбан-метод:

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

Канбан в создании и развитии продуктов

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

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

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

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

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

Канбан помогает работать над процессами сразу по трем направлениям: 

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

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

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

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

Обычно визуализацию начинают с процесса — то есть этапов, которые проходит работа. Для начала надо составить список всех этапов, которые уже проходит каждая задача. Причем они могут выполняться как внутри команды, так и во внешней среде. Например, если дизайн уходит в смежное подразделение, это обязательно надо визуализировать. Эффективный способ распознать все этапы — а они могут идти не только последовательно, но и параллельно, — подход STATIK (System Thinking Approach for Introducing Kanban).

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

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

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

Задачи от этапа к этапу двигаются только вперед: например, нельзя задачу с разработки передать обратно на аналитику. Если необходима доработка на предыдущем этапе, задача остается на текущем этапе и просто дорабатывается (например, лежит в колонке «разработка», а дорабатывается аналитиками). Однако надо правильно ее визуализировать — создать подзадачу на этапе разработки и обозначить ее другим цветом (например, «Уточнить формулу расчета кэшбэка при покупке от 5000 рублей»).

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

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

• Описаны Usecase-сценарии.
• Создана структура таблиц/сущностей в БД.
• Есть набросок макета.
• Информация зафиксирована в Wiki.

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

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

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

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

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

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

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

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

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

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

Как работают лимиты?

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

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

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

Tasks = People − 1

где Tasks — количество одновременно выполняемых задач, а People — количество людей на конкретном этапе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 2. На этапе тестирования возникает затык — тестировщик не успевает обработать входящие запросы, а в разработке уже скопилось много задач. Значит, команда смещается на этап тестирования, чтобы помочь разгрузить этот этап и быстрее продвинуть задачи к колонке «Готово».

О метриках, важных для управления потоком работ, будет отдельный пункт.

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

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

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

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

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

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

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

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

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

1. Канбан-митинг. На нем происходит планирование работы и управление потоком. Об этом формате мы уже говорили выше.
2. Собрание по пополнению. Выбор задач из бэклога и пополнение downstream — проще говоря, перемещение задач из бэклога в колонку «Выбрано». На такую встречу собираются основные заинтересованные лица и принимается решение, какие следующие задачи попадут в работу. Задач в бэклоге и пожеланий заинтересованных лиц всегда много, а пропускная способность команды ограничена — поэтому приходится выбирать и договариваться, какие задачи принесут наибольшую ценность продукту. 
3. Ретроспективы. Кроме похожих на Scrum ретроспективы Канбане есть дополнительные каденции обзора или ревью, одна из основных называется «ревью сервиса поставки». На них обсуждается поставка: насколько она эффективна, попадаем ли мы в ожидания заказчиков, укладываемся ли мы в сроки, какие есть блокеры и трудности. На выходе команда получает готовый план улучшений. Регулярно проводя такую каденцию, мы улучшаем процессы, взаимодействие, качество нашего продукта или сервиса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует достаточно много инструментов для ведения рабочего процесса — обычно это разного рода онлайн-доски: Jira, Trello, Youtrack и другие. Однако все они лишены гибкости и прозрачности, которую дают физические доски или их аналог в электронном виде — Miro. Но для полноценного отображения Канбан-системы понадобится специализированный инструмент, такой как Kaiten, в котором автоматически собираются метрики по производственному процессу.

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

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

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

Некоторые команды в качестве основной выбирают физическую доску на стене или Miro, чтобы наглядно видеть актуальный статус по задачам и проводить вокруг них каденции. А параллельно, в качестве второй доски, используют Jira, Youtrack или другие таск-трекеры.

Резюме

1. Главная цель канбан-метода — настроить систему постоянных эволюционных изменений в процессах, связанных с выполнением интеллектуальных задач.
2. Канбан-метод — это гибкая система и набор рекомендуемых практик, а не жесткая регламентация процессов и формальная система.
3. В канбан-методе используется шесть практик — если применять их разумно и грамотно адаптировать под особенности компании, они помогут постоянно улучшать процессы и адекватно планировать задачи.
4. Главная практика канбан-метода — визуализация процессов. А самая эффективная форма визуализации — «физическая» доска, висящая на стене в офисе или виртуальная доска в Miro. Решения вроде Trello и Asana не дают необходимой гибкости и могут использоваться для дублирования основной доски. Однако для полноценной работы с метриками и автоматического контроля правил лучше будет выбрать специализированный инструмент.
5. Эволюционные улучшения достигаются за счет максимальной прозрачности принятых в компании правил работы по канбан-методу, четкой визуализации, постоянного отслеживания метрик, петель обратной связи и экспериментов.