Решение задачи ускорения проектов и снижения затрат на координацию 💎 — 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, Scrum, Kanban–метод
Как оценивать сроки завершения работы
Почему так сложно верно оценивать работы по созданию нового продукта — и какими способами можно улучшить точность оценки, не делая это процесс сложнее.
Публикация
Agile, Scrum, Kanban–метод
Материалы для самостоятельного изучения Agile
Мы собрали для вас список самых важных книг на тему Agile и всего того, что пригодится на нелегком пути трансформации. Они могут вам самостоятельно изучить подход, а также закрепить и расширить полученные на тренингах знания.
Публикация
Agile, Scrum, Kanban–метод
Product owner и скрам-мастер: почему важно разделять эти роли
При внедрении Scrum появляются две новые роли: владелец продукта и скрам-мастер. И часто бывает, что на них решают назначить одного человека — обычно это менеджер проекта или тимлид. Но это не лучшее решение.
Публикация
Agile, Scrum, Kanban–метод
Покер планирования - совместная оценка задач командой
Planning poker — техника командной оценки задач в относительных единицах. Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning».

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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