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

21.03.2025 В письме «Standard Operating Procedure for Delegation»

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

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

На деле это был незакрытый управленческий контракт.

Сильная команда отличается не тем, что никогда не ошибается в оценке.

Она отличается короткой петлей обратной связи.

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

Это ранняя управленческая информация.

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

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

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

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

Если передали без права спорить, риск уходит в код, а возвращается инцидентом.

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

Это снижает TTU не за счет давления, а за счет меньшего числа переделок.