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

Product Coach

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

Опубликовано

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

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

Влияние на скорость выполнения проектов, глобально, можно разделить на 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 в телекоме: перевыполнение плана на 45%
Командная работа как залог успеха и опыт внедрения Agile, готовый к масштабированию.
Публикация
Разработка ПО
Материалы для самостоятельного изучения Agile
Мы собрали для вас список самых важных книг на тему Agile и всего того, что пригодится на нелегком пути трансформации. Они могут вам самостоятельно изучить подход, а также закрепить и расширить полученные на тренингах знания.
Публикация
Разработка ПО
Agile как основа технологического бизнеса
Бизнес — это деятельность с целью получения прибыли. Технология — это знание, как делать что-либо. Соответственно, технологический бизнес — это знание того, как правильно действовать, чтобы получить прибыль.
Публикация
Разработка ПО
Что такое Непрерывная поставка (Continuous Delivery)?
При разработке программного обеспечения в стремительно меняющемся мире, часто возникает вопрос, как оставаться конкурентноспособным на рынке?

Мы помогаем организациям с 2004 года

Свяжитесь с нами

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

Executive Agile Coach & Founder

+7 495 221 87 39

dmitry@onagile.ru

Telegram канал об Agile и гибких организациях: https://t.me/agilethinking