Казалось бы, будет лучше, если новый процесс начнет развиваться, устраняя одно ограничение за другим. Это основное положение теории ограничений Голдратта. Понимая, что мне еще многому предстоит научиться, я осознавал ценность материала и устремился вперед в работе над рукописью. Мне было ясно, что книга не давала советов, как внедрить идеи в более широком масштабе, а также почти не помогала найти способы управления изменениями.
Подход Голдратта, изложенный в главе 16, направлен на поиск ограничений, а затем и способов их устранения, чтобы они перестали препятствовать производительности. После этого возникает новое ограничение, и цикл повторяется. Это итеративный подход, предполагающий систематическое улучшение производительности посредством выявления и устранения препятствий.
Я понял, что можно сочетать этот подход с некоторыми приемами из области бережливого производства. Смоделировав рабочий процесс жизненного цикла разработки ПО как потока создания ценности и создав систему отслеживания и визуализации для фиксации изменений состояния возникающей работы, «протекающей» по системе, я мог определить ограничители. Способность выявить ограничение – это первый шаг к модели, лежащей в основе ТОС. Голдратт уже разработал применение этой теории для проблем рабочего процесса, носящее неуклюжее название «барабан-буфер-канат». Однако я понял, что упрощенный вариант этой системы можно внедрить в область разработки ПО.
С точки зрения происхождения «барабан-буфер-канат» – это пример класса решений, известных как вытягивающие системы. Как мы увидим в главе 2, канбан тоже один из примеров такого рода систем. Побочный эффект вытягивающих систем состоит в том, что они ограничивают объем незавершенной работы до установленного заранее количества, препятствуя перегрузке сотрудников. К тому же полностью загруженными остаются только работники, напрямую сталкивающиеся с ограничением; у всех остальных должно оставаться свободное время. Я понял, что вытягивающие системы способны решить обе волновавшие меня проблемы. Вытягивающая система позволит мне внедрять пошаговые изменения, что (как я надеялся) существенно уменьшит сопротивление им, а также облегчит достижение оптимального темпа. Я принял решение перейти на систему «барабан-буфер-канат» при первой возможности. Мне хотелось поэкспериментировать с пошаговой эволюцией процесса и посмотреть, насколько она обеспечивает оптимальный темп и снижает сопротивление изменениям.
Такая возможность появилась осенью 2004 года в Microsoft, что подробно описано в главе 4 этой книги в анализе примера.
От системы «барабан-буфер-канат» к канбану
Применение решения «барабан-буфер-канат» в Microsoft дало свои результаты. Сопротивление было слабым, производительность выросла более чем втрое, время опережения сократилось на 90 %, а предсказуемость повысилась на 98 %. Осенью 2005 года я сообщил о достигнутых результатах на конференции в Барселоне{5}, а зимой 2006 года сделал еще один доклад. Моя работа привлекла внимание Дональда Рейнертсена, который специально приехал ко мне в офис в Редмонде. Он хотел убедить меня, что все готово к полному переходу на канбан.
К счастью, Дон привел убедительный аргумент в пользу перехода с системы «барабан-буфер-канат» на канбан. Он звучал довольно эзотерически: система канбан обеспечивает более гладкий переход с простоя в узком месте, чем «барабан-буфер-канат». Однако понимание подобной отличительной особенности не так уж обязательно, чтобы читать и понимать эту книгу.