Накопительная диаграмма потока (CFD) как индикатор здоровья вашего проекта

Автор оригинала: Alexei Zheglov
  • Перевод

Предисловие переводчика


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

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

Накопительная диаграмма потока (CFD) как индикатор здоровья вашего проекта


Это накопительная диаграмма потока здорового проекта:


Серая заливка в правой нижней части представляет ценность для заказчика, доставленную ему и распознаваемую им.

Непосредственно над ним проходит тонкая оранжевая линия, отображающая объём текущей работы (work in progress, WIP).

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

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

Руководитель проекта добился короткого и, в достаточной степени, предсказуемого срока выполнения работ, уделяя особое внимание задержкам и зависимостям. Он не контролировал объём незавершённой работы (WIP) строго, но вмешивался, когда в середине рабочего процесса скапливалось слишком много рабочих элементов. В результате количество одновременно выполняемых элементов было в среднем около 4% от общего объёма работ и никогда не превышало 8%. Среднее время завершения элемента было существенно меньше (около 4%) общей длительности проекта. Это обеспечивало быструю обратную связь и возможность корректировки хода работ, основанных на результатах, полученных от предыдущей поставки ценности заказчику.

Сформулируем общие рекомендации для проектов:

  • Определите объём проекта в терминах рабочих элементов, распознаваемых заказчиком, приносящих ему ценность.
  • Время завершения отдельного рабочего элемента в среднем должно быть существенно меньше, чем длительность проекта в целом. Рекомендуется, чтобы соотношение длительности проекта в целом ко времени завершения одного элемента было не меньше, чем 10:1. С меньшим соотношением обратная связь будет приходить слишком поздно, когда вы уже продвинетесь слишком далеко, чтобы было безболезненно поменять направление движения.

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

  • Малое время завершения, как и ранняя и частая обратная связь не возникают сами по себе, волшебным образом. Необходимо держать под контролем объём одновременно выполняемой работы (WIP), приблизительно в той же пропорции с общим объёмом работы, как соотношение времён выше.
  • Если ваша организация не способна поставлять желаемую ценность клиенту с требуемым временем завершения (или у вас нет данных, подтверждающих такую возможность, например, свежих данных в виде распределения времени завершения), увы, ваш проектный план нереалистичен. Вам придётся поработать над улучшением возможностей сервиса и создать более реалистичный план. Скорее всего, придётся одновременно обсуждать с заинтересованными сторонами и то и другое и приходить к новым соглашениям.
  • Если среднее время завершения рабочего элемента имеет тенденцию к уменьшению или к увеличению, то ваши прогнозы сроков всего проекта будут иметь те же тенденции. Поэтому регулярно проводите обзоры возможностей ваших сервисов, вовлечённых в выполнение проекта, основанные на постоянно собираемых данных. Это гарантирует, что ваш  план проекта остаётся здоровым либо вы получите ранние сигналы о грядущих проблемах со сроками.


За участие в переводе большая благодарность artnek
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 2

    0
    Появилось впечатление, что на проекте существует какое-то кол-во работ которое не связано никак с потребностями/ценностью для заказчика и странно было видеть WIP в %.
    Что касается применения CFD для отслеживания ценности… Не знаю даже. CFD — отличный визуальный инструмент для отслеживания здоровья kanban-проекта который объясняется за 2 минуты и действительно позволяет по картинке сделать вывод о том что и где подкрутить (например youtu.be/eo2uv8avEsU). То, что описано у Вас я не сильно понимаю как и зачем применять на проектах. Есть доска с ежедневной работой команд(-ы) которую нужно оптимизировать по lead time, wip и т.д., а есть roadmap в котором запланированы значимые для Заказчика проектные достижения. Доска и дорожная карта синхронизируются периодически и рассказываются Заказчику. Зачем их скрещивать не понятно.
      0
      Не совсем так, никаких не несущих ценности работ в проекте нет, конечно.

      Здесь речь о том, что отслеживать метрики и здоровье проекта имеет смысл на уровне того, что в методе называют customer recognizable work items, а не технических задач в командах. CFD в таком случае показывает именно здоровье проекта, в отличие от CFD на уровне задач, которая, конечно, показывает поток, только пользы в нём гораздо меньше. И хорошая СFD на уровне технических задач команды очень мало говорит о здоровье поставки ценности клиенту сервиса.

      Оптимизация на уровне команды, отдельных задач, это локальная оптимизация. А Канбан-метод (и не только он) учит нас, что локальная оптимизация чаще всего не приносит пользы для цепочки поставки ценности. Канбан систему имеет смысл строить end2end и смотреть на систему и поток в целом.

      Видео хорошее для общего понимания. Чтобы научиться видеть паттерны на диаграмме, придётся потренироваться.

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

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое