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

Тем, кто знаком с теорией ограничений, часто кажется бессмысленным тот факт, что изменения, необходимые для повышения производительности бутылочного горлышка, должны производиться не в нем самом. Рецензируя мою первую книгу{20}, известный член 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 через залив Пьюджет, который тоже назовут бутылочным горлышком и ресурсом ограниченной мощности во время пикового движения.

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 18
Экономическая модель бережливого производства

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

Переосмысление «потерь»

Следуя за такими авторами, как Дональд Рейнертсен, я адаптировал понятия из сферы экономики и называю «ведущие к потерям» действия расходами. Расходы подразделяются на три основные абстрактные категории: операционные расходы, координационные расходы и «ошибочная» нагрузка (Failure Load). Категории показаны на рис. 18.1.

Рис. 18.1. Модель экономических расходов для бережливой разработки ПО

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

Эти расходы подробнее обсуждаются в следующих параграфах. Буду описывать их при помощи простого примера – покраски забора вокруг моего дома в Сиэтле.

Операционные расходы

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

Прежде чем начать работу, нужно было найти материалы. Для этого я поехал в магазин Home Depot. Кроме того, требовалось подготовиться: провести мелкий ремонт забора, его шлифовку, подрезку деревьев и кустов, чтобы можно было пройти к забору. Все эти действия не создают ценность. Заказчику неинтересно, что мне нужно ехать в Home Depot и это требует времени.

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

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

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

Когда дело наконец доходит до покраски, выясняется, что с 42 секциями забора (если считать обе стороны) невозможно управиться за один подход. Приблизительная скорость работы – четыре секции в час. Поэтому было решено разбить задачу на шесть этапов. Если бы речь шла о разработке ПО, мы бы назвали их итерациями или спринтами; в производстве это партии. Перед тем как начинать каждый этап покраски, также требовался ряд подготовительных мер. Надо было переодеться, доставить материалы: я переносил краску, кисти и другие инструменты из гаража к месту работы и только после этого начинал красить.

Итак, и проекты, и итерации предполагают подготовительные мероприятия.

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

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

Итак, как итерации, так и проекты предполагают завершающие мероприятия.

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

Итак, два первых типа потерь – это операционные расходы: подготовительные (или начальные) и завершающие (или конечные).

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

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

Координационные расходы

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

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

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

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

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

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

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

Можно попытаться сократить координационную деятельность, найдя другие, более эффективные способы координации работ.

Один из вариантов – дать членам команды полномочия для самоорганизации. Административно-командный тип управления, при котором сотрудники встречаются для предварительного распределения заданий, ведет к потерям. Самоорганизация обычно сокращает координационные затраты на проект. Однако для успешной работы требуется информация. Методы, используемые в Канбане (например, визуальный контроль цепочки создания ценности и визуализация работы на досках с карточками, в электронных инструментах и отчетах), дают достаточно информации для координации, что облегчает самоорганизацию и снижает координационные расходы на проект. Использование классов обслуживания и их визуализация разноцветными карточками или треками на доске наряду с соответствующими наборами правил для каждого класса обслуживания позволяет команде самостоятельно планировать работы и автоматизировать расстановку приоритетов. Иногда это называется самоускорением (я связываю этот термин с Элияху Голдраттом и управлением буферами).

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

Как узнать, что та или иная деятельность влечет за собой расходы

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

Так как определить приводящие к потерям операционные или координационные расходы?

Думаю, нужно спросить себя: «Если эта деятельность действительно создает ценность, то стоит ли тратить на нее больше времени?»

Спросите защитников Scrum, которые абсолютно убеждены, что стендапы создают ценность, не пора ли проводить их два раза в день или увеличить длительность с 15 минут до получаса. Наверняка все они ответят отрицательно. Я возражаю им: «Но ведь если стендапы действительно создают ценность, то увеличение времени должно пойти на пользу!»

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

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

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

«Ошибочная» нагрузка

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

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

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

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

Выводы

• Потери можно разбить на три основные абстрактные категории: операционные расходы, координационные расходы и «ошибочная» нагрузка.

• Концепция «потерь» является метафорой.

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

• Чтобы определить, действительно ли данный вид деятельности влечет потери, спросите себя: «Стали бы мы при возможности отводить на него больше времени?» Если ответ отрицательный, то такая деятельность является той или иной формой потерь.

• Операционные расходы подразделяются на два типа: подготовительная деятельность и завершающая, или релизная, деятельность.

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

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

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

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

Глава 19
Источники вариативности

Вариативность в промышленных процессах изучается с начала 1920-х годов. Пионером в этой области был Уолтер Шухарт. Его методы заложили основу движения по управлению качеством и стали базой как для производственной системы Toyota, так и для метода «шесть сигм», обеспечивающих качество и непрерывное совершенствование. Методы Шухарта были взяты на вооружение, развиты и дополнены Эдвардсом Демингом, Джозефом Джураном и Дэвидом Чемберсом. Их работы вдохновили Уоттса Хамфри и основателей Института технологий разработки ПО Университета Карнеги – Меллон, которые считали, что изучение и систематическое снижение вариативности сулит большие преимущества для разработчиков.

Шухарт, Деминг и Джуран опубликовали множество работ по исследованию вариативности и ее использованию в качестве техники управления, а также как основания для программы усовершенствований. Кроме того, существует немало публикаций, рассказывающих о методе количественной оценки, известном как статистический контроль процессов (СКП) и ставшем основным средством изучения вариативности и борьбы с нею. Теперь СКП взят на вооружение и командами, использующими Канбан. Однако СКП и его применение считается более серьезной темой, к которой мы обратимся в одной из следующих книг. Здесь же только затронем проблему вариативности.

Шухарт разделял вариативность и вариации в производственных показателях на два типа – внутреннюю и внешнюю.

Внутренние источники вариативности – это вариации, которые находятся под контролем задействованной системы. В рамках Канбан-подхода к IT и разработке ПО мы определяем систему как процесс, который задается набором правил, управляющих ее эксплуатацией. Эти правила могут подвергнуться влиянию изменений, вносимых сотрудниками, командой или руководством. Изменения в правилах трансформируют и эксплуатацию системы, и ее производительность. Тем самым изменения в определении процесса – это изменения, которые затрагивают внутренние источники вариативности. Забавно, что такие внутренние вариации Шухарт назвал случайными. Слово «случайный» предполагает, что вариации имеют непредсказуемый характер, что является прямым следствием структуры системы. Но не предполагается, что непредсказуемость равномерно распределена или укладывается в рамки нормального распределения. Изменения в структуре процесса, вызванные изменениями внутренних правил, повлияют на медианное распределение, его распространение и форму.

Приведем пример. Отбивающий в бейсболе обладает коэффициентом ударов (известным также как средний уровень), который показывает, как часто он наносил удары, приводившие как минимум к взятию первой базы. У разных отбивающих разные коэффициенты, обычно они колеблются от 0,1 до 0,35. В любой день такой игрок может продемонстрировать показатели ниже своего среднего коэффициента ударов. Это зависит от ряда факторов: выбора питчера[13], коэффициента успешности ударов других игроков, а также от специфики подач.

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

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

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

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

Внутренние источники вариативности

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

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

Размер единицы работы

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

Как <пользователь>, я хочу <функцию>, чтобы <создать некую ценность>.

Использование шаблона привело к стандартизации написания пользовательских историй. Один из авторов такого подхода, Тим Маккиннон, в 2008 году сообщил мне, что, по его данным, в среднем на создание пользовательской истории требуется 1,2 дня, а вариативность составляет от половины суток до примерно четырех дней.

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

Смешение типов единиц работы

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

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

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

Операционные системы, базы данных, платформы, языки, API и сервисные архитектуры со временем меняются. Для работы с этими изменениями нужно обновлять и код.

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

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

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

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

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

Смешение классов обслуживания

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

Ускоренные запросы – это внешние вариации, поэтому они будут описаны в следующем разделе.

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

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

Рассмотрим пример команды с WIP-лимитом в 20 единиц, из которых 4 приходятся на единицы с фиксированной датой поставки, 10 – на элементы стандартного класса и 6 – на единицы нематериального класса. Можно либо установить правило, что этих более мелких лимитов нужно строго придерживаться, либо ослабить жесткость, чтобы стандартный или нематериальный элемент мог занимать место элемента с фиксированной датой поставки, когда сезонный спрос на такие элементы недостаточен. В разное время года эти правила могут меняться ради общего экономического выигрыша и обеспечения большей предсказуемости системы.

Нерегулярный поток

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

Переработка

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

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

Внешние источники вариативности

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

Двойственность требований

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

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

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

В 2007 году в Corbis это достигалось постепенно. Сначала внедрили канбан-систему – визуальную доску и электронное средство отслеживания. Вместе с этим пришла прозрачность. Бизнес оказался сильнее вовлечен в процесс разработки ПО и в наблюдение за производительностью этого подразделения. Создавались отчеты, демонстрирующие количество нерешенных проблем и заблокированных единиц работы, а также среднее время разрешения этих задач. (Рис. 12.6. Отчет о проблемах и заблокированных единицах работы)

Когда требование проделало путь до приемочного тестирования, но было отвергнуто, поскольку оказалось ненужным бизнесу, команда ответила на это, выделив на доске мусорную корзину и прикрепив к ней талон, как показано на рис. 19.1. После этого руководство попросило создать несколько электронных отчетов о работе, которая поступила в систему, но не смогла проделать весь путь по ней (рис. 19.2).

Рис. 19.1. Доска с мусорной корзиной

Рис. 19.2. Отчет о непринятой и отмененной работе, демонстрирующий незавершенные рабочие единицы за прошлый месяц

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

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

Это один из примеров того, как локально предпринятые меры косвенно влияют на вариации с выявляемой причиной.

Ускоренные запросы

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

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

Необходимость в ускорении можно сократить. Увеличение резервной мощности благодаря усовершенствованию пропускной способности, автоматизации или увеличению ресурсов повысит способность к реагированию. Более короткое время выполнения, высокая прозрачность и организационная зрелость – все это снизит необходимость в ускорении. Хорошие команды, усвоившие Канбан-подход, обычно не злоупотребляют ускоренными запросами. Например, в Corbis за весь 2007 год их было всего пять.

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

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

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

Нерегулярный поток

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

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

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

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

Второй подход связан с неукоснительным проведением политики управления проблемами и их разрешения и, по достижении зрелости команды, с переходом к анализу и устранению первопричин, а также внесению улучшений, направленных на предотвращение вариаций с выявляемыми причинами в будущем. При таком подходе WIP-лимиты, размеры буфера и действующие правила остаются достаточно жесткими, и если задача блокируется, то это останавливает всю работу. Простой сотрудников, назначенных на блокированную задачу, повышает ответственность за блокирующую проблему. После этого может начаться массовая атака на проблему, что, как было установлено, стимулирует простаивающих членов команды думать о первопричинах и возможных изменениях в процессе, которые смогут сократить или исключить возможность новой подобной проблемы. Как показывает практика, сохранение жестких WIP-лимитов и проведение мероприятий по управлению проблемами и их разрешению позволяет создать культуру непрерывного совершенствования. Впервые я столкнулся с этим в Corbis в 2007 году, но есть и другие данные, полученные в 2009 году в таких компаниях, как Software Engineering Professionals (Индианаполис), IPC Media и BBC Worldwide (обе из Лондона). Сейчас уже достаточно информации, позволяющей предположить, что Канбан действительно способствует появлению культуры, сосредоточенной на непрерывном совершенствовании. Среди постоянно появляющихся элементов процесса, которые можно привести в пример, – готовность устанавливать жесткие правила WIP, маркировать работу как заблокированную, позволять потоку останавливаться, вызывая простой, и заниматься управлением проблемами и их решением в качестве устоявшейся организационной практики. Результат – сосредоточение на анализе и устранении первопричин и постепенное внедрение усовершенствований, которые снижают вариации с выявляемыми причинами и помогают распространению культуры непрерывного совершенствования.

Доступ к среде

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

Другие рыночные факторы

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

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

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

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

Некоторые материалы по управлению рисками в канбан-системах, появившиеся в результате использования Канбана, я представлял на конференциях в 2009 году. Они доступны в интернете.

Трудности с координацией

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

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

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

Такое осознание должно привести к поведенческим изменениям, улучшающим ситуацию.

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

Выводы

• Изучение вариативности в промышленных процессах началось в 1920-е годы с Уолтера Шухарта. В середине и конце XX века его дело продолжили и развили Эдвардс Деминг, Джозеф Джуран и Дэвид Чемберс.

• Изучение вариативности и связанный с ним метод статистического анализа лежит в основе производственной системы Toyota (а следовательно, и бережливого управления) и метода «шести сигм» для совершенствования процесса.

• Работы Эдвардса Деминга и Джозефа Джурана – главный источник вдохновения для Института технологий разработки ПО Университета Карнеги – Меллон и модели зрелости возможностей (современное название – «интегрированная модель зрелости», или CMMI).

• Шухарт разделил источники вариативности на две категории: внутренние для процесса или системы и внешние для процесса или системы.

• Внутренние вариации называются вариациями со случайными причинами.

• Внешние вариации называются вариациями с выявляемыми причинами.

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

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

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

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

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

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

• Предстоит еще много работать над передовыми стратегиями и тактиками управления рисками в Канбане – это станет темой следующей книги.