Вокруг любого управленческого подхода со временем выстраивается огромное количество заблуждений и мифов. Это обусловленно особенностью людей по-разному понимать одни и те же вещи и желанием интерпретировать факты в своих интересах. Канбан, как метод определения, управления и совершенствования сервисов, при разработке интеллектуальных продуктов, сравнительно молод, но уже успел обзавестись своей мифологией. Разработчики Kanban Tool (инструмента для визуализации потока) в своем блоге постарались разобрать наиболее распространенные мифы, возникшие из-за неправильного понимания принципов Канбан.
«Канбан на самом деле не метод организации рабочего процесса, а инструмент улучшения рабочего процесса.»
Часто говорят, что Канбан – это инструмент для создания знаний, а не метод управления рабочим процессом.
Да, Канбан позволяет по-новому взглянуть на ваш существующий процесс и делает все этапы прозрачными для всех участников. Можно сказать, что Кабан сам по себе не является методологией управления рабочим процессом, поскольку он не определяет конкретные процедуры и этапы выполнения работ, а представляет собой всего лишь визуальное дополнение к тому, что вы уже делаете. Но добавление Канбан-практик к существующему рабочему процессу оказывает на него столь сильное влияние, что у нас появляется основание считать Канбан вполне самостоятельным методом. Существует огромное количество команд, не имеющих формализованного рабочего процесса, но при этом эффективно использующих Канбан для организации своей работы. Ошибочно ли говорить, что они используют Канбан метод? Это миф? Можно утверждать, что рассуждения о том, является ли Канбан методом или нет, мало влияют на то, как работают люди.
«Канбан фокусирует внимание на тех этапах, которые нам нравятся, и разрешает нам игнорировать неприятные этапы».
Это неправильно, если не сказать больше.
Канбан обязывает обозначить все известные этапы процесса, а затем постоянно актуализировать их.
Существуют ли другие стадии, которые не были включены изначально? Считаете ли вы, что есть этапы, которые являются ненужными, вызывают потери и должны быть удалены?
Канбан предназначен для того, чтобы облегчить внесение этих изменений по мере их возникновения. Всегда. Без возможности достичь точки, в которой можно было бы сказать: «Вот оно – таков наш процесс с настоящего момента и до бесконечности!».
В этом смысле Канбан действительно является инструментом создания знаний. Знаний о вашем процессе, его этапах, сильных сторонах, недостатках и – это ключевое слово здесь – возможностях улучшения.
«Канбан – это работа без передышки»
Некоторые управленческие подходы позволяют не слишком торопиться, в основном из-за асинхронного характера процессов. Пока некоторые члены команды ждут завершения предыдущих этапов, у них появляется время на обучение и творчество, либо просто возможность перевести дух. При этом, создается впечатление, что если мы визуализируем наш рабочий процесс, то сможем контролировать загрузку каждого работника, и у них не будет времени на передышку. Так не должно быть. Команда должна осознанно тратить время на передышки и обучение. Отсутствие задач в работе – это не конец света. Проблемы больше во внутренней политике компаний, чем в самом Канбан-методе.
«Канбан пригоден только для управления линейными процессами»
Тот факт, что Канбан-доска представляет этапы рабочего процесса как линейные, не означает, что она обязательно накладывает ограничения на то, как выполняется работа. Доска предназначена для визуализации текущих этапов работы над каждым элементом, а не для ограничения способа исполнения этой работы. Доска – это инструмент визуализации, а не оракул.
«Ограничения на WIP убивают гибкость и способность быстро реагировать»
Бытует ошибочное мнение, что достигнув лимита на WIP, вы не сможете отвечать на срочные запросы.
Это не обязательно. Смысл ограничения WIP в том, чтобы контролировать количество задач, выполняемых одновременно. Это не значит, что вы не можете переключиться с двух обычных задач на две срочные при необходимости.
«В Канбан-методе нет ограничений по времени»
Отсутствие строгих временных рамок обычно называют одним из различий между скрамом и Канбаном.
Даже если вы не используете строгого контроля времени в вашем проекте, вы можете легко выяснить, сколько времени заняла работа, изучив Кумулятивную Диаграмму Потока и данные по Времени производства (Cycle Time) и Времени поставки (Lead Time).
Канбан позволяет прогнозировать затраты времени на основании исторических данных, не оказывая при этом давления на команду.
Учитывайте вышеизложенное, рассуждая о том, является Канбан методом или нет, какого бы мнения вы при этом не придерживались.
Комментарий от автора перевода:
Коллеги из команды Kanban Tool проделали хорошую работу по разъяснению многих важных аспектов правильного использования Канбан-метода, при этом не все их утверждения выглядят бесспорными.
Для меня, например, кажется странным, что рассказывая о практиках Канбан для работы со срочными задачами, коллеги потеряли истории про выделение отдельного потока для срочных задач (expedite) и классы обслуживания, обеспечивающие необходимую гибкость при работе над срочными задачами.
Точно так, в размышлениях о временных ограничениях и управлении содержанием, оказалась потеряна история о планировании поставки и релизных циклах.
Но с главным посылом авторов я, безусловно, согласен. Большинство ограничений и проблем в использовании Канбан-метода, не имеют отношения к принципам и практикам Канбан. Эти ограничения и проблемы создают люди и порождаемая ими культура производства.
GT