Делегирование в ИТ-проекте: 7 уровней автономии по Апелло
«Хотите, чтобы что-то было сделано правильно — сделайте это сами»
Тимлид задерживается на работе допоздна, проверяет каждую строчку кода, согласовывает каждый отчёт, принимает каждое решение. Его девиз: «Хотите, чтобы что-то было сделано правильно — сделайте это сами». Через полгода он выгорает, команда не развивается, проект стоит. Знакомая картина?
Руководители растут из сильных специалистов, они отлично понимают технические детали, и это их ловушка. Вместо того чтобы управлять, они начинают контролировать. Контроль масштабируется линейно, управление масштабируется системно. Разница между ними критическая, и начинается она с делегирования.
Почему ИТ-руководители не делегируют — три страха
Исследования показывают: 41% руководителей не делегируют, потому что не уверены, что сотрудники справятся, а 19% — потому что задачу проще выполнить самому. В ИТ этот страх усугубляется — менеджеры выросли из инженеров, они знают, как делать, и когда видят, что сотрудник делает не так, как сделали бы они, у них руки чешутся «поправить».
Страх «Сделают хуже» — руководитель перепроверяет каждую задачу. Решение: признайте, что «иначе» не значит «хуже», разные подходы могут быть равно эффективны.
Страх «Обучу, а они уйдут» — руководитель копит знания в себе. Решение: лучше, чтобы они ушли обученными и принесли пользу, чем ушли необученными и оставили вас без экспертизы.
Страх «Сделаю быстрее сам» — руководитель берёт задачи на себя. Решение: в краткосрочной перспективе — да, быстрее, но в долгосрочной вы растите не команду, а свою перегрузку.
«Эффект бумеранга делегирования» — задача возвращается обратно к руководителю, потому что он не дал полномочий и не готов отпустить.
Семь уровней делегирования по Юргену Апелло
Юрген Апелло предложил простую шкалу — семь уровней, от полного контроля до полной автономии.
Уровень 1. Сказать (Tell). Руководитель даёт чёткое указание, обсуждения нет. «Завтра в 10:00 релиз в прод. Точка». Для новичков, критичных задач, инцидентов. Риск: если использовать слишком часто — команда перестаёт думать.
Уровень 2. Продать (Sell). Руководитель объясняет, почему нужно сделать именно так. «Объясняю, почему мы переходим на Agile-доски — это ускорит наши коммуникации». Когда важно, чтобы команда поняла логику решения. Риск: занимает больше времени, чем просто «сказать».
Уровень 3. Посоветоваться (Consult). Руководитель собирает мнения, но решение принимает сам. «Собираю мнения по выбору технологии, но решение принимаю сам». Когда важна экспертиза команды, но финальная ответственность на вас. Риск: может создать иллюзию демократии — команда может подумать, что её мнение влияет на решение, а это не так.
Уровень 4. Согласовать (Agree). Коллегиальное решение, руководитель ещё может наложить вето. «Давайте вместе решим, какой стек использовать. Я тоже голосую». Когда команда достаточно зрелая, но вы ещё хотите сохранить контроль. Риск: команда может не принять решение, если вы используете вето слишком часто.
Уровень 5. Посоветовать (Advise). Руководитель рекомендует, но решение за командой. «Я рекомендую кеширование. Решение за вами». Начинается настоящее делегирование, команда готова брать ответственность. Риск: команда может не последовать вашему совету, и это нормально.
Уровень 6. Спросить (Inquire). Команда действует автономно, информирует о результате. «Как прошло внедрение? Доложите результат в пятницу». Команда полностью компетентна в этом вопросе. Риск: если ситуация изменится, команда может не заметить этого вовремя.
Уровень 7. Делегировать (Delegate). Команда принимает решения полностью самостоятельно. «Вы сами решаете, как это сделать. Я не вмешиваюсь». Команда — эксперты в этой области, это их зона ответственности. Риск: вы теряете контроль, но это и есть цель делегирования.
Как применять уровни в ИТ-команде
Не нужно выбирать один уровень для всех задач — разные зоны требуют разного подхода. Выбор технологии для нового модуля — уровень 4 «Согласовать», архитектор и разработчики — эксперты, но ответственность на вас. Назначение ответственного за код-ревью — уровень 3 «Посоветоваться», тимлид знает сильные стороны команды лучше всех. Деплой в прод в пятницу вечером — уровень 1 «Сказать», высокий риск, не обсуждается. Архитектурное решение — уровень 5 «Посоветовать», архитектор — эксперт, но вы можете дать рекомендацию. Детали реализации интерфейса — уровень 7 «Делегировать», фронтенд-разработчик — эксперт в своей области.
Двигайтесь по уровням постепенно: новичок (джуниор) — уровень 1–2 (Сказать, Продать), специалист с опытом (мидл) — уровень 3–4 (Посоветоваться, Согласовать), эксперт (сеньор) — уровень 5–7 (Посоветовать → Делегировать). Важно: слишком низкий уровень для квалифицированного специалиста убивает мотивацию, а слишком высокий для новичка порождает хаос.
Что делать, если вы застряли на контроле
Возьмите одну задачу, которую вы обычно делаете сами. Определите уровень делегирования — начните с уровня 4 «Согласовать». Чётко сформулируйте задачу по SMART и скажите: «Ты отвечаешь за результат. Финальное решение за тобой». Не вмешивайтесь, даже если он делает не так, как сделали бы вы. Через месяц поднимите уровень до 5, ещё через месяц — до 6.
Что в понедельник утром
Составьте список задач, которые вы делаете сами. Отметьте, какие из них можно делегировать. Для каждой задачи определите уровень автономии (1–7). Назначьте ответственного. Проведите встречу, где объясните задачу и уровень полномочий.
Заключение
Семь уровней делегирования — от «Сказать» до «Делегировать». Главное правило: делегируйте результат, а не способ его достижения. Руководитель, который делегирует, вырастает из исполнителя в стратегического лидера и перестаёт работать по ночам.
На воркшопах курса «Мастер управления IT-проектами» мы разбираем ваши реальные задачи и выбираем уровень делегирования для каждого члена команды. Подробнее о курсе →