Если вы хоть раз сталкивались с управлением проектом или командой, то знаете, что это нелегко. Нужно следить, чтобы все задачи выполнялись в срок и в определенной последовательности, а сотрудники не перегружались. Это и помогает делать популярный Канбан-метод. Расскажем, откуда она появилась, из чего состоит и кому подходит.
Что такое Kanban
Канбан — это методология, которая помогает улучшить сервис и достигать поставленных целей. Для чего нужен Канбан? Его цели — визуализировать процесс работы каждого члена команды и постоянно улучшать его, а также создать непрерывный поток выполнения задач.
Как появился Kanban
Kanban как термин появился в 1940-х годах в компании Toyota. До этого времени производители автомобилей часто придерживались метода Генри Форда: производилось большое количество деталей, которые использовались по мере необходимости. Каждый цех изготавливал детали с разной скоростью. Как итог каких-то деталей всегда не хватало, а каких-то было слишком много.
То есть такой подход приводил к большим издержкам и требовал авансового капитала. Чтобы избежать перепроизводства, главный инженер Toyota Тайити Оно (Taiichi Ōno) ввел новую систему, которая подразумевала, что детали должны изготавливаться только по запросу.
Тайити Оно
«To produce only what is needed, when it is needed and in the amount needed» —
производите только то, что необходимо в определенный момент и в нужном количестве.
Как же цеха обменивались заказами? Для этого они использовали обычную доску, которая висела на стене, и систему карточек. Бумажные карточки висели на доске. На них было написано, сколько и каких деталей потребуется в ближайшее время. Только после того, как появлялась карточка с требованием произвести детали, запускался производственный процесс.
Так выглядели карточки на изготовление деталей
Само слово «Kanban» состоит из двух иероглифов:
- 看 — «Кан» означает «знак»,
- 板 — «Бан» значит «доска».
Kanban-доска в Toyota
В 2000-х годах на Канбан обратил внимание Дэвид Дж. Андерсон — разработчик и менеджер компаний Motorola и Microsoft. Идея выполнять работу по запросу показалась ему применимой не только на производстве автомобилей, но и при разработке программного обеспечения.
Так началась история Kanban как метода управления рабочим процессом. Андерсон поделился результатами внедрения Канбана на Agile-конференции, что способствовало его популяризации. Уже в 2007 году Андерсон выпустил книгу «Канбан: альтернативный путь в Agile». В ней он рассказал об основных принципах и элементах Kanban method, которые мы знаем сейчас.
Принципы Канбан
Основные принципы Канбан-метода.
1. Начните с того, что есть сейчас.
Метод Kanban не требует кардинальных изменений в процессах. Внедрение начинается с анализа текущей ситуации и работы с уже существующими процессами.
2. Договоритесь об эволюционном развитии.
Изменения в рабочих процессах должны происходить постепенно, на основе данных и обратной связи. Канбан помогает совершенствовать процессы шаг за шагом, не создавая стресс для команды.
3. Поощряйте развитие лидерства на всех уровнях.
Ответственность за улучшение работы должна быть распределена между всеми участниками процесса. Важно поддерживать инициативность и стремление к изменениям на всех уровнях команды.
Сервисные принципы Канбан
1. Выясните потребности и ожидания заказчика.
Канбан направлен на эффективное удовлетворение запросов клиентов. Команда должна четко понимать, что важно для заказчика и какие ожидания он предъявляет.
2. Управляйте работой, дайте людям организоваться вокруг нее.
Фокус на управлении работой, а не людьми. Это значит, что команда сама определяет, как лучше организовать процесс выполнения задач.
3. Развивайте правила, чтобы улучшить показатели.
Достичь успеха с первого раза в любом деле почти невозможно. Также всегда есть внешние факторы, которые вносят свои корректировки в бизнес. Kanban-метод призывает быть гибкими. Нужно собирать обратную связь от коллег и пользователей продукта. Эти данные помогут найти путь для развития.
Элементы Kanban-системы
Kanban-доски
Умственная работа не видна так же очевидно, как физическая: нельзя просто взглянуть и понять, на каком этапе находится задача. Поэтому первое, с чего начинается внедрение Канбан-метода, — это визуализация. Именно она помогает сделать рабочий процесс прозрачным. Раньше сотрудники Toyota использовали физические доски для заказов деталей, а сейчас есть множество сервисов с виртуальными досками.
На Канбан-доске есть 3 важных элемента: колонки, строки (их также называют дорожками) и карточки.
Карточки — основной рабочий элемент, а колонки — этапы, которые должна пройти задача, пока ее не выполнят.
Количество колонок может быть любое — зависит от жизненного цикла карточки. Главное — все этапы должны быть учтены. Редко, когда хватает 3 колонок «Очередь», «В работе» и «Готово». Чем точнее колонки будут отражать жизненный процесс, тем проще в будущем выявить, какие проблемы возникают и на каком этапе.
Исполнители двигают карточки по колонкам слева направо. То есть, как только выполнен очередной этап работы, карточку перемещают в следующую колонку. Так делают до тех пор, пока задача не окажется в последней колонке, где хранятся завершенные дела.
Kанбан: пример доски
Командные встречи, или Kanban-каденции
Для Kanban очень важно, чтобы все члены команды были вовлечены в рабочий процесс. Чтобы этого достичь, необходимо постоянно общаться как внутри команды, так и с руководителями и заказчиками. Поэтому Kanban предусматривает встречи, или каденции (Kanban Cadences). Это цикл мероприятий, который обеспечивает обсуждение работы на разных этапах.
Каждая встреча связана с предыдущей. Циклы собраний сменяют друг друга и формируют единый поток коммуникации. Важно проводить Канбан-каденции регулярно.
7 видов Канбан-каденций
1. Ежедневная встреча (Daily Meeting, Standup Meeting)
Проходит ежедневно и длится не более 15 минут. Цель встречи — подготовить план работы на день.
На собрании каждый член команды должен ответить на 3 вопроса:
- Какими задачами планирует заняться?
- Сталкивается ли с проблемами и блокировками при выполнении задач?
- Нужна ли помощь от коллег?
Особое внимание уделите проблемным задачам и блокировкам. Важно понять, повлияют ли они на сроки подготовки проекта.
Если вы работаете офлайн, можно проводить собрание стоя. Долго стоять трудно, поэтому каждый, рассказывая о своих задачах, будет стараться доносить информацию быстро и кратко.
2. Встреча по пополнению очереди (Replenishment Meeting)
Проходит еженедельно или 1 раз в 2 недели. Частота зависит от команды и ее задач. Длительность — от 30 минут до 1 часа. Поток входящих задач — важный элемент Kanban. Чтобы в бэклоге карточки лежали по приоритетам и было понятно, что необходимо сделать в ближайшее время, нужно собираться на небольшую встречу по пополнению очереди задач.
В рамках этой встречи:
- решается, какие задачи важны на данный момент и есть ли у команды ресурсы на их выполнение;
- распределяются исполнители, чтобы нагрузка на каждого сотрудника была сбалансирована.
3. Собрание по планированию поставки (Delivery Planning Meeting)
Частота встреч зависит от потока задач. Встреча длится 1–2 часа. Заказчику важно знать сроки выполнения работы. Например, вы разрабатываете внутренний корпоративный портал для компании. Клиент должен знать, когда он запустится, чтобы подготовить информационную кампанию для сотрудников и собрать команду, которая будет готовить новости для него.
Планировать сроки реализации проекта нужно с опорой на данные прошедших проектов. Соберите информацию о продуктивности команды за предыдущие периоды и посчитайте, за сколько вы выполните аналогичные задачи.
4. Обзор поставки (Service Delivery Review)
Эта встреча проводится раз в две недели и длится 30 минут. Ее цель — проанализировать, насколько эффективно выполняются задачи, выявить точки улучшения и минимизировать риски задержек.
Важный фокус — соответствие сроков выполнения задач ожиданиям заказчика. На встрече оцениваются ключевые показатели работы команды, выявляются возможные узкие места и принимаются решения, которые помогут оптимизировать процесс.
В обсуждении участвуют только представители команды, а не вся команда целиком. При анализе важно учитывать не только скорость выполнения задач, но и удовлетворенность заказчиков качеством работы.
5. Анализ рисков (Risk Review)
Эта встреча проводится ежемесячно и длится 1–2 часа. Если вы хотите сделать проект в срок, важно, чтобы команда не сталкивалась с проблемами или хотя бы помнила, что они могут быть, и знала, как действовать. Чтобы у команды был план действий на разные ситуации, нужно изучать предыдущий опыт и совершенствовать процессы. Для этого раз в месяц встречайтесь всей командой и изучайте блокировки и возникшие на пути проблемы.
6. Обзор операций (Operation Review)
Проводится ежемесячно и длится примерно 2 часа.
На встрече присутствуют только менеджеры разных команд. Цель — проанализировать работу всех отделов, их коммуникацию с заказчиками и друг с другом. Для выявленных проблем нужно придумать решения.
В отличие от остальных встреч, обзор операций призван повысить эффективность всей организации в целом, а не отдельных команд.
7. Обзор стратегии (Strategy Review)
Проводится раз в квартал и длится долго — от 4 часов. В нем участвуют топ-менеджеры и руководители команд. Цели встречи:
- проследить, движется ли компания к целям;
- соответствуют ли цели ситуации на рынке;
- эффективны ли созданные бизнес-процессы.
Если проблемы есть, необходимо скорректировать курс.
Встреча требует масштабной подготовки. Нужно изучить рынок и изменения, которые на нем происходят, проанализировать достижения компании и отдельных команд, сравнить компанию с конкурентами.
Ограничение незавершенной работы
Для Канбана важно, чтобы задачи завершались как можно быстрее. Если сотрудник работает над несколькими задачами одновременно, он отвлекается. Чтобы сотрудник был сосредоточен на ограниченном количестве работы, вводятся WIP-лимиты. Work in progress, или лимиты незавершенной работы, — это правила, которые ограничивают количество задач на каждом этапе рабочего процесса. За счет этого сотрудники не хватаются за все задачи подряд, а фокусируются на одной или двух.
Например, редактор берется за статью и пишет половину текста. Как только ему надоедает тема, он бежит писать новую. В итоге ни одна из статей не дописана. Результата нет. Именно в таких случаях помогают WIP-лимиты. Сотрудник вынужден дописать предыдущую статью, чтобы взяться за новую. «Прыгать» между статьями не получится.
WIP-лимиты разные для всех. Понять, какое количество задач в работе приемлемо для каждого сотрудника, можно только путем исследования. Проанализируйте предыдущие задачи и установите примерные лимиты. Поработав несколько итераций, обсудите с командой выполненные задачи, было ли удобно так работать. Если нет — скорректируйте ограничения.
Классы обслуживания
Классы обслуживания (Classes of Service) — правила, по которым разделяются все задачи команды. Это помогает приоритизировать их и не упустить особенно важные.
В Kanban обычно выделяют 4 класса задач:
- Срочные. Их необходимо сделать быстро. Например, перестал работать сервер и нужно бросить все силы на его воскрешение.
- С фиксированной датой. Задачи с конкретным дедлайном. Например, пост о запуске акции должен выйти 1 марта.
- Стандартные. Большинство задач в рабочем процессе должны быть стандартными. В этом классе находятся задачи с умеренными затратами на задержку и есть много времени на выполнение.
- Нематериальные. Задачи этого класса можно назвать бытовыми делами. Их нужно выполнить, но спешить с ними не обязательно.
Классы обслуживания могут быть другими. Всё зависит от специфики вашей команды.
Важные метрики для Kanban
Чтобы знать, есть ли проблемы в рабочем процессе, в Kanban необходимо отслеживать метрики эффективности работы. Например, в команде разработчиков в колонке «Тестирование» копятся карточки. Дело в том, что в команде не хватает тестировщиков. Исправить это можно, найдя еще одного тестировщика.
Во многих таск-трекерах инструменты для отслеживания эффективности команды встроены в программу. То есть делать вручную ничего не нужно. Вы просто оцениваете собранные программой данные.
Итак, какие метрики нужно отслеживать в Kanban:
Скорость поставки задач
Сколько времени проходит с момента, как задача появляется на доске команды до ее полного выполнения. Этот показатель помогает ответить на вопрос, когда заказчик получит готовую работу.
Время цикла
Время от взятия задачи в работу до поставки. Показывает, сколько времени команда активно работает над задачей. То есть отсчет идет не с попадания карточки на доску, а с момента, как команда взяла задачу в работу. Помогает увидеть проблемы. Например, одна задача неожиданно выполнялась дольше, чем обычно. Стоит изучить ее. Может быть, ТЗ было сделано неправильно, не хватало информации.
Пропускная способность
Сколько задач выполнила команды за определенный промежуток времени. Например, писатели готовят в неделю пять статей. Если заказчик захочет узнать, когда вы сможете взять его задачу в работу, посмотрите на пропускную способность и рассчитайте примерную дату.
Стоимость задержки
Это последствия, к которым может привести задержка выполнения задачи. Например, если дизайнер не сделает макет, разработчики не смогут приступить к созданию интернет-магазина и бизнес не запустит онлайн-продажи. Каждый день задержки — упущенная прибыль, которая может достигать нескольких сотен тысяч.
Отличие Scrum от Kanban
Scrum и Kanban нужны для разных целей.
- Kanban-методология стремится улучшить рабочий процесс: увеличить скорость работы над задачами, уменьшить количество блокировок и визуализировать всю работу команды.
- Scrum помогает сосредотачиваться на постоянном выпуске нового элемента продукта (инкремента). В конце спринта команда ставит себе цель — создать что-то новое для потребителя. Такой подход способствует активному росту бизнеса.
Для наглядности отличие Kанбан от Скрам собрали в таблицу.
| Параметр | Kanban | Scrum |
| Суть подхода | Визуализация рабочего процесса и достижение максимальной эффективности | Деление работы на итерации (спринты). Ориентируется на постоянный выпуск элементов продукта и быстрый сбор обратной связи от пользователей |
| График | Непрерывный процесс | Вся работа поделена на спринты — итерации от 1 недели до месяца |
| Роли | В команде нет обязательных ролей | Владелец продукта (Product Owner), Scrum-мастер и команда разработчиков |
| Элементы | Kanban-доска, WIP-лимиты, классы обслуживания | Бэклог продукта, бэклог спринта, инкремент продукта |
| Скорость изменений | Можно вносить изменения в любой момент | Изменения проходят только между спринтами на основе ретроспективы, которая проходит в конце каждой итерации |
У Scrum и Kanban также бывают пересечения. Команды, которые работают по Scrum, используют Kanban-доски для визуализации задач и отслеживания прогресса. В свою очередь, Kanban-команды могут иметь Product Owner, который помогает им развивать продукт. Для такого комбинированного подхода придумали название — Scrumban. Но об этом поговорим подробнее в будущей статье.
Преимущества и недостатки Kanban
Kanban помогает сделать рабочие процессы и ошибки в них наглядными, а также балансирует нагрузку сотрудников.
Но, как и у многих методологий, у него есть недостатки. Собрали для вас все минусы и плюсы в таблице.
| ✅ Преимущества | ❌ Недостатки |
| Прозрачность рабочего процесса
Карточки на доске в режиме реального времени показывают, чем занимается каждый член команды. Вы легко можете оценить вклад каждого сотрудника в проект, найти проблемные места и не давать работникам перегружаться |
Методология Канбан подходит не всем
Он дает большую гибкость команде. Это может быть плюсом. Но, если в организации есть квартальные отчеты, жесткие KPI и OKR, то гибкость Канбана может усложнить задачу |
| Подробная аналитика
Вы можете проследить каждый этап работы. Если что-то пойдет не так, вы сразу это заметите и сможете скорректировать процесс |
Не дает планировать на годы вперед
Суть Kanban framework — быстро реагировать на изменение приоритетов задач. Если в вашей компании привыкли планировать на 1–2 года вперед, Канбан будет для вас неудобным. Вы не сможете в полной мере использовать его преимущества |
| Внедрение Канбан происходит легко
В Scrum нужно нанять Владельца продукта и Scrum-мастера, рассказать про четкие правила спринтов и т. д. Система Канбан — это эволюция рабочего процесса. Создайте рабочую доску, попробуйте проводить некоторые встречи, например Daily Meeting, затем выявите удобные WIP-лимиты. Вот так, шаг за шагом, вы придете к идеальному для вас рабочему процессу |
|
| Вся команда вовлечена в улучшение процессов
На Канбан-встречах команда активно обсуждает все неудобства или, наоборот, хорошие практики, решает проблемы. Это способствует вовлеченности в улучшение работы. Каждый член группы видит, как к его идеям и неудобствам прислушиваются |
Вместо итога
Методика Канбан подходит не всем, поэтому использовать его или нет — решать вам. При выборе любой методологии задавайте себе вопрос, что необходимо вашей команде. Если вам нужна активная разработка, то лучше обратить внимание на Scrum. Его цель — настроить постоянный релиз новых функций продукта. Если вам важно поработать над потоком работы: сделать его предсказуемым, сбалансированным по нагрузке и понятным, — выбирайте Kanban.
