Чего не хочешь от нового руководителя

Чего я, как IT Project Manager, не хочу от нового руководителя?

Как опытный IT Project Manager, я вижу свою ценность в том, чтобы эффективно достигать бизнес-целей через управление командой и процессами. Поэтому мой подход к новому руководителю строится на желании установить партнерские, а не подчиненно-директивные отношения. Вот ключевые аспекты, которых я хотел бы избежать.

1. Микроменеджмент и подрыв автономии

Самое разрушительное — это микроменеджмент. Руководитель, который ежедневно проверяет каждую задачу в Jira или требует детальных отчетов вместо доверия к установленным процессам, губит инициативу и скорость.

• Пример негативного сценария: Вместо вопроса "Каков прогресс по проекту А?" я получаю "Почему задачу PROJ-123, оцененную в 5 часов, разработчик Петров выполняет 6 часов?". Это говорит о недоверии к моей способности управлять нагрузкой и приоритизацией команды.
• Что это вызывает: Команда теряет мотивацию, я трачу время на оправдания вместо управления рисками, а атмосфера становится токсичной.

2. Отсутствие стратегического видения и ясных целей

Руководитель должен быть стратегическим лидером, а не просто контролером сроков. Я не хочу работать с тем, кто:

• Не может четко сформулировать бизнес-ценность проекта или его ключевые показатели успеха (OKR/KPI).
• Постоянно меняет приоритеты "по звонку", не оценивая влияние на текущие спринты и ресурсы. Это прямой путь к выгоранию команды и техническому долгу.

# Антипаттерн: как НЕ должно звучать
"Срочно бросайте всё и делайте эту новую фичу для отдела продаж.
Да, я знаю, что мы в середине спринта и готовим релиз.
Нет, мы не отменим ни одну из текущих задач. Просто успевайте всё."

• Не защищает команду от непоследовательных требований стейкхолдеров.

3. Игнорирование процессов и best practices

Опытный руководитель должен понимать ценность процессов. Я опасаюсь:

• Давления с целью "ускорить" за счет пропуска этапов: "Зачем нам ревью кода и тестирование на этом маленьком изменении? Просто задеплойте в прод!".
• Непонимания гибких методологий: Трактовки Agile как оправдания для хаоса и постоянных изменений в последний момент.
• Оценки успеха проекта исключительно по факту "выпуска в срок", игнорируя качество, удовлетворенность пользователей и долгосрочную поддержку продукта.

4. Неумение слушать и нежелание быть "щитом" для команды

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

• Игнорировал мою экспертизу и риски, которые я озвучиваю. Фраза "Разберитесь сами, я просто хочу результат" неприемлема.
• Передавал команде нефильтрованное давление "сверху", создавая панику, вместо того чтобы ставить адекватные, переговоренные задачи.
• Не участвовал в разрешении блокирующих организационных проблем (например, конфликты с другими департаментами, задержки с закупкой лицензий).

5. Оценка по ванильным метрикам, а не по реальной ценности

Опасным сигналом является фокус на неправильных метриках:

• Оценка производительности PM по количеству закрытых тасков, а не по достижению бизнес-целей, удовлетворенности клиента и здоровью команды.
• Использование velocity как инструмента сравнения или наказания команд, что полностью извращает его истинное назначение — внутреннее планирование.

Вместо заключения: В идеале я стремлюсь к отношениям, где новый руководитель — это стратегический партнер и лидер, который ставит ясные цели, доверяет моей профессиональной экспертизе в тактическом управлении, защищает команду от внешнего хаоса и оценивает результат по реальной созданной ценности, а не по активности в таск-трекере. Такой подход позволяет нам вместе выстраивать предсказуемые, эффективные и здоровые процессы разработки.