и должно быть. Канбан-доска дает нам нечто совершенно особенное – практичную вытягивающую систему для нашего нематериального продукта, интеллектуальной работы.
Если не устанавливать WIP-лимиты, то сигналы для перемещения карточек теряются. Перемещающийся влево поток сигналов останавливается, как только достигнет столбца, в котором отсутствует ограничение (в данном случае это столбец «Предложено» (Proposed) на левом краю доски).
Эти неограниченные (или бесконечные) очереди приобретают огромную важность, когда измеряется время, необходимое для прохождения работы через систему. Мы называем время на перемещение рабочего элемента от одного столбца без ограничения, до другого столбца без ограничения, через столбцы с WIP-лимитами временем производства канбан-системы. Оно может очень сильно отличаться от времени производства заказчика – времени выполнения заказа с точки зрения клиента[5].
Баланс Загрузки и Возможностей
Рассмотрим ситуацию на доске (рис. 2.2) с точки зрения людей, наиболее тесно связанных с этими самыми столбцами «Тест». Они могут быть тестировщиками или теми самыми разработчиками или аналитиками, которые занимались этими участками работы на более ранних стадиях; в интересах самоорганизации на доске это не отражается. Однако доска позволяет убедиться в том, что объем работы в этой зоне не выйдет (или не должен выйти) за пределы возможностей.
Это значит, что мы предприняли серьезные шаги к тому, чтобы избежать перегрузки людей, не доводить ситуацию до такого состояния, когда она становится, в лучшем случае, контрпродуктивной, а в худшем – негуманной. Стоит сделать завершение работы приоритетным по отношению к ее началу, и качество работы повысится – это объясняется тем, что у сотрудников появится возможность сосредоточиться на меньшем количестве задач. В результате на доске будет больше свободных ячеек. Чем меньше рабочих элементов на каждом участке производственного процесса, тем быстрее завершится работа в целом, а результаты обратной связи появятся раньше.
Тем не менее время от времени создается впечатление, будто WIP-лимиты заданы неверно. Когда они слишком высоки, то вроде не оказывают особого влияния на процесс. Но если приглядеться, то становится очевидным, что выполнение многих рабочих элементов застопоривается из-за нехватки людей. Если WIP-лимиты установлены слишком маленькими, то слишком большая доля работы может оказаться заблокированной в любой момент времени из-за того, что отдельные части системы «зависли», а люди сильно недозагружены.
Такие ситуации должны служить причиной для обсуждения и подробного изучения, а также для внесения корректив. Естественной реакцией может быть изменение лимитов, но слишком спешить не стоит. Сначала удостоверьтесь, что все, кого это касается, разобрались в причинах создавшейся ситуации, и действуйте, исходя из этого.
Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные
Используйте термины «время разработки» (lead time) и «продолжительность цикла» (cycle time) с осторожностью. Поскольку их определение может зависеть от вашей точки зрения, полезно дать более точную формулировку. Вам будет легче, если отсчет начнется в четко выраженной точке принятия решения и закончится точно в момент завершения, поставки или подтверждения (валидации). Также помните о том, что в литературе встречаются разные определения этих терминов, что создает и будет создавать сильную путаницу.
