Делегирование и распределение ответственности: уровни, RACI, контрольные точки

Делегирование — одна из самых сложных вещей для всех, от руководителя до рядового специалиста, и первая трудность даже не в навыке, а в определении. Делегировать — значит распределять ресурсы, общаться и искать подход к человеку, а не избавляться от лишних задач. Разница видна по вопросу, который менеджер задаёт себе перед передачей: «что мне надоело?» — это разгрузка, «где мой час стоит дороже всего?» — это делегирование.

Статья — про распределение ответственности внутри проекта: кто за что отвечает по ролям и артефактам, как это записывается и проверяется. Смежная тема — делегирование как инструмент роста конкретного человека (контракт делегирования, как не забрать задачу обратно, цена делегирования) — разобрана в «Делегирование: что отдавать и как не забрать обратно» из трека инженерного лидерства, и здесь мы её сознательно не повторяем: там — про человека, здесь — про проектную рамку (роли, матрицы, полномочия, контрольные точки, эскалация).

1. Почему это трудно именно бывшему сильному инженеру

Многие люди, оказавшиеся в роли менеджера проекта, никогда не учились распределять обязанности: работа досталась им потому, что они прекрасные технические специалисты. От них больше не требуется решать технические задачи — требуется, чтобы задачи решали другие, и в этой роли им крайне неуютно. Ключевая мысль, которую обычно пропускают: роль не расширилась, а сменилась. Инженеру кажется, что к прежним обязанностям добавили новые — отсюда попытка делать и то и другое, отсюда переработки. На деле старые обязанности передали кому-то ещё, а новые (границы, планирование, коммуникация, ответственность за результат) заняли всё место, и пока смена не осознана, самый естественный ход — вернуться туда, где комфортно, и написать код самому. Вторая причина проще и честнее: менеджерам нравится техническая работа. Это не порок, но это мотив, который нужно назвать вслух, иначе он маскируется под «никто не сделает это лучше меня»; правильный ответ — найти способ оставаться в курсе дел, не выполняя работу самому. Третья трудность самая неприятная:

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

В английской терминологии это разные слова: authority передаётся, accountability — нет. Единственный способ «передать ответственность» — сменить владельца целиком, вместе с правами и последствиями, то есть перестать быть тем, с кого спрашивают; в проекте такое бывает (передача модуля другой команде), но это не делегирование, а перераспределение ролей.

Закон сравнительного преимущества. Утверждение «никто не сделает это лучше меня» часто верно — и при этом нерелевантно. В экономике специализируются не там, где вы лучше других в абсолютном выражении, а там, где преимущество максимально относительно альтернативной стоимости вашего времени (comparative advantage). Практический перевод: даже если человек сделает задачу хуже вас, отдать её стоит, если ваше время даст больший эффект в другом месте. Вы правите баг за 2 часа, инженер — за 5; за те же 2 часа вы разблокируете интеграцию со смежниками, чего кроме вас не сделает никто, и это спасёт команде неделю: обмен трёх часов чужого времени на неделю командного — не близкое решение. Оговорка: «хуже» не значит «ниже порога приёмки», иначе разница уйдёт не в часы, а в дефекты. Ловушка симметрична — тот же расчёт запрещает отдавать работу, если освободившийся час не имеет более ценного применения.

2. Три разных объекта делегирования

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

Три уровня требуют разной подготовки. Делегируя задачу, вы обязаны точно знать, чего хотите; делегируя решение — назвать границы (бюджет, сроки, что нельзя трогать, кого нужно спросить); делегируя ответственность за результат — обеспечить полномочия под неё, иначе получается самая деморализующая конструкция: ответственность без полномочий, когда человек отвечает за срок, но не может ни изменить объём, ни привлечь людей, ни сказать «нет» смежникам. Ответственность и полномочия передаются одним пакетом; разрыв в любую сторону ломает конструкцию.

3. Что делегировать не стоит

Лучше всего для передачи подходят задачи с хорошо продуманной процедурой: они выполнялись раньше, есть уверенность, что ситуация будет развиваться примерно как хочется, и есть с чем сравнить результат. Плохие кандидаты — две категории. Задачи с неопределённым результатом: не «сложные», а те, где непонятно, как выглядит успех; их не делегируют, их исследуют вместе, а делегируют уже следующий шаг. И задачи, для которых вы сами не сформулировали, что именно хотите получить: если вы не можете сказать сотруднику, что должно получиться, как он это узнает? Такая передача возвращается в виде «он сделал не то». В проектной рамке к этому добавляется список того, что не делегируется в принципе — не потому что исполнитель не справится, а потому что передача разрушает конструкцию управления.

И отдельная строка: если существует задача, которую вы должны решить самостоятельно, — решайте её сами. Половина проблем снимается способностью честно признать, что эту работу передавать нельзя.

4. Дерево решения: отдавать ли и на каком уровне

Порядок вопросов важнее самих вопросов: компетенция исполнителя проверяется после двух вопросов о вас самих — сформулирован ли результат и не относится ли задача к неделегируемому. Перевёрнутый порядок — самая частая ошибка: менеджер начинает с «кому бы отдать», а не с «что я вообще хочу». И «сделать самому» законно только в одном сочетании — критичная задача при отсутствии компетентных людей, причём временно: если ситуация повторяется, проблема не в делегировании, а в топологии команды и bus-факторе.

5. Уровни делегирования: две шкалы и мост между ними

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

1. «Дайте мне знать» — подберите факты и предоставьте их мне, чтобы я мог сделать следующий шаг.
2. «Покажите, как это сделать» — на основе фактов разработайте альтернативные варианты действий.
3. «Сделайте, что я сказал» — всё перечисленное выше плюс готовность реализовать выбранное мной решение.
4. «Действуйте, пока я вас не остановлю» — предложите, что надо делать, и, если я не остановил, делайте.
5. «Как дела?» — вот задача: проанализируйте, действуйте и сообщите мне, что произошло, когда сделаете.
6. «Действуйте самостоятельно» — я ничего не хочу слышать, пока проблема не будет решена.

Главное не в самих ступенях, а в том, что уровень не угадывают, а проговаривают и согласовывают заранее: нужно не только понять, какой уровень приемлем, но и договориться с человеком, что работа идёт именно на этом уровне. Дешевле всего это стоит в момент постановки задачи и дороже всего — когда выяснилось, что один считал уровень третьим, а другой шестым. Современный аналог шкалы — Delegation Poker из Management 3.0 Юргена Аппело (management30.com), семь уровней: 1 Tell (решил и сообщаю), 2 Sell (решил и объясняю почему), 3 Consult (спрашиваю мнение, решаю сам), 4 Agree (решаем вместе), 5 Advise (высказываю мнение, решаете вы), 6 Inquire (решаете вы, потом рассказываете), 7 Delegate (решаете вы, рассказывать не нужно). Сопоставление двух шкал — самое полезное, что можно с ними сделать: старый словарь встречается в проектной документации, новый — в командной практике, и люди спорят, не подозревая, что говорят об одном.

Две находки из таблицы стоят всего сравнения. Первая: классические 2 и 3 идут не по порядку, потому что шкалы мерят разные оси — классическая измеряет самостоятельность в действии, Delegation Poker измеряет, кто принимает решение; на третьем классическом уровне человек делает больше, но решает меньше. Вторая: уровня «решаем вместе» в классике нет вовсе, а в реальном проекте архитектурные и приоритетные решения принимаются именно так — и отсутствие слова для частого режима приводит к тому, что совместное решение выдают за чьё-то единоличное, а потом ищут виноватого. Delegation Board превращает игру в артефакт: строки доски — не задачи, а области решений, и уровень задаётся на область, а не на разовое поручение.

Доска решает конкретную проблему: делегирование перестаёт быть свойством настроения менеджера. Пока уровень не записан, он колеблется — в спокойный день шестой, перед релизом второй; записанный уровень тоже можно менять, но изменение становится видимым событием с объяснением.

6. RACI: кто за что отвечает по ролям

Уровни отвечают на вопрос «сколько свободы у исполнителя». Матрица ответственности (RAM) отвечает на другой: «кто из ролей участвует в этой активности и в каком качестве». Самый распространённый вариант — RACI: R — Responsible (кто делает работу, может быть несколько), A — Accountable (с кого спросят за результат и кто подписывает приёмку, ровно один на строку), C — Consulted (с кем советуются до решения, двусторонняя связь), I — Informed (кого уведомляют после, односторонняя связь). Правило «ровно один A» держит всю конструкцию: матрица существует, чтобы в спорный момент не искать, кто решает, а два A означают, что решать будут двое — то есть никто.

Матрицу читают строками, а не столбцами. Строка «архитектурное решение» говорит: делают тимлид и разработчики, отвечает тимлид, аналитик и эксплуатация обязаны быть спрошены до решения, спонсор узнаёт после. Строка «решение о релизе» отражает нормативную картину, где go / no-go — прерогатива спонсора; в зрелой продуктовой команде та же строка выглядит иначе: A у владельца продукта или тимлида, а спонсор задаёт допуск («релизьте сами, пока не затрагиваются деньги клиентов»). Это не нарушение RACI, а управление по отклонениям из PRINCE2: полномочия делегируются вниз ровно до границы допуска, и только выход за неё поднимает решение наверх. Сама матрица — не изобретение Agile-эпохи: в PMBOK она входит в план управления ресурсами и связывается с WBS (строки — пакеты работ из структуры декомпозиции, столбцы — оргструктура), а PRINCE2 определяет роли жёстче и заранее — Project Board, Executive как единственный владелец решения, Project Manager, Team Manager, Project Assurance; это RACI, вшитый в методологию, где A расписан на уровне свода, а не проекта. Патологии матрицы:

Родственники RACI. RASCI добавляет S — Support и отделяет тех, кто выделяет ресурс, от тех, кто советует (полезно, когда работу делает одна команда, а инфраструктуру даёт другая). CAIRO (RACIO) добавляет O — Out of the loop, явно фиксируя, кого не привлекают: в больших организациях это снимает и обиды, и лишние согласования. RAPID (Bain: Recommend, Agree, Perform, Input, Decide) и DACI (Driver, Approver, Contributor, Informed — Atlassian Playbook) устроены иначе: RACI распределяет работу, а RAPID и DACI — решения; в RAPID буква D означает того, кто решает, а A — того, чьё согласие обязательно, то есть право вето («Who Has the D?», HBR 2006). Проекту нужны оба класса матриц; механику самих решений разбирает следующая глава.

7. Постановка задачи: делегирование начинается с формулировки

Половина неудачных делегирований проваливается не в исполнении, а в момент передачи. Классический набор правил постановки: выберите нужного человека (не каждый в состоянии выполнить любую задачу); объясните, почему задача важна — это увеличивает ответственность за поручение и позволяет исполнителю принимать разумные решения при отклонениях; попросите его самому оценить время и ресурсы — до того, как он согласится (названная им оценка работает иначе, чем спущенная сверху); разрешите приходить с вопросами явно и вслух, иначе вопрос превратится в догадку; разрешите отказаться — чем раньше вы узнаете, что человек не справится, тем лучше; заранее назначьте контрольные точки вместо мелочной опеки; оценивайте выполнение в ходе и после, а не только в конце.

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

# Задача: перевести отчёт по марже на новый источник данных

## Зачем (проблема, а не решение)
Финансы сводят маржу вручную 6 часов в конце месяца, расхождение с биллингом до 3%.
Ошибка в отчёте один раз уже привела к неверному решению по скидкам.

## Результат (как я пойму, что готово)
- Отчёт собирается из витрины `dwh.margin_daily`, без ручных шагов.
- Расхождение с биллингом на контрольном месяце — менее 0,5%.
- Финансы подтвердили приёмку на данных за март (Иванова, письменно).

## Уровень делегирования и границы полномочий
Уровень 5 «действуй, пока я не остановлю» / Advise — способ решения твой.
Можно: менять расчёт внутри витрины, привлекать аналитика до 8 часов, править дашборд.
Нельзя без согласования: менять схему витрины и контракт API биллинга, трогать
прод-таблицы биллинга, обещать финансам сроки по другим отчётам.

## Срок и почему он такой
До 28 марта. Причина не произвольная: закрытие квартала 31 марта, отчёт нужен для него.

## Контрольные точки (30 минут каждая, смотрю результат, не процесс)
- 14 марта: расчёт на данных одного дня рядом с ручной сводкой (артефакт, не статус).
- 21 марта: прогон на полном месяце, список расхождений с причинами.

## Что делать при блокировке
1. Смежники не отвечают более 1 рабочего дня — пиши мне, подключаюсь весом.
2. Понял, что срок не держится — говори в тот же день, вместе режем объём.
3. Нашёл, что задача решается принципиально иначе и дешевле — останавливайся и приходи.

## Что уже известно
Попытка в ноябре встала на том, что в витрине нет возвратов: ветка `spike/margin-dwh`.

Блоки шаблона — не бюрократия, а перечень мест, где делегирование обычно ломается. Уберите «границы полномочий» — получите либо согласование каждого шага, либо неприятный сюрприз; уберите «что делать при блокировке» — получите человека, который две недели молча ждёт смежников; уберите «зачем» — получите буквальное исполнение поручения, потерявшего смысл на третий день.

Врезка: постановка задачи ИИ-агенту. Тот же шаблон почти без изменений работает для кодового агента — агент, как и человек, не может выполнить задачу, для которой не сформулирован результат. Отличия ровно три, и все не в пользу агента. Он не откажется — сгенерирует правдоподобный результат вместо «задача непонятна», поэтому критерий приёмки должен быть механически проверяемым (тест, скрипт, число). Он не эскалирует — молча обойдёт блокировку способом, который вам не понравится, поэтому границы полномочий задаются как запреты инструментов, а не как просьбы. И он не помнит прошлого раза — блок «что уже известно» переносится в задачу целиком. Практическая механика — в «Командная работа с ИИ-агентами».

8. Контрольные точки без микроменеджмента

Менеджер должен выстроить процесс, который позволяет не брать на себя чужие обязанности и при этом не терять картину. Если вы не в состоянии не общаться с человеком две недели, заранее спланируйте точки, в которых будете проверять работу. Разница между контрольной точкой и микроменеджментом не в частоте, а в трёх свойствах: точка назначена заранее, у неё есть предмет, и между точками вы не спрашиваете. Интервал определяется двумя величинами, обе считаются до начала работы. Цена ошибки за интервал — сколько работы придётся выбросить, если сразу после прошлой точки всё пошло не туда (неделя работы одного человека приемлема, три недели работы троих — нет). Длина петли обратной связи задачи — если результат виден только через две недели, точка раньше не даст информации и выродится в отчёт о процессе. Отсюда правило: интервал ≈ min(допустимая потеря / темп сжигания, длина петли обратной связи), но не длиннее трети срока — точек нужно минимум две, иначе первая же неприятность обнаружится на финише, где манёвра нет.

«Покажи промежуточный результат» и «отчитайся о статусе» — два разных вопроса, и первый почти всегда лучше:

Отсюда практическое правило: сначала договариваемся о критерии готовности, потом об интервале проверки. Без сформулированного критерия любая точка выродится в разговор о процентах, потому что предъявлять нечего и мерить нечем; при наличии критерия интервал становится техническим вопросом.

Две детали решают исход. Оценку даёт исполнитель (шаг 3), и делает это до согласия — иначе срок остаётся чужим, а чужой срок не защищают. И эскалация сформулирована как правило, записанное заранее (шаг 10): иначе человек либо молчит две недели, либо приходит с каждым чихом.

9. Жизненный цикл делегированной задачи

Два перехода почти никогда не рисуют, и именно они отличают живой процесс от бумажного. Предложена → Отклонена — легальный, дешёвый и полезный исход. Точка → Пересогласована — то, ради чего точка вообще существует: если единственный возможный результат проверки «работаем дальше», проверка была ритуалом. А в переходе Заблокирована → В работе следующий шаг обязан вернуться к исполнителю: если он остаётся у менеджера, задача незаметно переехала.

10. Обратное делегирование: обезьяна на спине

Уильям Онкен и Дональд Уосс описали механику в статье «Management Time: Who’s Got the Monkey?» (HBR, 1974, перепечатка 1999). Метафора: у каждой проблемы есть следующий шаг, и это «обезьяна»; она сидит либо на спине сотрудника, либо на вашей, а передача занимает секунды. Классический диалог — сотрудник в коридоре: «У нас проблема с выгрузкой, смежники не отвечают». Вы: «Понял, я разберусь». Всё: до разговора следующий шаг принадлежал сотруднику, после — вам, и теперь он вправе спрашивать, как продвигается ваша работа. Роли поменялись местами за одну фразу. Как это ловить:

• Тест следующего шага. В конце разговора назовите вслух, что вы сделаете до следующей встречи и что сделает он; если ваш список длиннее — задача переехала.
• Не отвечать на вопрос «что делать?» ответом. Правильная реакция — «какие у тебя варианты и какой бы ты выбрал?»; нарушение видно сразу — через неделю человек приходит с тем же типом вопроса.
• Различать помощь и перехват. «Я напишу смежникам от своего имени, потому что нужен мой вес, а ты держишь тред и следишь за сроком» — помощь, следующий шаг остался у него; «я разберусь» — перехват. А четырнадцать чужих следующих шагов на неделю означают, что вы стали узким местом: «жду ответа от менеджера» в трёх задачах подряд — не проблема дисциплины, а диагноз системы.

Онкен формулировал правило жёстко: обезьяна кормится либо в присутствии владельца, либо не кормится вовсе — проблема обсуждается вместе с тем, кто ею владеет, и уходит со встречи вместе с ним. Дополнение из практики: обратное делегирование почти всегда добровольное со стороны менеджера — сотрудник не крадёт обезьяну, её отдают, потому что взять её самому быстрее и приятнее.

11. Типичные ошибки

12. Как это выглядит в проде

Продуктовая команда из восьми человек, платёжный сервис. Delegation Board на одной вики-странице: двенадцать областей решений, уровень для каждой, дата пересмотра; пересматривают раз в квартал и после крупных инцидентов. Эффект, который команда отмечает сама: споры «а кто это решает» исчезли не потому, что все согласны с уровнями, а потому что несогласие адресуется к строке на доске, а не к человеку.

Проект внедрения, вендор и три отдела заказчика. RACI на восемнадцать строк, с одним A в каждой. Единственная строка, из-за которой спорили две недели, — приёмка интеграции: заказчик хотел A у себя и у вендора одновременно. Компромисс оказался полезнее спора — A остался у заказчика, а у вендора появился явный S (Support) с обязательствами по срокам ответа; через полгода именно эта строка была единственной, на которую ссылались в конфликте.

Проект, где всё сделали наоборот. Матрица существовала как файл, приложенный к уставу, и ни разу не открывалась; уровень не назывался, срок был спущен сверху, оценку исполнитель не давал. За неделю до релиза выяснилось, что интеграцию никто не тестировал: в матрице QA стоял C, а не R, но об этом не помнили, потому что матрицу не читали. Формально документ был — фактически ответственность за строку не была передана никому.

Мини-итог

• Делегирование — распределение ресурсов, а не избавление от задач. Проверка: «где мой час стоит дороже всего», а не «что мне надоело». По закону сравнительного преимущества отдать стоит даже то, что вы сделаете лучше, — если ваше время в другом месте даёт больший эффект.
• Полномочия делегируются, ответственность — нет, и передаются они одним пакетом: разрыв в любую сторону ломает конструкцию.
• Три разных объекта передачи: задача, решение, ответственность за результат — три подготовки и три риска. Уровень называют вслух и записывают: классическая шкала и Delegation Poker мерят разные оси.
• RACI распределяет работу, RAPID и DACI — решения. Ровно один A на строку; матрица описывает 10–20 классов решений, а не все задачи; живую матрицу открывают в конфликте. Не делегируются подпись под уставом, go / no-go, эскалация за допуски, оценка людей и плохие новости спонсору.
• Контрольная точка ≠ микроменеджмент: назначена заранее, имеет предмет (артефакт, а не проценты), между точками не спрашивают; сначала критерий готовности, потом интервал. И обратное делегирование добровольно: обезьяну не крадут — её отдают; тест — чей список дел до следующей встречи длиннее.

Источники

• Appelo J., Delegation Poker и Delegation Board, Management 3.0 — семь уровней и практика их согласования.
• Oncken W., Wass D., «Management Time: Who’s Got the Monkey?», HBR 1974 / 1999 — обратное делегирование.
• Blenko M., Mankins M., Rogers P., «Who Has the D?», HBR 2006 — модель RAPID и разделение прав на решение.
• PMBOK Guide, PMI — матрица ответственности (RAM) и её связь с WBS.
• PRINCE2 — определённые роли, Project Board и управление по отклонениям; ISO 21502:2020 — разделы о ролях и полномочиях.
• Atlassian Team Playbook: DACI — лёгкая матрица для отдельного решения; Comparative Advantage, Econlib — экономическая формулировка закона.

Что дальше

Матрица ответственности отвечает, кто принимает решение, но ничего не говорит о том, как это решение находится, — а большинство решений в проекте принимаются не из готового списка вариантов, а после того, как варианты придуманы и проблема сформулирована заново. Хорошо распределённая ответственность за работу над неправильной задачей остаётся работой над неправильной задачей. Поэтому следующий шаг — методы, которыми проблема формулируется и разбирается на причины, и методы, которыми генерируются варианты: почему классический мозговой штурм проигрывает тем же людям, работающим порознь, как устроены brainswarming и brainwriting, зачем нужны «пять почему» и диаграмма Исикавы и как честно свести двадцать идей к одной.

Читайте: Методы решения проблем и генерации идей: от мозгового штурма к brainswarming и 5 почему