Сам термин «канбан» происходит от двух японских слов: «кан» переводится как видимый, визуальный, а «бан» – карточка или доска. Канбан появился на свет на заводе Toyota, когда менеджеры в очередной раз ломали голову над тем, как улучшить процесс создания автомобилей. К слову, в то время производство было довольно плохо налажено и приносило немалые убытки. По стандартной схеме сборки автомобиля, в первую очередь изготавливалось большое количество деталей.
Проблема была в том, что разные детали могли производиться на разных заводах и потом залеживаться месяцами, ожидая своего времени. Из-за того, что в этом процессе было задействовано множество отделов, очень сложно было вовремя отловить ошибку, если таковая допускалась. А ошибка на предприятии такового масштаба постоянно стоит недешево.
Именно поэтому долгими ночами менеджеры искали новый способ ведения разработки. Вдруг их осенило: единый поток! То есть сделать все процессы непрерывно связанными и поставит все производство на один поток. В потоке нет застоя недоделанных задач, нет пауз, только движение вперед. Как в школьной эстафете: задача передается из рук в руки (из одного отдела в другой) как мячик. Если же кто-то допустил ошибку, то это обнаруживается сразу и не приводит к большим убыткам. Также этот способ повышает качество продукта, снижает его стоимость (ведь не надо больше тратиться на лишние складские помещения, например), уменьшает время изготовления товара.
Как использовать канбан на деле
Для наглядной работы с этим методом используют канбан-доску с прикрепленными к ней бумажками (задачами). Такая доска помогает работникам быстро и легко оценить количество работы и этап, на котором она находится. Обычно доску делят на следующие основные колонки:
- задачи, которые необходимо выполнить;
- задачи, которые в данный момент находятся в разработке;
- задачи, которые выполнены, но еще не переданы тестировщикам;
- задачки, готовые к передаче в отдел тестировки;
- задачи, проходящие проверку project-менеджером;
- выполненные задачи.
Сверху или снизу каждого столбца указывается максимальное число задач. То есть одновременно в этом столбце может находиться не больше определенного количества задач. Эти цифры подбираются экспериментально, но они зависят от числа разработчиков в команде и помогают оптимизировать работу.
Если число задач будет сильно превышать число работников, то каждый будет засыпан работой, а некоторые задачи будут висеть на доске очень долго (а ведь именно этого и не должен допустить канбан!). Если же задач будет слишком мало – у работников появится слишком много свободного времени (а на производстве это ни к чему хорошему не приводит). Значит надо подобрать оптимальное количество задач под количество сотрудников, чтобы было время обсудить задачи, но и заскученные работники не успевали. Таким образом, можно сделать вывод, что лимиты (это циферки под или над столбиками) – это очень важная деталь, без которой метод «канбан» теряет свою сущность.
Чем канбан хорош
- Гибкое планирование – менеджер сам выставляет приоритетность задач, а команда концентрируется на текущей работе
- Меньшая длительность цикла – сокращение времени выполнения каждой отдельной задачи. Как следствие – увеличивается скорость выполнения цикла
- Благодаря прозрачности процессов, работники проявляют большую самостоятельность и вовлеченность.
- Меньше ошибок: наличие лимитов задач позволяет внимательнее относиться к процессам
- Наглядность – канбан-доска дает возможность каждому участнику команды смотреть за действием работы.
Есть и недостатки
- Канбан нельзя использовать для долгосрочного планирования
- Плохо работает в командах с численностью более 5 человек
Канбанить или воздержаться
Канбан используют многие ИТ-компании уже более 10 лет. Так что это достаточно старый метод, проверенный временем. Компании Microsoft канбан в свое время помогли значительно улучшить производственные процессы и увеличить производительность «проблемных» отделов.
Канбан – это инструмент, который помогает сгладить неровности и явно показывает, где стоит улучшить текущие процессы. Чтобы извлечь как можно больше пользы, его нужно применять только там, где он сможет оптимально работать: в маленьких командах при недолгосрочных задачах.