Ресурсы с ограниченной доступностью

 

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

Более показательный пример, особенно по отношению к сквозной теме нашей главы – дорожному движению в штате Вашингтон, – это система паромов, которая действует в заливе Пьюджет и соединяет полуострова Китсап и Олимпик с материком в районе Сиэтла. Здесь три паромные переправы: две из них отправляются из Сиэтла в Бремертон и Бэйнбридж, а моя любимая 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 через залив Пьюджет, который тоже назовут бутылочным горлышком и ресурсом ограниченной мощности во время пикового движения.

 

 

Выводы

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Глава 18