Что такое обратное делегирование и как от него избавиться

Любому руководителю проектов знакома ситуация, когда ответственность за выполнение задачи ложится исключительно на его плечи: РП согласует каждое решение, отвечает на вопросы, контролирует детали и принимает все решения. Это явление получило название Reverse Delegation Creep. Что это такое и как вернуть самостоятельность команде?

Reverse Delegation Creep в переводе с английского означает «постепенное обратное делегирование».

В отличие от прямого отказа выполнять работу, этот процесс развивается поэтапно. Сотрудники продолжают вести задачи, но все чаще обращаются к шефу, чтобы подтвердить решение, согласовать следующий шаг или разрешить спорную ситуацию. Чем это грозит? Со временем сотрудники становятся зависимыми от руководства и менее самостоятельными, а сам менеджер начинает выполнять свои же поручения.

Впервые похожий механизм подробно описали Уильям Онкен-младший (председатель совета директоров William Oncken Corporation) и Дональд Уосс (президент фирмы William Oncken Company of Texas) в статье «Менеджер и его время, или Кому достанется обезьяна». Она была опубликована в журнале Harvard Business Review еще в 1974 году. Авторы использовали метафору «обезьяны» как следующую задачу или действие, ответственность за которое незаметно перекладывается с исполнителя на руководителя.

Важно не путать это явление с микроменеджментом. В чем ключевые отличия:

1. при микроменеджменте руководитель сознательно контролирует каждое действие сотрудников;
2. при Reverse Delegation Creep инициатива исходит от самой команды: участники регулярно возвращают руководителю право принимать решения, а тот, стремясь ускорить работу или избежать ошибок, постепенно берет всю ответственность на себя.

Почему эффект «обезьяны» появляется почти в каждой команде

Причина № 1. Нет понятных критериев, когда задача считается выполненной и как распределяется ответственность

Разберем на примере:

Разработчик вроде бы закончил работу, но не знает, достаточно ли тестов провел, нужно ли обновить документацию и можно ли действительно присвоить задаче статус «Готово».

В результате появляются вопросы:

«Посмотрите, пожалуйста, все ли нормально, могу закрыть?»

И такая ситуация — не всегда нехватка компетенций. Часто сотрудник просто не понимает, какой результат от него ждут и в каком случае задачу можно считать завершенной.

Более того, разный тип работ требует проверки разных ответственных. В результате команда сама путается в настроенном, как казалось поначалу, процессе.

Причина № 2. Руководитель отвечает быстрее, чем команда успевает подумать

Сотрудник пишет:

«Клиент просит изменить срок. Что делать?»

Менеджер сразу отвечает:

«Перенесите на следующую неделю».

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

Причина № 3. Процессы раскиданы по разным инструментам и сервисам

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

Здесь на «сцену» снова возвращается руководитель, потому что именно он постепенно становится основным источником контекста.

Почему это дорого обходится

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

Проблемы становятся заметны, когда количество подобных запросов начинает расти.

Увеличивается время выполнения задач

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

В результате увеличиваются показатели Lead Time (время от постановки задачи до ее завершения) и Cycle Time (время, которое задание находится непосредственно в работе).

Растет стоимость изменений

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

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

Руководитель сам становится «бутылочным горлышком»

В своей книге «Гол» Элияху Голдратт с примерами разбирает, что производительность всей системы определяется самым медленным участком процесса.

При Reverse Delegation Creep таким ограничением постепенно становится сам руководитель. Команда может работать быстрее, но задачи продолжают накапливаться в ожидании согласования, ответа или окончательного решения.

Команда теряет самостоятельность

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

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

В контексте управления проектами это означает простую вещь: Reverse Delegation Creep — это не проблема отдельного руководителя, а характеристика зрелости процессов. Если большинство решений проходит через одного человека, проект неизбежно теряет скорость, а бизнес — деньги.

6 шагов к управленческому дзену

Надо понимать, что избавиться от обратного делегирования одной просьбой «будьте самостоятельнее» не получится. Причина в процессе, и исправлять нужно именно его.

Шаг 1. Определите, кто отвечает за результат

Первый вопрос, который стоит задать по каждой задаче:

«Кто должен принять окончательное решение?»

Если ответ звучит как «руководитель посмотрит», «потом согласуем» или «решим по ходу», команда неизбежно будет возвращаться за подтверждением каждого следующего шага.

Поэтому еще на старте важно определить:

1. кто отвечает за выполнение;
2. кто принимает решение;
3. кого необходимо уведомить;
4. чье участие потребуется только при возникновении рисков.

Для этого необязательно строить сложные матрицы ответственности. Даже простое разделение ролей по модели RACI уже значительно снизит количество вопросов и итераций.

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

Шаг 2. Сделайте процессы одинаковым для всей команды

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

Например:

1. «В работе»: исполнитель реализует задачу.
2. «На проверке»: код готов, описание заполнено, необходимые материалы приложены;
3. «Готово»: результат устраивает всех заинтересованных, дополнительные действия не требуются.

Чтобы правила начали работать, их нужно зафиксировать. Отличными помощниками здесь станут цифровые инструменты. Например, «Agile-доски» от Directum. Все процессы можно визуализировать и гибко настроить: работа команды становится формализованной, видно, какие задачи находятся в работе, какие ожидают проверки, а какие уже завершены. Так участники смогут самостоятельно отслеживать исполнение, не обращаться к руководителю за очередным уточнением.

Шаг 3. Регламентируйте минимальные требования к переходу между этапами

Даже если правила утверждены, со временем часть требований начинает забываться. Например, к тикету на доске забыли прикрепить спецификацию или не добавили обязательную метку о том, что руководитель проверил промежуточный результат.

В результате карточка задачи возвращается обратно, руководитель начинает выяснять причины, а команда тратит время на повторные обсуждения.

В «Agile-досках» эту проблему можно решить достаточно простым способом — настроить условия перехода тикета между колонками. Например, можно запретить движение задачи дальше, пока не заполнены обязательные поля, не добавлены вложения или не установлена необходимая метка. Такие проверки не заменяют полноценный бизнес-процесс, но исключают большое количество формальных возвратов.

Шаг 4. Используйте «Agile-доску» не только для контроля задач

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

Когда часть тикетов перегружает колонку «На проверке», проблема может быть в том, что:

1. руководитель не успевает проверять задачи;
2. отсутствуют единые критерии приемки;
3. сотрудники предпочитают согласовывать каждое решение вместо того, чтобы принимать его самостоятельно.

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

Шаг 5. Учите команду приносить решения, а не вопросы

Обратимся к книге «Разверните ваш корабль» Дэвида Марке, эксперта по лидерству. Автор предлагает простой принцип: сотрудник должен обращаться к руководителю со своим вариантом решения проблемы.

Например, вместо вопроса «Клиент просит перенести срок. Что делать?» лучше сформулировать предложение следующим образом:

«Предлагаю перенести срок на три дня. Это поможет завершить интеграцию без сокращения объема работ. Риск для следующего этапа отсутствует».

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

Если такая практика становится нормой для всей команды, количество обратного делегирования заметно сокращается.

Шаг 6. Следите за признаками обратного делегирования

Reverse Delegation Creep редко появляется за один день. Обычно его можно заметить значительно раньше по косвенным признакам: тикеты регулярно возвращаются назад, руководитель оставляет комментарий почти к каждой задаче, большинство дел «застревают» в одной колонке, исполнители постоянно уточняют дальнейшие действия.

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

Получается, если шеф становится единственным человеком, через которого проходят практически все решения, проблема, скорее всего, не в сотрудниках. Это сигнал, что процесс требует пересмотра. И чем раньше удастся обнаружить этот момент, тем проще вернуть команде самостоятельность без потери управляемости проекта.