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

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

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

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

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

Влияние на скорость выполнения проектов глобально можно разделить на 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. Сформировать команду

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

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

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

Вопросы и ответы по теме

Почему опытные руководители ограничивают количество одновременных задач вместо увеличения ресурсов?

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

Как Value Stream Mapping раскрывает скрытые возможности ускорения проектов?

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

Какой неожиданный фактор больше всего тормозит выполнение проектов?

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

Как избежать проектного хаоса без внедрения сложных процессов?

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

Почему успешные компании переходят от максимальной загрузки ресурсов к ограничению параллельных задач?

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

Как определить реальную эффективность процессов в вашем проекте?

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

Хотите системно изучить гибкие методологии?

Профессиональный сертификационный тренинг по Agile и Scrum

24 - 26 сентября 2025
Узнать больше

Сертифицированный Владелец продукта в Agile

01 - 03 октября 2025
Узнать больше

Сертифицированный Delivery и Project менеджер в Agile

22 - 24 октября 2025
Узнать больше

Полный календарь тренингов

Перейти к расписанию

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

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

Внедрение Scrum фреймворка - что происходит, когда методология встречается с реальностью

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

Применение AI для улучшения управления в проектной компании
Кейс Agile, Scrum, Kanban–метод

Применение AI для улучшения управления в проектной компании

Искусственный интеллект в проектном менеджменте, которому можно делегировать контроль статуса проектов, и применение Scrum в проектной организации.

Секрет успеха ZARA: часть 2
Публикация Мода

Секрет успеха ZARA: часть 2

В первой части мы рассказали, как Lean-подход позволяет ZARA свести запасы к минимуму и производить одежду только в том объеме, который требуется.

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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