Вашингтон SR-520 – это шоссе, которое связывает Сиэтл с его северо-восточными пригородами Кирклендом и Редмондом. Основная артерия для жителей пригородов, работающих в центре города, а также для сотрудников Microsoft и других базирующихся в этих пригородах высокотехнологичных компаний (например, AT&T, Honeywell и Nintendo), которые живут в городе и ездят на работу в обратном направлении. Каждый день в течение восьми часов дорога представляет собой бесконечную пробку – бутылочное горлышко в обоих направлениях. Если после обеда встать на мосту, который пересекает шоссе по Северо-Восточной 76-й улице в небольшом пригороде Медина (недалеко от дома Билла Гейтса на берегу озера Вашингтон), и посмотреть на восток, то видно, как пробка ползет на запад, по направлению к городу, медленно карабкаясь на холм из Бельвью, прежде чем распадается на две полосы, пересекая понтонный мост в Сиэтл. Скорость пробки, движущейся вверх по холму, составляет примерно 15 километров в час, и машины в потоке постоянно останавливаются. Если вы пересечете улицу и посмотрите на запад, на небоскребы Спейс-Нидл и Олимпик-Маунтинс в центре Сиэтла, то увидите гладкое движение со скоростью около 80 километров в час. Что за волшебство творится прямо у вас под ногами, почему скорость так резко меняется, а поток из рваного делается гладким? Дело в том, что прямо перед мостом дорога сужается с трех полос до двух – нужно пересечь озеро по понтонному мосту. Крайняя правая полоса шоссе предназначена для автомобилей с двумя и более пассажирами. Она занята общественным транспортом – автобусы ездят в город и из него – и некоторым количеством личных автомобилей. Эти машины вливаются в другой поток, чем вызывают замешательство и замедляют движение. На протяжении нескольких километров перед мостом в шоссе вливается еще несколько дорог, что увеличивает загруженность шоссе в пиковое время. В результате поток имеет рваный ритм и очень низкую скорость.

Планируя безопасность дорожного движения, специалисты беспокоятся о дистанции между машинами. В идеале она должна быть достаточной, чтобы отреагировать на изменения и при необходимости срочно и безопасно остановиться. Это расстояние зависит от скорости и времени реакции. Правила рекомендуют «дистанцию» в две секунды. На языке бережливого производства это идеальное время такта между машинами. Если у нас есть две полосы и две секунды между машинами, то максимальная пропускная способность дороги – 30 машин на полосу в минуту, то есть 60 машин в минуту. Это верно независимо от скорости машин. Не выполняются эти правила только в экстремальных случаях – для очень малых скоростей и для очень высоких, существенно превышающих ограничение в 80 километров в час, установленное на SR-520. Таким образом, пропускная способность (которая в управлении транспортными потоками называется емкостью, что приводит к некоторым недоразумениям) составляет 3600 машин в час.

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

Понтонный мост через озеро Вашингтон – это бутылочное горлышко. Все мы понимаем, что это значит. От ширины бутылочного горлышка зависит скорость, с которой можно наполнить или опустошить бутылку. Из широкого горлышка вода льется быстро, но в таком случае велик риск все пролить. Если горлышко узкое, то вода льется медленнее, но точность в этом случае выше. Бутылочные горлышки ограничивают потенциальную пропускную способность – в нашем случае от 60 машин в минуту, то есть 3600 в час, до менее чем 10 машин в минуту, то есть 600 в час.

Бутылочное горлышко в потоке проекта находится в любом месте, где выстраивается очередь на обработку заданий. В случае с шоссе SR-520 эта очередь состоит из автомобилей, ждущих въезда на мост в 11 километрах к востоку. В разработке ПО это может быть любая очередь заданий, с которыми еще не начали работать, или заданий в работе: требования, ожидающие анализа, результаты анализа, которые нужно проектировать, разрабатывать и тестировать, протестированные задания, которые нужно выпускать, и т. д.

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

SR-520 в районе моста Северо-Восточной 76-й улицы – ресурс ограниченной мощности. Она составляет 60 автомобилей в минуту в двух полосах. Дорога, ведущая к этому отрезку, имеет три полосы, так что участники движения вынуждены перестраиваться, чтобы пересечь озеро по древнему понтонному мосту, который был спроектирован 50 лет назад и рассчитан на две полосы. В то время этого вполне хватало – никакого бутылочного горлышка не предвиделось. Восточные пригороды были небольшими поселениями, так что пересекать мост приходилось редко, притом в основном в город, а не в обратную сторону, как сейчас.

С точки зрения ограниченности ресурсов можно провести аналогию между SR-520 и девушкой – дизайнером пользовательского интерфейса в команде по производству ПО, отвечающей за проектирование всех экранов, на которых происходит взаимодействие с пользователем. Дизайнер работает усердно, но ее мощности не хватает, чтобы покрыть все потребности проекта. Естественная реакция большинства менеджеров – нанять кого-то ей в помощь. В теории ограничений Элияху Голдратта такое решение называется «расширением ограничений»: мы добавляем мощности, и бутылочное горлышко устраняется.

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

Оказывается, увеличение мощности ограниченного ресурса – это крайний вариант. Расширение бутылочного горлышка стоит времени и денег. Если, например, нанимать второго дизайнера пользовательского интерфейса, то надо найти не только средства на его зарплату, но и бюджет на сам процесс найма, который может включать комиссионные для агентов по подбору персонала. Пока мы рассматриваем резюме и проводим собеседования с кандидатами, тормозится ход текущего проекта. А наш самый драгоценный ресурс, та самая девушка – дизайнер пользовательского интерфейса с ограниченной мощностью, будет вынуждена отрываться от работы по проекту, чтобы читать резюме, отбирать кандидатов, проводить собеседования. В результате ее возможности заниматься дизайном сокращаются, как и потенциальная пропускная способность всего проекта. Именно из-за таких ситуаций появился закон Фреда Брукса, который гласит: «Если проект не укладывается в сроки, то добавление рабочей силы только еще больше задержит его». Наблюдения Брукса были основаны на отдельных случаях, а сейчас можно дать научное объяснение этого феномена; в производстве ПО, по крайней мере, в последние 35 лет установилось понимание того, что при наборе дополнительных сотрудников проект замедляется.

Вместо того чтобы немедленно расширять бутылочное горлышко, теряя время и деньги, замедляя процесс, лучше сначала найти возможность полностью использовать мощность этого ресурса. Например, мы выяснили, что SR-520 в пиковое время имеет пропускную способность лишь в 20 % от своего потенциала. Что нужно предпринять, чтобы ее повысить? Давайте немного пофантазируем. Если бы пропускная способность в час пик достигала своего максимума – 3600 машин в час, пришлось бы заменять существующий мост новым? А стало бы время поездки достаточно коротким, чтобы налогоплательщик штата Вашингтон предпочел видеть свои налоги потраченными на более насущные нужды, например на книги для школьных библиотек? Может быть!

Но как использовать весь потенциал дороги? Источник проблемы – это водители. Скорость их реакции и действия, которые они предпринимают, очень разнообразны. Когда машины съезжают с полосы для загруженного транспорта, автомобили в средней полосе должны притормозить и освободить место для съезжающих. Некоторые водители реагируют медленнее остальных, кто-то жмет на тормоза более яростно, а в результате движение становится непредсказуемым. Часть водителей, которых нервирует неустойчивое движение в полосе перед ними и снижение скорости по сравнению с соседней левой полосой, решают перестроиться в нее. Эффект повторяется. Все машины замедляют ход, но пропускной способности вредит не это. Самое важное – расстояние от одной машины до другой. Для равномерного движения желателен двухсекундный зазор между транспортными средствами. Однако человеческий фактор означает, что машины не тормозят и не ускоряются равномерно, так что расстояния между ними расходятся. Разное время реакции отдельных людей, нажимающих на педали газа и тормоза, и время реакции двигателей, трансмиссий и коробок передач в автомобилях означает, что расстояния продолжают расширяться и создается пробка. Вариативность системы оказывает огромное влияние на пропускную способность.

Устранение этой проблемы увлекает нас в сказочную с точки зрения управления автомобилем страну, хотя некоторые немецкие производители уже проводят подобные эксперименты. Системы, которые используют радары и лазеры для оценки дистанции между автомобилями и позволяют сохранить равномерность движения, могут снять вариативность, существующую на SR-520. Такие системы способны эффективно замедлять поток автомобилей, сохраняя интервал между ними. В результате пропускная способность трассы остается высокой. Однако исключение вариативности в отношении частных автомобилей имеет свои пределы. Чтобы обеспечить низкую вариативность транспорта, нужно связать пассажирские автомобили вместе и поставить их на рельсы. Вот, собственно, причина того, почему массовый скоростной железнодорожный транспорт более эффективно, чем автомобильный, справляется с задачей быстрой перевозки большого количества людей.

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

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

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

Долгосрочным решением могут стать инвестиции в автоматизацию тестов. Ключевое слово в этом предложении – «инвестиции». Если вы говорите о них, то обычно имеете в виду расширение бутылочного горлышка. Привлечение дополнительных ресурсов – не единственный метод расширения мощности. Полезная и естественная стратегия для этого – автоматизация. Сообщество agile-программистов за последнее десятилетие многое сделало для развития автоматизации тестирования. Обычно стоит смотреть на автоматизацию как на стратегию расширения. Однако у автоматизации есть и замечательный дополнительный эффект: она снижает вариативность, поскольку повторяющиеся задания и действия воспроизводятся с цифровой точностью. Итак, автоматизация снижает вариативность процесса и может помочь оптимизировать использование мощности следующего бутылочного горлышка.

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

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

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

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

Еще один метод, часто применяемый для обеспечения максимальной загрузки ресурса ограниченной мощности, состоит в том, чтобы убедиться: ресурс никогда не простаивает. Если вдруг ресурс ограниченной мощности оставляют без работы из-за проблемы, неожиданно возникшей выше по цепочке – например, аналитик запросов заболел, – это непозволительная трата времени и средств. Или, предположим, внезапно ограничение снимается. Либо большая часть требований отзывается заказчиком, решившим внести стратегические изменения. Пока команда ждет разработки новых требований, дизайнер пользовательского интерфейса простаивает. Что если действия выше по цепочке по своей природе крайне вариативны? Это обычная ситуация при выявлении требований и разработке. Таким образом, темпы поступления заданий оказываются неравномерными. Причин, по которым ресурс ограниченной мощности может простаивать из-за временного недостатка работы, много. Вариативность темпов поступления новых заданий в очередь (в нашем примере – к дизайнеру пользовательского интерфейса) можно нейтрализовать посредством буфера. Буферизация увеличивает общее число заведенных в системе заданий на работу. С точки зрения бережливого управления добавление буфера заданий приводит к потерям времени, поскольку увеличивает период выполнения. Однако преимущества в пропускной способности, которые обеспечивает равномерный поток работы, проходящий через ресурс ограниченной мощности, обычно ценнее. Вы сделаете больше работы, несмотря на немного удлинившееся время выполнения и слега увеличившееся число заданий в работе.

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

Наш пример в области управления движением – трасса SR-520, чья пропускная способность составляет менее 20 % от потенциальной, – достаточно заурядный для интеллектуальной деятельности, например анализа требований и разработки ПО. Часто благодаря максимальному использованию бутылочного горлышка можно добиться более чем четырехкратного увеличения пропускной способности.

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

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

Давайте вернемся к нашим фантазиям о транспортной системе будущего. Теперь мы решили не строить новый мост через озеро Вашингтон, а снабдить все машины, едущие в час пик по SR-520, новой системой управления скоростью, которая регулирует трафик на одиннадцатикилометровом участке шоссе при помощи радара и беспроводной связи. Эта новая система будет работать своего рода круиз-контролем и заменит управление педалями газа и тормоза. Стимул к установке новой системы на частные автомобили – налоговые льготы. Как только система появится на достаточном количестве автомобилей, она начнет действовать, так что машинам, не оснащенным ею, придется либо искать альтернативный маршрут, либо не ездить в час пик. Результатом станет более равномерный поток движения и возросшее использование мощности бутылочного горлышка. Предполагаю, что такая система при достаточной эффективности сможет вернуть узкому месту около 50 % утраченной мощности. Иными словами, она повысит пропускную способность шоссе SR-520 в пиковое время в два с половиной раза.

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

Тем, кто знаком с теорией ограничений, часто кажется бессмысленным тот факт, что изменения, необходимые для повышения производительности бутылочного горлышка, должны производиться не в нем самом. Рецензируя мою первую книгу, известный член agile-сообщества разработки ПО предположил, что использование теории ограничений в качестве подхода к совершенствованию приведет к тому, что все участники команды захотят стать частью ресурса – бутылочного горлышка. Ведь так они получают максимум внимания руководства. И подобная ошибка вполне естественна. На самом деле, как ни странно, большая часть действий по управлению бутылочными горлышками проводится вдали от них. Многие изменения связаны со снижением избыточной нагрузки на бутылочное горлышко, чтобы увеличить его пропускную способность. Следует обязательно стремиться к максимальному использованию мощности бутылочного горлышка и соответствующему увеличению пропускной способности, а следовательно, и к сокращению времени выполнения проекта, принимая меры по всей цепочке создания ценности, но, как правило, не к бутылочному горлышку.

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

Более показательный пример, особенно по отношению к сквозной теме нашей главы – дорожному движению в штате Вашингтон, – это система паромов, которая действует в заливе Пьюджет и соединяет полуострова Китсап и Олимпик с материком в районе Сиэтла. Здесь три паромные переправы: две из них отправляются из Сиэтла в Бремертон и Бэйнбридж, а моя любимая SR-104 переправляет машины из Эдмондса на восточной стороне в Кингстон на западной. На карте паромный маршрут считается частью дороги SR-104. Здесь часто пишут «дорожная пошлина», вместо того чтобы прямо сказать «тут вам надо сесть на паром». Специалисты-транспортники считают паром дорогой с ограниченной доступностью.

Подъезжая к переправе, вы платите определенную сумму, после чего вас просят подождать. Обычное время ожидания в очереди – около 30 минут: парому требуется около получаса, чтобы пересечь залив Пьюджет, затем 10–15 минут уходит на разгрузку транспортных средств и примерно столько же – на погрузку новых перед отплытием. Как правило, паромная компания использует два судна, поэтому отправление происходит примерно каждые 50 минут. В часы пик на маршруте иногда появляется третий паром, что сокращает время ожидания примерно до 35 минут.

Большую часть времени паромы ходят с почти полной загрузкой, но система ограничена не мощностью. Скопление машин в зоне ожидания – в буфере – и затем загрузка на паром для отплытия (пакетная передача) не говорят о том, что мощность ресурса ограничена. Это свидетельствует об ограниченной доступности. Паромы отходят всего раз или два в час и способны вместить около 220 машин.

В часы пик, например в пятницу днем, паромная система действительно ограничена мощностью. Когда такое случается, количество машин, прибывающих к переправе, начинает превышать вместимость судна. Мощность составляет около 300 машин в час. Автомобили встают в очередь за зоной ожидания, перед пунктом оплаты. Во время пикового спроса образуется пробка, которая растягивается по Кингстону или Эдмондсу на три километра. И тут мало что можно сделать – просто надо ждать. Расширить ограничение при помощи другого парома не так-то просто. Расписание отправлений призвано обеспечить должный уровень обслуживания за достаточное время. Постоянное наличие избыточной мощности слишком дорого обойдется налогоплательщикам штата, которые и оплачивают паромную переправу.

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

Один из известных мне примеров ограниченной доступности связан с билд-инженером. В компании существовало правило, что только члены команды управления конфигурациями могли собирать код и отправлять его в тестовую среду. Это была конкретная стратегия управления рисками, основанная на предшествующем опыте: разработчики часто проявляли небрежность и собирали такой код, который разрушал тестовую среду. А тестовая среда нередко была общей для нескольких проектов, так что негативное воздействие плохой сборки оказывалось существенным. Технологический отдел не очень хорошо справлялся с координацией на программном уровне, и возникала вероятность того, что одна команда и один проект работали с общими IT-системами, что могло повлиять и на другой проект.

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

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

Например, в Corbis Дуг Буррос был назначен билд-инженером на проект технической поддержки. Но одновременно выполнял и две другие задачи: создавал новые среды и сопровождал существующие. Как инженер по управлению конфигурациями, он должен был поддерживать актуальность сред, то есть следить за обновлением оперативной системы, применением патчей и обновлений для серверов баз данных и межплатформенного программного обеспечения, системных конфигураций, топологии сети и т. д. Примерно час в день у него занимало выполнение функций билд-инженера – обычно с десяти до одиннадцати утра. Если разработчики в три часа дня обнаруживали, что им необходима тестовая сборка, приходилось ждать до начала следующего рабочего дня. Билд-инженер был ресурсом с ограниченной доступностью. Работа блокировалась, и, поскольку техническое обслуживание выполнялось при помощи канбан-системы, задания быстро выстраивались в очередь по всей цепочке создания ценности, вызывая простой других сотрудников.

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

Прежде всего следовало понять, что Дуг – это ресурс с ограниченной доступностью, и выявить влияние, которое оказывает этот фактор. Задания выстраивались в очередь за время недоступности билд-инженера, потому что канбан-лимиты были жестко определены. Он стал источником вариативности в потоке, значит, следовало организовать буфер заданий перед Дугом. При этом требовался достаточно большой буфер, чтобы поток продолжал двигаться, но не настолько, чтобы Дуг превратился в ресурс с ограничением мощности. Я поговорил с ним, и оказалось, что он легко может собирать до семи элементов за час своей работы в этой должности. Поэтому мы создали буфер с канбан-лимитом, равным семи, дали знать об этом всем участникам цепочки создания ценности и начертили на стене карточек новый столбец под названием «Сборка готова». Общий WIP-лимит системы увеличился примерно на 20 %, но это принесло результат. Хотя сборки были ресурсом с ограниченной доступностью, действия выше по цепочке могли обеспечивать равномерный поток работы в течение дня. В результате существенно повысилась пропускная способность, а время выполнения сократилось, несмотря на увеличение WIP-лимита. Мы также решили изменить график Дуга: вместо одного часа подряд два раза по полчаса. Их можно было разнести по времени: тридцать минут утром и столько же – днем. Это облегчило бы поток и снизило давление на буфер для ожидания доступа. Возможно, от этого размер буфера уменьшился бы до двух или трех, что повысило бы WIP-лимит всего на 10 % и привело к сокращению времени выполнения для всей системы.

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

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

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

Другой вариант – отказ от идеи многозадачности и полное вовлечение Дуга в работу команды технического обслуживания. Это сулило ему массу свободного времени. Он просиживал бы в ожидании работы, как пожарный в ожидании пожара. Перевод Дуга в режим постоянного ожидания, разумеется, решил бы все проблемы с потоком, но разве это был бы разумный выбор?

Бюджет мог не выдержать набора новых сотрудников в команду управления конфигурациями, которые занялись бы сборкой системы и обслуживанием вместо Дуга. Ведь пришлось бы просить у руководства деньги на оплату труда нового работника, из-за которого другой сотрудник бoльшую часть времени простаивал бы. Каково это с точки зрения управления рисками?

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

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

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

Автоматизация заняла шесть месяцев, на восемь недель были приглашены два подрядчика. Общие финансовые расходы составили примерно 60 тысяч долларов. В результате, однако, Дуг избавился от необходимости производить сборку, которая была доступна в любой момент, когда это требовалось разработчикам. На этом этапе уже можно было исключить буфер и сократить WIP-лимит системы. Это, в свою очередь, привело к небольшому уменьшению времени выполнения.

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

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

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

Теперь вспомним пример с паромом из Эдмондса в Кингстон. Какое расширение возможно здесь? В данный момент штат Вашингтон рассматривает два варианта. Один из них – заменить нынешний устаревающий флот паромов новыми, более крупными и эффективными судами. Кроме того, в Вашингтоне часто применяются понтонные мосты. Два из них – через озеро Вашингтон, в том числе и тот, который составляет часть SR-520 (возможно, это самый длинный такой мост в мире), а еще один ведет через канал Худ и является частью шоссе SR-104. Сейчас рассматривается возможность постройки нового, рекордного по длине моста через залив Пьюджет, продолжающего SR-104 и полностью заменяющего паромную переправу. Планируемый мост не только решит проблему ограниченной мощности в пиковое время, но и устранит проблемы ограниченной доступности, которые мешают рассматривать все паромные переправы как вариант организации движения. Этот мост будет способствовать экономическому росту полуостровов Китсап и Олимпик. Возможно, лет через пятьдесят в другой книге будет обсуждаться понтонный мост на трассе SR-104 через залив Пьюджет, который тоже назовут бутылочным горлышком и ресурсом ограниченной мощности во время пикового движения.

• Бутылочные горлышки сдерживают и ограничивают поток работы.

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

• Мы управляем бутылочными горлышками в соответствии с пятью направляющими шагами теории ограничений.

• Повышение мощности бутылочного горлышка называется расширением.

• Действия, направленные на увеличение мощности ресурса с ограниченной мощностью, обычно отличаются от действий, направленных на увеличение мощности ресурса с ограниченной доступностью.

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

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

• Часто на практике бутылочные горлышки демонстрируют мощность существенно ниже теоретической.

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

• Защита, как правило, заключается в добавлении буфера незавершенных заданий перед бутылочным горлышком. Это верно как для ресурсов с ограниченной мощностью, так и для ресурсов с ограниченной доступностью.

• Загрузка обычно обеспечивается изменением правил, контролирующих работу ресурса – бутылочного горлышка.

• Для обеспечения загрузки могут использоваться классы обслуживания.

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

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

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

• Необходимо сначала стремиться к полной загрузке и только потом пытаться увеличить мощность ресурса.

• Нередко тактические действия по загрузке и подчинению ограничению производятся в то же время, что и внедрение плана стратегических изменений по расширению ограничения в долгосрочной перспективе.