Представьте PM-а, который пытается тащить проект на себе: сам ведёт переговоры, сам пишет отчёты, сам обновляет доску задач и параллельно разруливает конфликты. Итог предсказуем всегда один - выгорание и хаос в проекте. Делегирование спасает: оно позволяет распределять задачи так, чтобы проект ехал, а не буксовал.

Но делегирование это не про скинуть все проблемы на первого встречного. Это искусство правильно передавать задачи и ответственность (то есть исполнитель, которому вы делегировали задачу, берёт на себя обязанность довести её до результата, но финальная ответственность за проект всё равно остаётся за вами). Давайте разберём, что можно делегировать, что нельзя, как контролировать и почему делегирование работает не только вниз, но и вверх.

Что делегировать, а что нельзя

Можно:

• Рутинные организационные задачи. Протоколирование встреч, обновление статусов в системе, сбор данных для отчётов.
• Подготовку материалов. Черновые презентации, графики, сводки по метрикам. PM проверит и доработает, но не обязан делать всё сам.
• Часть коммуникаций. Технические детали - пусть тимлид решает с подрядчиком. Аналитик может напрямую уточнить требования у клиента, если вы дали контекст.
• Исследования и проработку. Сравнение инструментов, поиск best practices, предварительный анализ пользовательских запросов.

Нельзя:

• Финальную ответственность. Если дедлайн сорван - отвечает PM, даже если работу делал другой.
• Приоритизацию на уровне проекта. Советы можно спросить, но решение остаётся за PM и стейкхолдерами.
• Ключевые договорённости. Сроки, бюджеты, цели - не зона команды.
• Решение конфликтов. Собирать факты может кто угодно, но договариваться обязан менеджер.

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

Главный страх PM что задачи уйдут в никуда. Но решать это микроконтролем значит убить доверие, команда перестаёт верить, что вы доверяете ей задачи, а вы сами перестаёте верить, что они могут справиться без вашего постоянного вмешательства.

Рабочая схема:

• Определять результат, а не процесс. Фокусироваться нужно на результате, а не на мелочах процесса. Вы задаёте, что именно должно быть достигнуто и каким должен быть эффект, но не контролируете каждое движение исполнителя.
• Делать точки контроля, а не жить в чате 24/7. Стендапы, еженедельные обзоры - достаточно.
• Использовать прозрачные инструменты. Jira или Trello должны сами показывать прогресс.
• Давать конкретную обратную связь. Не «плохо», а «отчёт перегружен деталями, клиенту нужен упрощённый вариант».

Контроль - это как навигация: курс задан, координаты сверяются, правки вносятся по мере необходимости.

Делегирование вниз: в команду

Это основа работы PM. Но делегирование вниз - это не «раздать поручения», а процесс:

• Доверие. Передал - значит доверяешь. Вмешательство на каждом шагу обесценивает задачу.
• Рост. Джун не вырастет, если будет чинить только кнопки. Иногда стоит дать сложную задачу, чтобы человек научился.
• Использование сильных сторон. Аналитик быстрее соберёт данные, дизайнер сделает нагляднее. Задачи должны попадать туда, где они принесут максимум пользы.

Делегирование вверх: к стейкхолдерам

Менеджер - не супергерой. Иногда нужно отдавать ответственность «наверх»:

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

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

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

Часто замечаю как молодые PM передают задачи в отдел разработки или QA так «Сделай красиво» или «разберись» - это не делегирование. Это рулетка. Правильная передача задачи должна содержать:

• Цель. Что должно измениться.
• Критерии успеха. По каким признакам поймём, что задача выполнена.
• Сроки и границы. К какому числу, в каком объёме, с какими ограничениями.

Без этого результат всегда будет не тот что вы думали.

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