# Делегирование без провала: что фиксировать

Canonical: https://www.kt-team.ru/blog/adizes-delegation-accountability

Source: https://www.kt-team.ru/blog/adizes-delegation-accountability

21.03.2025

В письме «Standard Operating Procedure for Delegation» Ichak Adizes описывает делегирование не как передачу поручения, а как передачу завершенного решения. Это важное различие. Поручение может быть фразой в чате. Завершенное решение содержит результат, срок, способ выполнения и ответственного.

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

## Главное

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

## Полная задача

- Ожидаемый результат сформулирован так, что его можно принять или отклонить.
- Срок задан явно: дата, событие или критерий готовности, а не «как получится».
- Способ выполнения ограничен там, где есть бюджет, безопасность, архитектура, юридические требования или зависимость от других команд.
- Ответственный назван, а если нужна совместная работа - названы участники и границы их вклада.
- Фиксация лежит в системе, где ее можно проверить, а не только в памяти участников.

## Право спросить и право не согласиться

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

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

## Что делать, когда план ломается

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

Это не просьба о прощении. Это ранняя управленческая информация. Чем раньше она появляется, тем дешевле поменять срок, объем, способ, состав участников или приоритет.

## Почему это инженерная практика

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

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

## Вывод

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

## Источники

- Ichak Adizes, Standard Operating Procedure for Delegation, 21.03.2025: https://mailchi.mp/191e913142f7/on-building-trust-7223044
- Ichak Adizes, When Can One Be Held Accountable?, 07.03.2025: https://mailchi.mp/1acee9d5de1d/when-can-one-be-held-accountable