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

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

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

Отслеживание WIP

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

Рис. 12.1. Пример кумулятивной диаграммы потока из канбан-системы (за 2007 год)

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

Время выполнения

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

Рис. 12.2. Пример спектрального анализа времени выполнения

Рис. 12.3 Пример тенденции среднего времени выполнения

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

Рис. 12.4. Пример отчета, демонстрирующего среднее время выполнения и долю заданий, выполненных в срок

Доля заданий, выполненных в срок

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

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

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

Разумеется, самый важный показатель – был ли элемент выпущен до дедлайна.

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

Пропускная способность

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

Рис. 12.5. Пример столбиковой диаграммы пропускной способности

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

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

Проблемы и блокированные рабочие элементы

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

.

Рис. 12.6. Пример диаграммы проблем и заблокированных рабочих элементов

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

Эффективность потока

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

Рис. 12.7. Пример отношения времени выполнения к выделенному времени

Пусть вас не пугает, что изначально отношение равняется, например, 10: 1. Я был на многих конференциях, где докладчики, представлявшие самые разные сферы деятельности – от строительства самолетов до проектирования медицинского оборудования, – сообщали о таких же показателях.

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

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

Первоначальное качество

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

Рис. 12.8. Диаграмма количества дефектов на функцию

Критическая нагрузка

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

Выводы

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

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

• Время выполнения – это индикатор деловой гибкости.

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

• Сообщайте о доле заданий, выполненных в срок, как индикаторе предсказуемости.

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

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

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

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

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

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

Как справиться с этими проблемами?

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

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

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

Иерархические требования

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

Разработка на основе функционала тоже имеет три типа требований: для функций, наборов функций (или заданий) и тематических областей.

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

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

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

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

Разделение поставки ценности и вариативности рабочих единиц

Поскольку большая часть Канбан-команд отслеживает только два верхних уровня требований, появилась идея о том, что верхний, наименее детализированный уровень требований обычно описывает какую-либо неделимую единицу ценности, создаваемую для рынка или клиента. Эти эпики, или пользовательские требования, часто писали так, чтобы после реализации их можно было вывести на рынок. Если же продукт уже обслуживался, то запросы можно было обрабатывать и выпускать в индивидуальном порядке. Иногда этот уровень требований в Канбан-сообществе именуется «минимальной коммерчески ценной функцией» (Minimal Marketable Feature, MMF). Небольшая терминологическая путаница связана с тем, что MMF была определена Денном и Клиланд-Хуань в книге Software by Numbers, причем их определение не вполне соответствует используемому на практике. Поэтому я использую понятие «минимальный коммерчески ценный релиз» (Minimal Marketable Release, MMR), которым обозначаю ряд функций, воспринимаемых клиентом как единый набор и достаточно полезных, чтобы оправдать издержки релиза.

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

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

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

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

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

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

Взяв на вооружение этот двухъярусный подход, мы отделили создание ценности от вариативности размеров и усилий, затрачиваемых на ее создание.

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

Двухуровневые стены карточек

Первые команды, использовавшие Канбан в работе над крупными проектами, имели дело с двухуровневыми стенами карточек (пример – на рис. 13.1).

Рис. 13.1. Фотография двухуровневой доски

На этой фотографии крупные требования обозначены зелеными карточками. Они движутся слева направо, переходят в различные состояния: «бэклог», «предложено» (анализ), «в работе» (проектирование и разработка), «устранено» (тестирование) и «закрыто».

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

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

Желтые карточки привязываются к породившим их зеленым: на желтые карточки наклеиваются ярлыки, где указаны ID зеленых.

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

Введение «плавательных дорожек»

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

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

.

Рис. 13.2. Фотография двухуровневой доски с «плавательными дорожками»

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

Альтернативный подход к борьбе с вариативностью трудозатрат

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

Введение классов обслуживания

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

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

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

Системная интеграция

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

Управление общими ресурсами

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

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

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

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

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

Выводы

• Крупные проекты должны выполняться в соответствии с ключевыми принципами Канбана.

• WIP-лимиты, каденция приоритетов, каденция релизов и классы обслуживания остаются полезными и в крупных проектах.

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

• Обычно команды отслеживают два верхних уровня иерархии требований на стене карточек и задают WIP-лимиты на одном или обоих уровнях.

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

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

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

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

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

• Крупные WIP ограничиваются количеством «плавательных дорожек».

• Детализированные WIP при желании можно ограничить на каждой «плавательной дорожке».

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

• Спрос на общие ресурсы можно визуализировать при помощи небольших стикеров, прикрепляемых к обычным рабочим элементам.

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

• Общие ресурсы должны разработать собственные канбан-системы.

• Сеть канбан-систем для общих ресурсов в портфеле проектов можно считать архитектурой для обслуживания запросов на разработку ПО.

До совещания

Половина восьмого утра, вторая пятница марта 2007 года. Я пришел на работу так рано, потому что сегодня у нас в отделе четвертый ежемесячный анализ производственного процесса. Со мной Рик Гарбер, менеджер нашей группы процессов разработки ПО. Рик будет координатором совещания – он отвечает за повестку. Сейчас он распечатывает раздаточный материал для сегодняшнего анализа, который состоит примерно из 70 слайдов презентации в PowerPoint. Когда он заканчивает, мы направляемся в Harbor Club в деловой части Сиэтла с коробкой раздаточного материала на сто человек. Совещание назначено на 8:30 утра, но завтрак подается с восьми. Приглашены все сотрудники моей организации и компании моего коллеги Эрика Арнольда. Однако поскольку некоторые из них работают в Индии, другие – в других штатах США, а кое-кто не может посетить совещание по личным причинам, присутствует обычно человек восемьдесят.

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

Группа начинает собираться, все стараются успеть к завтраку. Зал находится на верхнем этаже сиэтлского небоскреба, откуда открывается прекрасный вид на город, гавань, пирсы и Эллиотт-Бэй[8]. В зале стоят круглые столы, за каждым – от шести до восьми человек. В одном конце зала – прожектор и кафедра. Рик действует в строгом соответствии с расписанием. Каждому выступающему дается примерно восемь минут, чтобы показать свои четыре-пять слайдов. Предусмотрены несколько отрезков времени на случай непредвиденных задержек, вызванных вопросами и обсуждениями. Я начинаю совещание с коротких вступительных замечаний: прошу всех мысленно вернуться к концу января и вспомнить, чем мы тогда занимались. Я напоминаю всем, что мы должны сейчас проанализировать работу организации за февраль. Рик подобрал отличную картинку из архивов компании, которая символизирует основную тему месяца и помогает вспомнить о том, чем мы тогда занимались.

Сразу задайте деловой тон

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

Приглашение гостей расширяет аудиторию и создает дополнительную ценность

Следующий докладчик – наш гость, вице-президент другого подразделения. Я уже понял: если мы хотим, чтобы наши партнеры по цепочке создания ценности интересовались нами, нужно проявить интерес к ним и пригласить на встречу. По регламенту гостю отводится 15 минут, которыми он и воспользовался: мы прослушали презентацию, касающуюся отдела сбыта – того подразделения бизнеса, которое выполняет заказы клиентов и занимается доставкой продукта. Хотя бизнес Corbis делается в основном через интернет и заказы выполняются в электронной форме, не все, что предлагает наша фирма, доставляется посредством скачивания. Целый отдел занят удовлетворением более сложных заказов, поступающих из различных источников – от профессиональных рекламных агентств до медиакомпаний. Мой коллега Эрик Арнольд попросил гостя оплатить общий завтрак, чтобы удержать наши расходы в пределах допустимого. За несколько месяцев наша команда узнала о многих аспектах бизнеса, а руководителям компании стало известно о том, чем мы занимаемся, как это делаем и насколько интенсивно трудимся над решением проблем. В результате через девять месяцев топ-менеджеры рассуждали о том, как хорошо управляется IT-команда, и о необходимости остальным подразделениям следовать нашему примеру.

Основная повестка

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

Ежемесячный анализ производственного процесса, проходивший в марте 2007 года, был особенно интересным. Первый прошел в декабре, пришли почти все. Людям было любопытно, и впоследствии они говорили: «За всю карьеру не встречал такой прозрачности» или «Это было очень интересно». Один из самых полезных отзывов звучал так: «Хорошо бы, чтобы в следующий раз нам предложили не холодный, а горячий завтрак». Мы с этим согласились. В следующем месяце народ говорил: «Да, еще один отличный месяц. Спасибо за горячий завтрак!» А на третьем собрании некоторые спрашивали: «Зачем так рано вставать?» или «Думаете, это не пустая трата времени?»

На четвертой встрече мы анализировали серьезную проблему: компания приобрела бизнес в Австралии, и IT-отдел должен был выключить все IT-системы австралийской дочерней структуры, перевести всех 50 пользователей на системы Corbis. Дату выполнения запроса назначили произвольно, но он был срочным. Дата была связана с экономией на масштабах, которая должна была частично отбить сумму покупки, так что опоздание грозило издержками. Запрос поступил в очередь на обслуживание как единый элемент. По размеру он мог соответствовать даже десяти карточкам, но мы назначили для него всего одну. Эффект от поступления в канбан-систему такой монстрообразной рабочей единицы хорошо известен в промышленности. Система забивается, и время выполнения всего того, что следует за этим элементом, значительно увеличивается. Так и произошло. Время выполнения выросло с 30 до 55 дней. Теория массового обслуживания также утверждает, что сокращение журнала ожиданий при полной загрузке требует значительного времени. Мы выяснили: чтобы вернуться к целевому времени выполнения, понадобится пять месяцев.

Вдобавок у нас был релиз, который требовал срочной отладки.

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

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

Ключ для перехода к бережливым принципам

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

Подходящая каденция

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

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

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

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

Демонстрация ценности менеджеров

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

Фокус на организации содействует кайдзену

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

Более ранний пример операционных обзоров

Операционные обзоры придумал не я. Они характерны для многих крупных компаний. Но я научился проводить их объективно и масштабно, когда в 2001 году работал в Sprint PCS. Мой руководитель, вице-президент и генеральный менеджер sprintpcs.com, учредил их примерно с теми же целями. Он хотел повысить зрелость своей организации – подразделения, состоявшего из 350 человек, отвечавшего за сайт, всю электронную коммерцию и онлайновую поддержку клиентов в компании Sprint, занимавшейся сотовой связью. В sprintpcs.com операционный обзор проводился каждую третью пятницу месяца в два часа дня. Он продолжался два часа, участвовали около 70 старших сотрудников и менеджеров соответствующего подразделения, приглашались также директора или старшие менеджеры наших партнеров по цепочке создания ценности. Часто бывали и высшие руководители, в том числе директор по маркетингу и вице-президент по стратегическому планированию. Формат очень походил на то, что было позднее реализовано в Corbis. Все проводилось исключительно на основании объективных данных. Каждый менеджер представлял собственные данные. Открывалось совещание финансовой информацией. Расписание было распланировано и четко соблюдалось. После совещания все уходили домой пораньше, тем более что была пятница. Совещание проводилось не на территории офиса, а в кампусе местного колледжа. Хотя методы гибкой разработки ПО в целом давались sprintpcs.com тяжело, операционный обзор был ключевым элементом в развитии зрелости организации и совершенствовании управления ею. Он демонстрировал сотрудникам, что менеджеры знают, как руководить, а сотрудники и руководители направления имеют возможность показать высшему руководству, чем они могут помочь и где менеджерам необходимо вмешаться, чтобы повысить эффективность. На основании двух экспериментов, проведенных за последнее десятилетие, я убедился, что операционные обзоры – это необходимый элемент успешного перехода к бережливым или agile-принципам и жизненно важный компонент развития зрелости организации.

Выводы

• Операционный обзор проводится в масштабе всей организации.

• Операционный обзор должен придерживаться объективных данных.

• Каждый отдел сообщает свои данные.

• Презентации должны быть короткими и в основном содержать показатели и индикаторы вроде тех, о которых говорилось в главе 12.

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

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

• Совещания должны быть короткими – желательно около двух часов.

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

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

• Эффективный операционный обзор создает взаимное доверие между менеджерами и сотрудниками.

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

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

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

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

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

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

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

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

• Менеджеры должны нести ответственность и демонстрировать систематическую работу над предложениями.