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

 

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

.

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

 

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

 

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

 

Выводы

 

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

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

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

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

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

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

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

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

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

 

 

Глава 13

Масштабирование канбана

 

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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