Что в Канбан-методе понимают неправильно

Даже опытные Канбан-тренеры не застрахованы от ошибок в своей работе. Предупрежден — значит вооружен: разберем одни из распространенных заблуждений при работе с Канбан.

Об авторе

Алексей Пименов — аккредитованный тренер Kanban University, преподаватель международного консорциума ICAgile. Тренер и консультант по темам Kanban Method, Business Agility и другим современным методам менеджмента.

Статья написана на основе выступления Алексея Пименова на AgileDays 2022. Выступление можно посмотреть здесь.

Ошибка 1. Не знать отличий сервиса поставки ценности от команды

Для начала нужно разделить понятия «сервис поставки ценности» и «команда».

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

• запрос клиента;
• команды или коллектив разрозненных сотрудников в компании;
• рабочий процесс (Workflow);
• стек технологий и инструментов, используемых при разработке продукта (Inventory);
• рабочее окружение, куда входят серверы, стенды, среды разработки и др (Environment);
• конечный продукт, поставляемый клиенту.

Ошибка 2. Неверно трактовать паттерны стоимости задержки

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

Ось I обозначает стоимость задержки, а ось T — время.

Нулевую точку трактуют по-разному, в том числе как:

• момент, когда запрос придуман;
• момент, когда запрос заведен в систему в виде задачи;
• момент, когда задача взята в работу и т. д.

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

Исходя из этого трактуем графики паттернов стоимости задержки:

• Expedite (Ускоренный)— начинаем получать прибыль сразу после завершения запроса;
• Fixed Date (Фиксированная дата) — зарабатываем не сразу после поставки результата, а с какого-то определенного момента;
• Regular (Постоянный) — прибыль растет плавно после поставки результата;
• Intangible (Нематериальный) — неизвестно, когда будет получена прибыль, однако запрос всё равно необходимо удовлетворить.

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

Ошибка 3. Путать классы обслуживания и приоритет

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

Разберем разницу этих сущностей на примерах.

Если клиент банка с VIP-картой встает в очередь к сотруднику первым — он получает приоритет над остальными в этой очереди.

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

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

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

• Expedite — начинаем работу сразу же после поступления задачи в систему;
• Fixed Date — определяем, когда задачу нужно поставить, а затем когда мы начнем ее выполнять. Не обрабатываем задачу до этого момента;
• Regular — ставим задачу в стандартную очередь и беремся за нее последовательно;
• Intangible — берем задачу в работу, когда у нас есть свободное время.

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

Ошибка 4. Отображать несколько компонентов рабочего процесса на Канбан-доске одним и тем же способом

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

На изображении ниже типичная Канбан-доска. На ней отображены колонки этапов движения задач в системе и свимлайны. Множество стикеров разных цветов обозначают задачи.

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

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

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

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

Ошибка 5. Создавать универсальные доски

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

Но в случае Канбан-метода это не принесет результатов по следующим причинам.

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

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

Каждый рабочий процесс уникален и зависит от контекста.

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

Ошибка 6. Не работать по Канбан-методу, потому что нет нужного инструмента

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

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

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

Ошибка 7. Считать, что Канбан — это Just in Time

Можно услышать утверждение, что метод Канбан — это метод Just in Time.

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

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

Ошибка 8. Опираться на статистику в неограниченной системе

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

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

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

Ошибка 9. Считать, что лимит на незавершенную работу обязательно должен быть небольшим

Еще одно распространенное заблуждение при интеграции Канбан-метода состоит в том, что лимит на незавершенные задачи (WIP-лимит) должен быть небольшим.

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

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

Ошибка 10. Двигать карточки влево

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

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

• дополнительная нагрузка на команду. Представим, что задача возвращается на предыдущий этап. Тогда сотрудникам нужно будет заняться вернувшейся карточкой и приостановить текущую работу. Менеджеру придется потратить время на объяснения, зачем это нужно;
• необходимость анализа возвратов. На менеджера добавится нагрузка по подсчету количества возвращенных задач, выявлению и сортировке причин возвратов, оценке их влияния на процесс. Только так он сможет выяснить, насколько возвращающиеся назад задачи замедляют работу и почему это происходит;
• невозможность оценки всего рабочего процесса. Сотрудники фокусируются на текущих задачах в их колонках, при этом к ним возвращаются назад уже завершенные карточки. В результате у них просто не остается ресурсов оценивать весь рабочий процесс. Однако Канбан-метод стремится, чтобы все участники охватывали всю доску, а не только ее часть. Так команда сможет анализировать возникающие сложности и ключевые цели всего процесса работы целиком. Это поможет сообща улучшать конечный результат, а не только отдельные этапы в его достижении.

Выводы

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