Как правильная структура сократила сроки проекта
Когда проект начинает отставать, первая реакция обычно связана со скоростью.
Нужно работать быстрее.
Быстрее согласовывать.
Быстрее выполнять задачи.
Быстрее принимать решения.
Но в реальности многие проекты тормозят не потому, что люди работают медленно.
Они тормозят потому, что сама структура работы заставляет их постоянно ждать друг друга.
Именно поэтому иногда лучший способ ускорить проект — не требовать от команды больше скорости, а изменить архитектуру взаимодействия.
Проблема выглядела как низкая производительность
Представим кросс-функциональный проект.
В нём участвуют бизнес, HR, IT, аналитика и обучение.
У каждой функции своя зона ответственности.
Свои руководители.
Свои приоритеты.
Свои сроки.
На старте всё выглядит логично.
Бизнес формирует потребность.
HR описывает процесс.
IT получает техническое задание.
Аналитики готовят данные.
Обучение разрабатывает материалы.
На бумаге работа распределена.
Но на практике проект начинает двигаться рывками.
Одна команда заканчивает свой этап и ждёт следующую.
Следующая обнаруживает, что информации недостаточно.
Документы возвращаются на доработку.
Возникают дополнительные согласования.
Появляются новые вводные.
Сроки начинают постепенно расползаться.
При этом каждая функция может честно говорить:
«С нашей стороны задержки нет».
И это может быть правдой.
Проблема находится не внутри отдельных команд.
Она находится между ними.
Структура была построена вокруг функций, а не результата
Это типичная организационная ловушка.
Работу делят по профессиональным зонам ответственности.
Каждая функция оптимизирует собственный этап.
Но никто не отвечает за движение результата через всю цепочку.
Проект начинает напоминать эстафету.
Одна команда передала работу другой и считает свою часть завершённой.
Следующая принимает её не сразу.
Потом задаёт вопросы.
Работа возвращается назад.
Каждая передача создаёт ожидание.
А чем больше таких переходов, тем длиннее становится общий цикл.
В итоге проект может иметь сильных специалистов, хорошее финансирование и поддержку руководства, но всё равно двигаться медленно.
Потому что локальная эффективность не компенсирует плохую структуру взаимодействия.
Главным ограничением оказалось время ожидания
Когда начали смотреть не на загрузку сотрудников, а на движение самой работы, картина изменилась.
Выяснилось, что задача могла выполняться два дня.
Но пять дней ждать согласования.
Ещё три — ответа другой функции.
Затем возвращаться на корректировку.
После этого снова вставать в очередь.
То есть значительная часть календарного срока проекта состояла вовсе не из работы.
Она состояла из ожидания.
И это принципиально важное различие.
Сокращать два дня непосредственной работы до полутора почти бессмысленно, если между этапами остаётся десять дней ожидания.
Системное мышление как раз требует смотреть не только на отдельные действия, но и на связи между элементами процесса, искать узкие места и работать с самим потоком, а не только с локальной проблемой. сист мышление (3) (1)
Первое изменение — работа перестала передаваться по цепочке
Вместо последовательного движения начали формировать кросс-функциональный контур.
Не:
бизнес закончил → передал HR → HR закончил → передал IT.
А:
бизнес, HR и IT подключаются к задаче раньше и совместно уточняют решение ещё до начала основной реализации.
Это кажется небольшим изменением.
Но оно резко сокращает количество возвратов.
IT заранее видит технические ограничения.
Бизнес быстрее понимает стоимость своих требований.
HR может скорректировать процесс до того, как он превратился в техническое задание.
Аналитики заранее понимают, какие данные понадобятся.
Работа перестаёт путешествовать между функциями как документ.
Она становится общим объектом нескольких участников.
Второе изменение — появился единый владелец результата
До перестройки у каждого участка был свой ответственный.
Но за общий результат отвечали фактически все.
А значит — никто.
При возникновении задержки начиналось привычное выяснение:
кто сейчас должен сделать следующий шаг;
у кого находится задача;
кто должен эскалировать проблему;
кто имеет право изменить приоритет.
Поэтому появился единый владелец инициативы.
Не человек, который выполняет всю работу.
И не руководитель всех участников.
А тот, кто отвечает за прохождение результата через систему целиком.
Его задача — видеть зависимости, обеспечивать принятие решений и не позволять работе зависать между функциями.
Это соответствует более зрелой логике проектного управления, где ключевыми становятся не только отдельные задачи, но и координация коллективных усилий, взаимодействие между ролями и выбор подходящей модели управления под конкретный контекст. PMBOK7
Третье изменение — убрали лишние уровни согласования
Оказалось, что часть задержек вообще не была связана со сложностью решений.
Они возникали потому, что любое изменение проходило через несколько уровней управления.
Исполнитель готовит решение.
Руководитель проверяет.
Другой руководитель согласовывает.
Функция подтверждает.
Проект возвращается к исполнителю.
Каждая отдельная точка выглядит разумно.
Но вместе они создают огромный временной лаг.
После анализа часть решений перенесли на уровень самой команды.
Были зафиксированы границы:
что команда может решать самостоятельно;
что требует согласования;
что действительно должно подниматься выше.
В результате количество решений не уменьшилось.
Но сократилось количество людей, через которых они должны пройти.
И это сразу повлияло на скорость.
Четвёртое изменение — зависимости стали видимыми
До этого каждая команда видела в основном собственный план.
Поэтому проблема часто становилась очевидной слишком поздно.
Одна функция меняла срок — и только через неделю выяснялось, что это блокирует ещё две команды.
После перестройки появилась единая картина зависимостей.
Не просто список задач.
А понимание:
что должно произойти раньше;
какая команда кого блокирует;
какие решения являются критическими;
где находится ближайшее ограничение.
Это изменило саму логику управления.
Вместо вопроса:
«Все ли команды выполняют свои планы?»
появился другой:
«Что сейчас ограничивает движение всего проекта?»
Именно этот вопрос оказался значительно полезнее.
Люди не стали работать быстрее
Это, пожалуй, самый интересный результат.
Сотрудники не начали печатать быстрее.
Не стали работать больше часов.
Не получили дополнительной мотивации.
Их индивидуальная производительность практически не изменилась.
Но проект начал двигаться быстрее.
Потому что исчезла часть потерь между действиями.
Меньше ожиданий.
Меньше возвратов.
Меньше передач.
Меньше согласований.
Меньше ситуаций, когда задача просто лежит и ждёт чьего-то решения.
То есть ускорили не людей.
Ускорили систему.
Почему структура часто важнее мотивации
Когда сроки начинают ухудшаться, руководителю психологически проще работать с поведением сотрудников.
Попросить ускориться.
Установить дополнительный KPI.
Поставить более жёсткий дедлайн.
Усилить контроль.
Но если причина находится в архитектуре работы, давление почти ничего не меняет.
Люди начинают быстрее выполнять свой участок.
А затем всё равно ждут.
Более того, давление может даже ухудшить ситуацию.
Каждая функция начинает ещё сильнее оптимизировать собственные показатели.
Передавать работу дальше как можно быстрее.
Формально этап завершён.
А качество входящего результата для следующей команды ухудшается.
Возвратов становится больше.
Вся система замедляется.
Поэтому сильное управление требует различать две ситуации:
сотрудник действительно выполняет работу слишком медленно;
или система заставляет нормальную работу двигаться медленно.
Это совершенно разные проблемы.
Правильная структура уменьшает необходимость в управлении
После перестройки произошло ещё одно важное изменение.
Стало меньше эскалаций.
Когда владелец результата понятен, зависимости прозрачны, а полномочия определены, значительная часть вопросов решается без участия вышестоящих руководителей.
Это хороший показатель качества структуры.
Плохая архитектура постоянно требует внимания менеджмента.
Хорошая — позволяет большей части работы проходить самостоятельно.
Именно поэтому зрелое управление связано не только с контролем сроков и ресурсов, но и с проектированием контуров управления, прозрачностью, распределением владельцев, управлением зависимостями и снижением организационного хаоса. Роль
Срок проекта — это свойство системы
Мы привыкли думать, что срок определяется объёмом работы.
Но в сложных проектах это только часть картины.
На срок также влияют:
количество передач между командами;
скорость принятия решений;
число согласований;
конфликтующие приоритеты;
очереди;
зависимости;
качество входящей информации.
Поэтому сокращение срока часто начинается не с попытки выполнить каждую задачу быстрее.
Оно начинается с уменьшения количества препятствий между задачами.
Главный вывод
Проект ускорился не после того, как людей попросили работать быстрее.
Он ускорился после того, как изменилась структура.
Появился единый владелец результата.
Команды стали раньше взаимодействовать друг с другом.
Зависимости сделали прозрачными.
Часть решений спустили вниз.
Лишние согласования убрали.
И количество времени, которое работа проводила в ожидании, сократилось.
Это важный принцип управления сложными проектами:
скорость системы определяется не только скоростью её элементов, но и качеством связей между ними.
Поэтому, когда проект снова начинает отставать, полезно не сразу спрашивать:
«Кто работает недостаточно быстро?»
Иногда гораздо сильнее другой вопрос:
«Что в нашей структуре заставляет работу двигаться медленно?»
Данный материал носит исключительно ознакомительный и дискуссионный характер и отражает личное мнение автора.
