Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

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

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

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

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

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

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

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