Как стать автором
Обновить

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

Время на прочтение3 мин
Количество просмотров7K
Автор оригинала: Alexei Zheglov

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


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

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

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


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


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

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

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

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

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

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

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

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

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


За участие в переводе большая благодарность artnek
Теги:
Хабы:
Всего голосов 5: ↑3 и ↓2+5
Комментарии2

Публикации

Истории

Работа

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань