Kanban: что это, как работает метод и как внедрить его в проекты крупного бизнеса

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

Название связано с японским словом, которое обычно переводят как «сигнальная карточка». Подход берёт свое начало в производственной системе Toyota. Сейчас Kanban-метод используют шире, например, для управления профессиональными сервисами или работой ИТ-команд. В официальном руководстве Kanban University (англ. университет Канбан) метод рассматривается именно как управленческий подход, который накладывается на существующий способ работы, а не как жесткий фреймворк с обязательными ролями и процедурами. 

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

Например, процесс разработки может выглядеть так:

Запрос → Анализ → Разработка → Проверка кода → Тестирование → Приемка → Готово

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

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

Команда видит общую картину и все понимают:

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

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

Классификации типов Kanban, как в случае со Scrum-фреймворками, нет. Метод адаптируется под конкретный рабочий процесс. На практике можно выделить несколько вариантов применения.

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

Доска отражает движение задач внутри отдельного проекта.

Вот так, например, выглядит проект внедрения CRM:

Требования → Проектирование → Настройка → Интеграции → Тестирование → Обучение → Запуск

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

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

Вместо завершения фиксированного объема работы команда постоянно принимает новые запросы по мере освобождения ресурсов.

Используется для управления потоками на уровне нескольких команд или подразделений производства.

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

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

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

В основе Kanban лежит несколько принципов.

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

Канбан доска собирает работу в одном представлении.

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

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

Количество одновременно выполняемых задач ограничивается с помощью WIP-лимитов (от англ. Work in Progress — работа в процессе выполнения). Это ограничения на число одновременно выполняемых задач в рамках отдельного этапа рабочего процесса.

Например, если установлен WIP-лимит 5, команда не начинает шестую задачу, пока одна из пяти текущих задач не перейдет на следующую стадию.

Это помогает команде сконцентрироваться на завершении работы.

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

Методология Kanban не требует одномоментной перестройки работы всей организации.

Команда может начать с одного процесса и, наблюдая за ним, постепенно менять правила.

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

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

На практике методология Kanban помогает решать несколько задач:

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

1. Прозрачность. Статус работы становится доступен команде и руководителю.
2. Гибкость. Новые задачи можно добавлять в поток без обязательного ожидания следующего спринта.
3. Контроль нагрузки. WIP-лимиты помогают ограничивать количество незавершенной работы.
4. Поиск узких мест. Очереди и задержки становятся заметны непосредственно на доске.
5. Предсказуемость. Статистика по времени выполнения позволяет делать более обоснованные прогнозы.
6. Постепенное внедрение. Не требуется полностью менять существующую организацию работы.

Kanban не является универсальным решением. Если процесс вообще не определен, одна доска не создаст управляемость. Сначала нужно понять, какая работа выполняется и как встроена в систему.

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

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

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

Главный инструмент Kanban — канбан-доска. Однако полноценная система состоит из нескольких элементов.

Доска показывает этапы рабочего процесса и положение задач.

Для ИТ-команды базовый вариант может выглядеть так:

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

Карточка содержит информацию о конкретной единице работы.

В ИТ это может быть:

• пользовательская история
• заявка
• ошибка
• запрос на изменение
• интеграционная задача
• функциональное требование
• инфраструктурная задача
• задача проекта

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

WIP означает Work in Progress, то есть работу, которая уже начата, но еще не завершена.

Лимит задает максимальное количество карточек на конкретном этапе.

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

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

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

Такие правила часто называют политиками процесса.

Не все задачи одинаковы. Например, в сфере ИТ могут существовать обычные задачи, срочные инциденты, задачи с фиксированной датой или крупные инициативы.

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

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

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

Без метрик Kanban превращается в обычную доску задач. Внедрение основных показателей важно для скорости и стабильности потока.

Lead Time (англ., время выполнения) показывает, сколько времени проходит от появления запроса до его завершения. Например, бизнес передал заявку 1 сентября, а результат получил 12 сентября. Lead Time составляет 11 дней.

Этот показатель важен для оценки сервиса с точки зрения заказчика.

Cycle Time (англ., время цикла) измеряет время, которое задача проводит в активной работе. Если задача поступила в разработку 5 сентября и была готова 9 сентября, Cycle Time составляет четыре дня.

Сравнение Lead Time и Cycle Time помогает понять, сколько времени задача действительно выполняется и сколько времени проводит в ожидании.

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

WIP (Work in progress, англ. работа в процессе выполнения) показывает количество незавершенной работы.

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

Cumulative Flow Diagram (англ. кумулятивная диаграмма потока), или CFD, показывает, как количество задач распределяется между этапами во времени. С помощью такого графика можно увидеть накопление работы. Если одна из областей постоянно расширяется, это сигнал о росте очереди на данном этапе.

Отдельная метрика редко дает полную картину.

Например:

• WIP растет
• Throughput остается примерно прежним
• Lead Time увеличивается

Комбинация этих показателей показывает, что работа накапливается быстрее, чем система ее завершает.

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

Kanban University (Университет Канбан, англ.) также рекомендует использовать данные о Lead Time, пропускной способности и визуализации потока для постоянного улучшения системы. 

Рассмотрим типичный ИТ-процесс:

1. Бизнес формирует запрос на новую функцию CRM.
2. Карточка появляется в очереди «Новые запросы». Аналитик берет задачу в работу, уточняет требования и переводит ее на следующий этап.
3. После анализа задача поступает группе разработки. Когда разработка завершена, карточка попадает в Code Review.
4. Затем задача переходит в тестирование. Если тестировщик обнаруживает ошибку, карточка возвращается на предыдущий этап или попадает в отдельный поток исправлений.
5. После успешного тестирования задача проходит приемку и становится завершенной.

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

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

Например:

Разработка → 8 задач → Тестирование → 2 задачи

Через несколько дней:

Разработка → 5 задач → Тестирование → 7 задач

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

Эти понятия часто смешивают, хотя они относятся к разным уровням.

Agile — набор ценностей и принципов гибкой разработки.

Scrum — конкретный фреймворк организации работы.

Kanban — метод управления потоком работы.

Поэтому Kanban и Scrum не являются прямыми противоположностями.

Kanban часто хорошо подходит для поддержки, эксплуатации, продуктовых команд с постоянно меняющимся спросом и ИТ-сервисов.

Scrum удобен там, где команде нужна регулярная ритмика разработки и планирования.

Возможен и гибридный вариант. Например, команда работает по Scrum, но использует Kanban-практики для визуализации и ограничения WIP.

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

Для ИТ-интегратора Kanban интересен прежде всего тем, что его можно применять не только внутри разработки.

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

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

Руководитель проекта получает картину по всему потоку.

В службу поддержки постоянно поступают новые обращения. Kanban позволяет разделить инциденты, стандартные запросы и крупные изменения. Для каждого типа можно определить свои правила обслуживания. Особенно полезны WIP-лимиты. Они предотвращают ситуацию, когда специалисты одновременно открывают слишком много обращений.

Для разработки ERP, CRM, BPM и других информационных систем Kanban позволяет видеть движение функциональных требований от анализа до релиза. Это помогает выявлять очереди между аналитиками, разработчиками и тестировщиками.

Интеграции CRM с ERP, WMS, 1С, телефонией или внешними сервисами часто имеют зависимости. Карточки Kanban позволяют сделать такие зависимости заметными и выделить задачи, которые находятся в ожидании внешней системы или решения заказчика.

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

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

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

Зафиксируйте, как задача проходит путь от поступления до результата. Не нужно сразу создавать идеальную схему. Kanban предполагает принцип «начните с того, что есть».

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

Перенесите реальные этапы процесса на доску.

Например:

Очередь → Анализ → Разработка → Тестирование → Приемка → Готово

Если в реальном процессе есть ожидание согласования, его стоит показать отдельно. Иначе значительная часть Lead Time останется невидимой.

Определите:

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

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

Если лимит постоянно превышается, это повод исследовать причину.

Минимальный набор для начала:

WIP + Lead Time + Throughput

Через некоторое время можно добавить Cycle Time, CFD и другие показатели.

Небольшой команде подойдет простая цифровая доска.

В корпоративной ИТ-среде полезнее связать Kanban с системой управления задачами и другими информационными системами. Это позволяет автоматически фиксировать изменение статусов, время нахождения задачи на этапах, исполнителей, приоритеты и зависимости.

Команда должна смотреть не только на завершенные задачи, но и обсуждать:

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

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

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

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

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

Карточка может формально находиться «в работе», хотя специалист фактически ничего с ней не делает. Ожидание заказчика, согласования или доступа нужно видеть отдельно.

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

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

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

Kanban делает такие ограничения видимыми.

Основные элементы подхода:

1. Визуализировать рабочий процесс.
2. Разделить работу на понятные единицы.
3. Ограничить количество незавершенных задач.
4. Управлять потоком, а не индивидуальной занятостью.
5. Измерять время и пропускную способность.
6. Находить узкие места по данным.
7. Постепенно улучшать процесс.

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

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