Делегирование без самообмана: чеклист владения

Когда использовать

Используйте этот чеклист, когда тимлид хочет передать часть работы команде или конкретному человеку, но есть риск попасть в одну из двух крайностей:

• микроменеджмент: задача передана, но все решения остаются у тимлида;
• сброс ответственности: человеку отдали работу без контекста, полномочий и поддержки.

Материал помогает договориться не только о том, кто делает задачу, но и о том, какой контур владения передается вместе с ней.

Главная проверка

Передача работы считается делегированием только если человек понимает:

• зачем нужна работа;
• что он может решить сам;
• где граница его полномочий;
• когда нужно позвать тимлида или другого владельца;
• как будет проверяться результат;
• какие последствия нельзя принимать в одиночку.

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

1. Назвать контур владения

Запишите коротко:

Что передаем:
Кому:
Зачем это нужно:
Какая часть результата теперь у человека:
Какая часть остается у тимлида:

Плохая формулировка:

Передаю интеграционную задачу.

Лучше:

Передаю владение первичным разбором интеграционной задачи:
человек сам собирает открытые вопросы, риски, критерии приемки и варианты решения,
а тимлид подключается на выборе trade-off'ов и согласовании внешних зависимостей.

2. Выбрать уровень самостоятельности

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

3. Передать контекст

Проверьте, что человек получил не только задачу, но и смысл:

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

Если контекст остается в голове тимлида, самостоятельность будет имитацией.

4. Передать право на решение

Отдельно назовите, что человек может решать без согласования:

• порядок разбора задачи;
• выбор локального решения;
• формат фиксации результата;
• коммуникацию с соседней ролью;
• остановку работы на уточнение;
• подъем риска до тимлида, продукта, аналитика, QA или внешней стороны.

И отдельно назовите, что нельзя решать одному:

• изменение срока, если он обещан наружу;
• изменение объема, если оно влияет на пользователя или договоренность;
• принятие риска безопасности, денег, персональных данных или внешнего SLA;
• скрытый отказ от приемки, логирования, диагностики или rollback-варианта.

5. Договориться о проверке

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

Минимум:

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

Плохой сигнал: тимлид передал работу, но проверяет каждое сообщение, каждую формулировку и каждое локальное решение.

Хороший сигнал: человек действует внутри границ, а тимлид проверяет только смысл, риск и последствия.

6. Оставить канал поддержки

Самостоятельность не означает “разбирайся сам”.

Договоритесь заранее:

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

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

7. Проверить антипаттерны

Стоит насторожиться, если:

• человек получил задачу, но не понимает, зачем она нужна;
• тимлид остается единственным контактом со стейкхолдером;
• решения принимаются человеком, но ответственность за последствия не названа;
• любое отклонение возвращается к тимлиду как к диспетчеру;
• человек отвечает за результат, но не может обсуждать объем, срок или качество;
• риск можно поднять только когда уже поздно;
• после выполнения никто не фиксирует, чему команда научилась.

Шаблон договоренности

## Что делегируем

Работа:
Владелец:
Зачем это нужно:

## Граница владения

Человек решает сам:
Нужно согласовать:
Нельзя решать одному:

## Контекст

Владелец результата:
Затронутые роли или системы:
Известные ограничения:
Принятые решения:

## Проверка

Критерий результата:
Промежуточная точка:
Что фиксируем письменно:

## Эскалация

Когда звать тимлида:
Когда останавливать работу:
Кого еще подключать:

Короткий итог

Делегирование работает, когда вместе с задачей передается контекст, граница, право на решение и понятная проверка.

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