Баланс – это ценность, тесно связанная со второй основной практикой канбана:
ОП2: ограничивайте объем незавершенной работы (WIP – work-in-progress).
В первой части этой главы я продемонстрирую, как ограничение WIP на канбан-доске работает в качестве механизма координации для реализации вытягивающей системы. Позже мы рассмотрим другие случаи проявления баланса в канбане.
Рассмотрим столбец «Тест» на доске (рис. 2.1).
В правом верхнем углу столбца «Тест» стоит цифра 4. Она обозначает WIP-лимит, т. е. максимально допустимое в этой зоне количество рабочих элементов. В приведенном примере общее количество рабочих элементов в столбце «Тест» (включая два его подстолбца «В работе» (In Progress) и «Выполнено» (Done)) не должно превышать четырех. Наше приложение выделяет лимит, потому что эта часть доски в данный момент максимально загружена.
Теперь посмотрим, что происходит на рис. 2.2, когда карточки перемещаются вправо, причем как внутри, так и (что важно) за пределы выделенной зоны.
Зона «Тест» на доске теперь не заполнена целиком. Пространство в подстолбце «В работе», оставшееся пустым, играет очень важную роль – оно сигнализирует, что можно вытянуть туда карточку из соседнего (левого) столбца.
Вытягивающая система работает следующим образом: по мере того, как работа движется к завершению (вправо по доске), эти сигналы (освободившиеся ячейки) перемещаются в начало (влево), показывая, что можно по мере готовности перетягивать на свободные места другие рабочие элементы. Когда есть участки столбцов с ограничениями (собственными или общими), а сигналы и перемещения могут сдвигаться влево очень быстро, система представляется связанной, как это и должно быть. Канбан-доска дает нам нечто совершенно особенное – практичную вытягивающую систему для нашего нематериального продукта, интеллектуальной работы.
Если не устанавливать WIP-лимиты, то сигналы для перемещения карточек теряются. Перемещающийся влево поток сигналов останавливается, как только достигнет столбца, в котором отсутствует ограничение (в данном случае это столбец «Предложено» (Proposed) на левом краю доски).
Эти неограниченные (или бесконечные) очереди приобретают огромную важность, когда измеряется время, необходимое для прохождения работы через систему. Мы называем время на перемещение рабочего элемента от одного столбца без ограничения, до другого столбца без ограничения, через столбцы с WIP-лимитами временем производства канбан-системы. Оно может очень сильно отличаться от времени производства заказчика – времени выполнения заказа с точки зрения клиента[5].
Рассмотрим ситуацию на доске (рис. 2.2) с точки зрения людей, наиболее тесно связанных с этими самыми столбцами «Тест». Они могут быть тестировщиками или теми самыми разработчиками или аналитиками, которые занимались этими участками работы на более ранних стадиях; в интересах самоорганизации на доске это не отражается. Однако доска позволяет убедиться в том, что объем работы в этой зоне не выйдет (или не должен выйти) за пределы возможностей.
Это значит, что мы предприняли серьезные шаги к тому, чтобы избежать перегрузки людей, не доводить ситуацию до такого состояния, когда она становится, в лучшем случае, контрпродуктивной, а в худшем – негуманной. Стоит сделать завершение работы приоритетным по отношению к ее началу, и качество работы повысится – это объясняется тем, что у сотрудников появится возможность сосредоточиться на меньшем количестве задач. В результате на доске будет больше свободных ячеек. Чем меньше рабочих элементов на каждом участке производственного процесса, тем быстрее завершится работа в целом, а результаты обратной связи появятся раньше.
Тем не менее время от времени создается впечатление, будто WIP-лимиты заданы неверно. Когда они слишком высоки, то вроде не оказывают особого влияния на процесс. Но если приглядеться, то становится очевидным, что выполнение многих рабочих элементов застопоривается из-за нехватки людей. Если WIP-лимиты установлены слишком маленькими, то слишком большая доля работы может оказаться заблокированной в любой момент времени из-за того, что отдельные части системы «зависли», а люди сильно недозагружены.
Такие ситуации должны служить причиной для обсуждения и подробного изучения, а также для внесения корректив. Естественной реакцией может быть изменение лимитов, но слишком спешить не стоит. Сначала удостоверьтесь, что все, кого это касается, разобрались в причинах создавшейся ситуации, и действуйте, исходя из этого.
Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные факторы усовершенствований в масштабах всей системы. Когда вы уменьшаете объем WIP, то делаете намного более очевидными другие проблемы (а они могут мешать еще сильнее). Решите их, и тогда объем WIP можно будет уменьшить дополнительно – он даже может уменьшиться сам собой[6]. Это еще один механизм самоусиления, причем очень мощный. Его очень успешно в течение многих десятилетий использует компания Toyota[7].
Противоположностью этого механизма я считаю порочный круг, который возникает, когда главной заботой становится постоянная занятость людей. В этом случае первая реакция на застопорившуюся работу заключается не в решении проблемы, а в начале выполнения еще одной рабочей задачи, что приводит к увеличению объема WIP в системе. Чем больше незавершенной работы, тем больше время ожидания у тех, кто будет ее завершать, а значит, проблема только усугубляется. Задержки и одновременное выполнение множества задач оказывают негативное воздействие на качество и являются причиной – да вы и сами, наверное, догадались – ошибок и переделок, большего объема застопорившейся работы и WIP. Слишком много работы в сочетании с плохим качеством – вам нравится такая комбинация?
Я бы не хотел создавать впечатление, что WIP-лимиты на уровне столбцов – это единственный способ ограничения объема незавершенной работы. Он достаточно действенный, но иногда работает лучше в сочетании с другими механизмами. Их можно условно разделить на две основные категории:
1. Уменьшение размера пакетных транзакций – сокращение размера (в плане бюджета и продолжительности) проектов, интервалов между релизами, а также размеров спринтов, размера пакета разрабатываемого функционала и т. д.
2. Уменьшение количества событий, развивающихся параллельно, – сокращение количества бизнес-инициатив (к которым привязаны проекты), сокращение количества сопутствующих проектов в расчете на группу или отдел, сокращение количества рабочих элементов в расчете на группу или на человека и т. д.
Здесь в нашем распоряжении множество рычагов! Выберите правильный, и вы увидите, что другие поддаются легче как в техническом, так и в психологическом смысле. Ограничение объема незавершенной работы разными способами позволяет довести его до такого уровня, который когда-то мог казаться недостижимым.
Ситуация в Будапеште, с которой начинается глава 1, сложилась не сразу. Я пришел работать в организацию, которая просто «подсела» на WIP. Как это часто случается в молодых компаниях, им было просто очень трудно сказать «нет». Это относилось не только к взаимодействию с внешними заказчиками – не говорить «нет» превратилось в привычку и в отношениях между подразделениями компании. От одного совещания к другому списки необходимых дел (а таких списков было очень много) становились все длиннее и длиннее.
Через несколько недель после моего появления в организации и начала плавного и спокойного использования Канбан Метода на совещании руководства случилось очень важное событие. Марк Дикинсон, наш управляющий директор, объявил, что с этого момента персональные списки задач становятся достоянием истории, и мы немедленно от них отказываемся. Сказать, что я обрадовался, было бы сильным преуменьшением – на мой взгляд, произошел существенный прорыв, очень важный для всех нас.
Затем мы стали свидетелями множества таких прорывов. Несколько месяцев спустя количество бизнес-инициатив было сокращено до минимума, остались лишь те, что наиболее эффективно поддерживали нашу бизнес-стратегию. Это, в свою очередь, повлияло на проекты, часть которых были приостановлены или полностью отменены. Как только появилась возможность присмотреться к нашим проектам повнимательнее, оказалось, что вовсе не те из них, что стояли первыми в очереди, являлись более срочными.
Обнадеживало то, что в большинстве случаев процесс смены приоритетов (в сфере ИТ) шел, не дожидаясь моего вмешательства – иногда проекты добровольно отзывали их спонсоры (мои коллеги из руководства). Не знаю, приходилось ли вам сталкиваться с отменой уже выполняемых проектов, но, по моему опыту, это бывает достаточно редко. Если это случается регулярно, то происходит что-то необычное.
Не все работы похожи друг на друга, и это особенно справедливо для интеллектуальной работы. Многие руководители пытаются отрицать разнообразие или избавиться от него, не понимая, что намного лучше воспользоваться им.
Давайте подробно рассмотрим небольшую часть нашей доски, показанной на рис. 2.3.
Пусть вас не смущают непонятные названия трех рабочих элементов, сконцентрируйте внимание на различиях в их визуализации. Для начала возьмем две верхние задачи Tokyo gateway upgrade и Swap curve.
Рабочий элемент Tokyo gateway upgrade помечен карточкой с иконкой в виде календаря, т. е. это рабочий элемент с привязкой к дате. В данном примере речь идет о том, что интерфейс Токийской фондовой биржи должен измениться в определенный день, поэтому нам нужно к этому моменту обновить системы соответствующим образом. Если мы осуществим эти изменения слишком поздно, то не сможем торговать на данной площадке, и это может обойтись организации слишком дорого. Однако слишком ранняя поставка не принесет выгоды – более того, она может быть даже вредной.
Рабочий элемент Swap curve совсем другой. Он представляет совершенно независимую функциональность. Чем скорее он будет выполнен, тем раньше начнет приносить пользу. В отличие от предыдущего примера, этот рабочий элемент не привязан к дате, он является срочным.
О проекте
О подписке