Книга: Канбан. Альтернативный путь в Agile
Назад: Глава 11 Формирование соглашений об уровне обслуживания
Дальше: Глава 13 Масштабирование канбана

Глава 12
Показатели и доклады для руководства

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

Отслеживание 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-лимитами.
• Записывайте время выполнения для каждого обработанного элемента и сообщайте как о среднем времени выполнения, так и о спектральном анализе для каждого класса обслуживания.
• Время выполнения – это индикатор деловой гибкости.
• Отслеживайте отношение ориентировочного времени выполнения к реальному для элементов класса обслуживания с фиксированной датой поставки.
• Сообщайте о доле заданий, выполненных в срок, как индикаторе предсказуемости.
• Препятствия блокируют рабочий поток и негативно сказываются на времени выполнения и доле заданий, выполненных в срок; сообщайте о блокирующих проблемах и количестве заблокированных рабочих элементов посредством кумулятивной диаграммы потока с наложенным на нее графиком заблокированных элементов. Используйте ее, чтобы показать свою способность выявлять проблемы и быстро их решать.
• Эффективность потока – это отношение времени выполнения ко времени, выделенному на работу. Показатель демонстрирует эффективность организации в обработке новых заданий и служит вторичным индикатором деловой гибкости. Он также демонстрирует потенциал для совершенствования, доступный без изменения методов работы.
• Исходное качество – показатель количества ошибок, обнаруженных тестировщиками в пределах системы. Он указывает на то, сколько мощности теряется из-за плохого изначального качества.
• Критическая нагрузка – показатель, сообщающий о доле работы, созданной ошибками в системе. Он говорит о мощности, которая могла быть использована для работы над новыми, создающими ценность функциями.
Назад: Глава 11 Формирование соглашений об уровне обслуживания
Дальше: Глава 13 Масштабирование канбана