Решение задачи ускорения проектов и снижения затрат на координацию 💎 — 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

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

Публикация
Agile, Scrum, Kanban–метод
3 критерия для быстрой оценки работы Скрам-мастера
Кому: * Менеджерам и руководителям, которые хотят быть в курсе выстраивания новых процессов в компании. * Скрам-мастерам на старте карьеры и в начале работы в новой компании.
Публикация
Agile, Scrum, Kanban–метод
Мифы об Agile. «Мы стали проводить время в бесконечных митингах»
Нередко от Agile-команд можно услышать недовольство о нехватке времени, поскольку большую часть времени люди стали проводить в «бесконечных встречах».
Публикация
Agile, Scrum, Kanban–метод
Анализ стейкхолдеров проекта
Несмотря на то, что в базовом варианте работа agile-команды не предполагает такую процедуру как Управление проектом (как и саму роль менеджера проекта), часто бывает полезно применять хорошие практики, наработанные в рамках стандартных процедур управления проектами. Одна из них — анализ стейкхолдеров проекта.

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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