Текст бизнес-книги "Канбан Метод. Улучшение системы управления"

Автор книги: Майк Барроуз

Раздел: О бизнесе популярно, Бизнес-книги

Глава 2
Баланс

Баланс – это ценность, тесно связанная со второй основной практикой канбана:

ОП2: ограничивайте объем незавершенной работы (WIP – work-in-progress).

В первой части этой главы я продемонстрирую, как ограничение WIP на канбан-доске работает в качестве механизма координации для реализации вытягивающей системы. Позже мы рассмотрим другие случаи проявления баланса в канбане.

Рассмотрим столбец «Тест» на доске (рис. 2.1).

В правом верхнем углу столбца «Тест» стоит цифра 4. Она обозначает WIP-лимит, т. е. максимально допустимое в этой зоне количество рабочих элементов. В приведенном примере общее количество рабочих элементов в столбце «Тест» (включая два его подстолбца «В работе» (In Progress) и «Выполнено» (Done)) не должно превышать четырех. Наше приложение выделяет лимит, потому что эта часть доски в данный момент максимально загружена.

Теперь посмотрим, что происходит на рис. 2.2, когда карточки перемещаются вправо, причем как внутри, так и (что важно) за пределы выделенной зоны.

Зона «Тест» на доске теперь не заполнена целиком. Пространство в подстолбце «В работе», оставшееся пустым, играет очень важную роль – оно сигнализирует, что можно вытянуть туда карточку из соседнего (левого) столбца.

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

Если не устанавливать WIP-лимиты, то сигналы для перемещения карточек теряются. Перемещающийся влево поток сигналов останавливается, как только достигнет столбца, в котором отсутствует ограничение (в данном случае это столбец «Предложено» (Proposed) на левом краю доски).

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


[Закрыть].

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

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

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

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

Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные факторы усовершенствований в масштабах всей системы. Когда вы уменьшаете объем WIP, то делаете намного более очевидными другие проблемы (а они могут мешать еще сильнее). Решите их, и тогда объем WIP можно будет уменьшить дополнительно – он даже может уменьшиться сам собой[6]6
  Более полное объяснение этого эффекта см. в разделе «Закон Литтла» в главе 17.


[Закрыть]. Это еще один механизм самоусиления, причем очень мощный. Его очень успешно в течение многих десятилетий использует компания Toyota[7]7
  Информацию о системе организации производства в компании Toyota см. в части II, глава 14.


[Закрыть].

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

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

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

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

Здесь в нашем распоряжении множество рычагов! Выберите правильный, и вы увидите, что другие поддаются легче как в техническом, так и в психологическом смысле. Ограничение объема незавершенной работы разными способами позволяет довести его до такого уровня, который когда-то мог казаться недостижимым.

Ситуация в Будапеште, с которой начинается глава 1, сложилась не сразу. Я пришел работать в организацию, которая просто «подсела» на WIP. Как это часто случается в молодых компаниях, им было просто очень трудно сказать «нет». Это относилось не только к взаимодействию с внешними заказчиками – не говорить «нет» превратилось в привычку и в отношениях между подразделениями компании. От одного совещания к другому списки необходимых дел (а таких списков было очень много) становились все длиннее и длиннее.

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

Затем мы стали свидетелями множества таких прорывов. Несколько месяцев спустя количество бизнес-инициатив было сокращено до минимума, остались лишь те, что наиболее эффективно поддерживали нашу бизнес-стратегию. Это, в свою очередь, повлияло на проекты, часть которых были приостановлены или полностью отменены. Как только появилась возможность присмотреться к нашим проектам повнимательнее, оказалось, что вовсе не те из них, что стояли первыми в очереди, являлись более срочными.

Обнадеживало то, что в большинстве случаев процесс смены приоритетов (в сфере ИТ) шел, не дожидаясь моего вмешательства – иногда проекты добровольно отзывали их спонсоры (мои коллеги из руководства). Не знаю, приходилось ли вам сталкиваться с отменой уже выполняемых проектов, но, по моему опыту, это бывает достаточно редко. Если это случается регулярно, то происходит что-то необычное.

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

Давайте подробно рассмотрим небольшую часть нашей доски, показанной на рис. 2.3.

Пусть вас не смущают непонятные названия трех рабочих элементов, сконцентрируйте внимание на различиях в их визуализации. Для начала возьмем две верхние задачи Tokyo gateway upgrade и Swap curve.

Рабочий элемент Tokyo gateway upgrade помечен карточкой с иконкой в виде календаря, т. е. это рабочий элемент с привязкой к дате. В данном примере речь идет о том, что интерфейс Токийской фондовой биржи должен измениться в определенный день, поэтому нам нужно к этому моменту обновить системы соответствующим образом. Если мы осуществим эти изменения слишком поздно, то не сможем торговать на данной площадке, и это может обойтись организации слишком дорого. Однако слишком ранняя поставка не принесет выгоды – более того, она может быть даже вредной.

Рабочий элемент Swap curve совсем другой. Он представляет совершенно независимую функциональность. Чем скорее он будет выполнен, тем раньше начнет приносить пользу. В отличие от предыдущего примера, этот рабочий элемент не привязан к дате, он является срочным.

Если мы сможем завершить выполнение срочного рабочего элемента раньше рабочего элемента, привязанного к определенной дате, то это прекрасно. Однако приоритет переходит к рабочему элементу с привязкой к дате, как только возникнет опасение, что он оказывается под угрозой. И в том и в другом случае мы получаем хорошие результаты[8]8
  Здесь я допускаю небольшое упрощение – задачи с привязкой к дате не всегда настолько важны, чтобы желание выполнить их точно в срок перевешивало другие соображения. Мы рассмотрим подробнее экономику принятия таких решений в главе 15.


[Закрыть].

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

Многие команды разработчиков страдают из-за того, что либо привязывают все рабочие элементы к определенной дате, втискивают слишком много работы во временны́е окна, либо, что еще хуже, привязывают каждый рабочий элемент к дате индивидуально. В результате оценочные сроки превращаются в обязательства. Целевые показатели продуктивности растягивают обязательства до предела, и это происходит в тот момент, когда начинаются первые заминки!

Рабочий элемент Try MongoDB (оставшийся в столбце) не кажется ни привязанным к дате, ни срочным. Но разве из-за этого он становится неважным? По этому рабочему элементу судить трудно, но где мы окажемся через год или два, если не будем экспериментировать и делать неафишируемую работу, ориентированную на перспективу и расширение наших возможностей в плане платформ, продуктов, процессов или людей?

Если смотреть только на график выполнения работы (без учета характера результатов или базовых рабочих процессов), то наши примеры укладываются в три качественно разные категории. Канбан Метод обычно определяет следующие четыре категории.

● Ускоренные (Expedite): рабочие элементы настолько срочные, что приходится откладывать выполнение других работ и немедленно переключаться на них.

● Привязанные к дате (с фиксированной датой) (Date-driven или Fixed Date): рабочие элементы, невыполнение которых к конкретной дате приводит к наложению существенного штрафа, несопоставимого с любой выгодой от ранней поставки. Такие риски срыва графика тщательно контролируются.

● Стандартные (Standard), или регулярные[9]9
  Маркус Хаммарберг и Йоаким Сунден рекомендуют использовать менее обремененное понятие «регулярная» вместо общепринятого понятия «стандартная», и я буду рад, если оно приживется.


[Закрыть] (Regular): срочные рабочие элементы, выполняемые в соответствии с порядком, согласованным с заказчиками, или в последовательности, соответствующей выбранным вами правилам. В зависимости от ситуации правила выполнения могут быть такими простыми, как «первым пришел – первым ушел» (first in, first out – FIFO), базироваться на такой экономической модели, как «стоимость задержки» (cost of delay) (глава 15), или просто на личном выборе.

● Нематериальные (Intangible): расширение возможностей, эксперименты в области технологий или на рынке, инвестиции в человеческие ресурсы – работа, результаты которой проявляются в среднесрочной или долгосрочной перспективе, но непосредственный бизнес-эффект трудно оценить количественно.

Возможна также классификация на основе других аспектов риска. В существующей в организации системе планирования может быть своя классификация, например в банках часто используются такие категории, как «Инновации», «Техническое обслуживание», «Поддержка», «Нормативные документы».

Когда в основе классификации лежит предложение разных уровней обслуживания, мы называем их классами обслуживания (classes of service). На внешнем уровне мы помогаем заказчику выбрать тот класс обслуживания, который, с его точки зрения, наилучшим образом отражает правильный баланс риска и вознаграждения. На внутреннем уровне стратегия планирования помогает выбрать рабочие элементы так, что хорошие результаты достигаются в большинстве случаев. Правильный набор рабочих элементов, особенно такой, который создает достаточные запасы стандартных и нематериальных рабочих элементов, позволяет добиться очень высокой степени предсказуемости.

Внутри системы мы стараемся найти баланс между загрузкой и возможностями системы. Это делается как ради людей, выполняющих работу, так и ради повышения результативности и предсказуемости. Но останавливаться на этом не следует.

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

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

Короче говоря, канбан помогает находить баланс между нагрузкой и возможностями на разных временны́х интервалах. Эта эффективная стратегия применима как внутри системы, так и за ее пределами.

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

Никто не может непрерывно оценивать интересы всех перечисленных сторон, но практичные правила позволяют задать правильный тон: если так называемое усовершенствование работает за счет одной из сторон, то надо обдумать ситуацию еще раз и попытаться найти баланс. Если создается впечатление, что идет игра с нулевым результатом, то надо насторожиться. Правильный вариант выглядит так: «Хорошо для заказчиков, хорошо для организации и для исполнителей работы».

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