Другими словами, когда команда испытывает трудности с традиционным проектным управлением, в ответ она обычно добавляет в график работ «пустые» задачи – независимо от того, что является причиной проблемы.
Канбан-команды не создают буферы и «пустые» задачи в графике, потому что это скрывает изменчивость от тех, кто старается создавать правильные решения. Ценности бережливого мышления в том, что они позволяют видеть картину целиком и препятствуют сокрытию информации. Кроме того, бережливое мышление говорит нам, что, когда есть потери, вызванные неравномерностью, мы должны найти причину проблемы и устранить ее. Вместо того чтобы скрывать потери за «пустыми» элементами, канбан-команды показывают их, визуализируя рабочий процесс, вводя WIP-лимиты и другие стратегии, чтобы их исправить. Они делают изменчивость и ее основные причины явными.
Тогда вы будете иметь проблемы с внедрением Канбана. Когда вы читаете о том, как действует Канбан, кажется, что создание очередей и ограничение потока поможет существенно улучшить работу команды. Но все начинается с введения WIP-лимитов, которые нужны, чтобы ваше руководство согласилось не добавлять дополнительную работу, когда команда достигает WIP-лимита.
Это может стать ахиллесовой пятой при попытке совершенствования, особенно когда руководитель убежден, что мышление приравнивается к действию. Допустим, вы потратили несколько недель или даже месяцев, помогая команде разобраться с Канбаном, работая вместе над визуализацией рабочего процесса, создавая канбан-доску и проводя тщательные измерения для определения WIP-лимита. Теперь вы вместе с другими менеджерами с гордостью приносите свое предложение. Ваш руководитель понимает, что это заслуживает внимания. Он говорит: «Мне нравится канбан-доска, я думаю, что эти измерения замечательны, и полностью вас поддерживаю. Но мне нужно сделать всего одно небольшое изменение. Стереть этот номер в верхней части столбца на доске».
Ему кажется, что это абсолютно несущественно – стереть один маленький номер. Но WIP-лимит – это ноу-хау Канбана. Без него команда не имеет возможности ограничить поток и Канбан не работает.
На интуитивном уровне не всегда понятно, что сокращение работы всего на один шаг позволяет ускорить весь проект. И даже если вы визуализируете рабочий процесс, проводите измерения и выявляете потери, вызванные неравномерной работой, перегрузками и необоснованной или невозможной работой, это может оказаться недостаточно убедительным для руководителя. Когда это не так, он будет ориентироваться на WIP-лимит и видеть в нем компромисс. Может быть, он чувствует, что, удалив его, команда сможет оптимизировать свою работу и предотвратить неполную занятость. Или он считает, что WIP-лимит дает команде временной запас, и боится, что она будет злоупотреблять им, замедляя темпы работы и устраивая себе отпуск. Либо эта идея просто кажется ему неудачной. А возможно, он чересчур рационален и совершенно лишен магического мышления, поэтому считает так: поставка по готовности приведет к тому, что функция будет переходить из одного релиза в другой и пользователи, увидев это, одуреют и начнут настаивать на увольнении разработчиков и выгонять людей. Но независимо от того, что он думает, удаление WIP-лимита выбивает опору из-под всех действий в стиле Канбана.