Решение задачи ускорения проектов и снижения затрат на координацию 💎 — OnAgile Consulting

Решение задачи ускорения проектов и снижения затрат на координацию

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

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

Принципы, затронутые в статье, применимы как к выполнению одного проекта, так и к координации нескольких.

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

Потери обычно являются следующими:

  • Задержки при передаче работы между подразделениями и сотрудниками.
  • Задержки из-за блокировок (ожидания) и реприоритизации.
  • Избыточные координационные мероприятия с участием множества сотрудников.
  • Многочисленное переключение контекстов у каждого исполнителя.
  • Потери, связанные с неточной передачей информации между участниками проекта.
  • Повторное выполнение работы из-за изменения условий или низкого качества результата.

В первую очередь, произведем анализ цепочки поставки ценности (Value Stream Map).

Для упрощения — на примере реализации одной задачи:

 

Общее время выполнения задачи составило ~16 дней (эта метрика называется Lead Time), из них на реальное выполнение работы было потрачено ~15 часов.

Эффективное время потока в этом кейсе составило Общее время выполнения (дней 16 * рабочих часов в день 8) / Эффективное рабочее время 15 = 8,5.

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

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

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

Количество одновременно выполняемых задач (Work In Progress, сокращенно WIP) напрямую влияет на время поставки. Согласно закону Литтла: Lead Time (ср) = WIP / Пропускная способность (ср).

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

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

Диаграмма ниже показывает метрику количества выполненных задач (или проектов) при определенном ограничении WIP (1 или 3 одновременно):

 

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

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

Установка лимитов на количество одновременно выполняемой работы (WIP) приводит к тому, что становятся явными причины задержек и блокировок, становится возможным их постепенное устранение. Сокращение WIP, вместе с устранением потерь на ожидание, приводит к сокращению необходимого объема координационных мероприятий и количество бардака в головах у исполнителей.

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

Основные выводы и первые шаги

1. Сформировать Value Stream Map

И найти основные потери на ожидание. Провести диагностику корневых причин и устранить потери, используя Scrum-фреймворк или Kanban-метод. Сократить переключение контекстов там, где это возможно.

2. Выполнить постепенное сокращение Work In Progress

С отслеживанием метрики Lead Time. Сокращение WIP выполнять с установкой лимитов, превышение которых допускать только в исключительных ситуациях.

3. Сформировать команду

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

Интересно узнать подробнее?

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

Еще публикации по Agile в Agile, Scrum, Kanban–метод

Весенняя подборка тематических книг по Agile
Публикация Agile, Scrum, Kanban–метод

Весенняя подборка тематических книг по Agile

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

Секрет головокружительного успеха ZARA
Публикация Мода

Секрет головокружительного успеха ZARA

В 1975 году Амансио Ортега Гаона открыл первый магазин одежды ZARA. В мае 2016 года Forbes оценил стоимость бренда ZARA в 10.7 миллиарда долларов. Каким образом ZARA удалось занять лидирующие позиции в модной индустрии, оставив конкурентов далеко позади?

Agile как основа технологического бизнеса
Публикация Разработка ПО

Agile как основа технологического бизнеса

Бизнес — это деятельность с целью получения прибыли. Технология — это знание, как делать что-либо. Соответственно, технологический бизнес — это знание того, как правильно действовать, чтобы получить прибыль.

3 главных критерия для оценки работы Скрам-мастера
Публикация Agile, Scrum, Kanban–метод

3 главных критерия для оценки работы Скрам-мастера

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

Ближайшие тренинги по Agile и Scrum

С 2004 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!