Канбан Метод. Улучшение системы управления

Эти неограниченные (или бесконечные) очереди приобретают огромную важность, когда измеряется время, необходимое для прохождения работы через систему. Мы называем время на перемещение рабочего элемента от одного столбца без ограничения, до другого столбца без ограничения, через столбцы с WIP-лимитами временем производства канбан-системы. Оно может очень сильно отличаться от времени производства заказчика – времени выполнения заказа с точки зрения клиента[5].

Баланс Загрузки и Возможностей

Рассмотрим ситуацию на доске (рис. 2.2) с точки зрения людей, наиболее тесно связанных с этими самыми столбцами «Тест». Они могут быть тестировщиками или теми самыми разработчиками или аналитиками, которые занимались этими участками работы на более ранних стадиях; в интересах самоорганизации на доске это не отражается. Однако доска позволяет убедиться в том, что объем работы в этой зоне не выйдет (или не должен выйти) за пределы возможностей.

Это значит, что мы предприняли серьезные шаги к тому, чтобы избежать перегрузки людей, не доводить ситуацию до такого состояния, когда она становится, в лучшем случае, контрпродуктивной, а в худшем – негуманной. Стоит сделать завершение работы приоритетным по отношению к ее началу, и качество работы повысится – это объясняется тем, что у сотрудников появится возможность сосредоточиться на меньшем количестве задач. В результате на доске будет больше свободных ячеек. Чем меньше рабочих элементов на каждом участке производственного процесса, тем быстрее завершится работа в целом, а результаты обратной связи появятся раньше.

Тем не менее время от времени создается впечатление, будто WIP-лимиты заданы неверно. Когда они слишком высоки, то вроде не оказывают особого влияния на процесс. Но если приглядеться, то становится очевидным, что выполнение многих рабочих элементов застопоривается из-за нехватки людей. Если WIP-лимиты установлены слишком маленькими, то слишком большая доля работы может оказаться заблокированной в любой момент времени из-за того, что отдельные части системы «зависли», а люди сильно недозагружены.

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

Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные факторы усовершенствований в масштабах всей системы. Когда вы уменьшаете объем WIP, то делаете намного более очевидными другие проблемы (а они могут мешать еще сильнее). Решите их, и тогда объем WIP можно будет уменьшить дополнительно – он даже может уменьшиться сам собой[6]. Это еще один механизм самоусиления, причем очень мощный. Его очень успешно в течение многих десятилетий использует компания Toyota[7].

Противоположностью этого механизма я считаю порочный круг, который возникает, когда главной заботой становится постоянная занятость людей. В этом случае первая реакция на застопорившуюся работу заключается не в решении проблемы, а в начале выполнения еще одной рабочей задачи, что приводит к увеличению объема WIP в системе. Чем больше незавершенной работы, тем больше время ожидания у тех, кто будет ее завершать, а значит, проблема только усугубляется. Задержки и одновременное выполнение множества задач оказывают негативное воздействие на качество и являются причиной – да вы и сами, наверное, догадались – ошибок и переделок, большего объема застопорившейся работы и WIP. Слишком много работы в сочетании с плохим качеством – вам нравится такая комбинация?

Другие способы ограничить WIP

Я бы не хотел создавать впечатление, что WIP-лимиты на уровне столбцов – это единственный способ ограничения объема незавершенной работы. Он достаточно действенный, но иногда работает лучше в сочетании с другими механизмами. Их можно условно разделить на две основные категории:

1. Уменьшение размера пакетных транзакций – сокращение размера (в плане бюджета и продолжительности) проектов, интервалов между релизами, а также размеров спринтов, размера пакета разрабатываемого функционала и т. д.

2. Уменьшение количества событий, развивающихся параллельно, – сокращение количества бизнес-инициатив (к которым привязаны проекты), сокращение количества сопутствующих проектов в расчете на группу или отдел, сокращение количества рабочих элементов в расчете на группу или на человека и т. д.