Приветосы!
У нас уже есть статья треугольник талантов руководителей проектов — три опоры, на которых держится профессия: Ways of Working (хард-скиллы управления), Power Skills (лидерство и коммуникация) и Business Acumen (понимание бизнеса). А в статье про TOP компетенций для резюме разбирал, какие четыре компетенции — коммуникации, планирование, контроль и мотивация — рекрутеры и PMO хотят видеть в первую очередь.
Эта статья - не абстрактная теория, а конкретный набор навыков, которые нужны PM, если вы работаете руководителем проекта в IT-продуктовой компании: там, где PM живёт на стыке бизнеса, продукта и разработки.
Понимание бизнеса и продукта
Это Business Acumen из треугольника талантов. Если PM не понимает, зачем компания вообще делает то, что делает, он превращается в диспетчера задач: ведёт спринты, закрывает тикеты, но не может ответить на вопрос "а зачем мы это делаем". В продуктовой компании это особенно критично — здесь решения принимаются не по ТЗ заказчика, а исходя из стратегии и данных о пользователях.
- Понимает бизнес-цели компании и умеет связывать задачи с результатом. Каждая задача в бэклоге должна быть объяснима через "зачем" — иначе это работа ради работы.
- Знает продуктовую стратегию и понимает, зачем делается каждая ключевая инициатива. PM должен уметь пересказать роадмап своими словами, а не просто скопировать его в план проекта.
- Разбирается в домене: рынке, пользователях, конкурентах, ограничениях и типовых сценариях. Без понимания контекста сложно отличить важный риск от несущественной детали.
Роли, полномочия и границы ответственности
Из "Треугольника талантов" я цитировал: работает команда, а оценивают менеджера. Но чтобы честно нести эту ответственность, PM должен точно понимать, где заканчиваются его полномочия и начинаются чужие. Размытые границы — источник большинства внутренних конфликтов в командах.
- Понимает роли в команде и зоны ответственности каждого участника. Иначе неизбежны дублирование работы и ситуации "я думал, это делаешь ты".
- Имеет полномочия принимать операционные решения в рамках своей зоны. PM без права решать хоть что-то самостоятельно — это не менеджер, а секретарь при команде.
- Может быстро эскалировать блокеры и получать помощь от нужных людей. Скорость эскалации часто важнее её "красоты" — застрявшая на неделю проблема стоит дороже, чем неловкий вопрос не по адресу.
- Понимает, где его зона ответственности заканчивается, а где начинается зона продуктового или функционального лидера. PM не подменяет продакт-менеджера в вопросах "что делать" и тимлида в вопросах "как делать" — он координирует, а не решает за них.
Планирование и управление исполнением
Это прямое продолжение "Планирования" и "Контролирования" из статьи про TOP компетенций. PM — интегратор, который объединяет планы и команду в одно целое. Но план без контроля исполнения — просто красивый документ, который никто не читает после первой недели проекта.
- Умеет приоритизировать задачи по ценности, рискам и срокам. В продуктовой разработке бэклог всегда больше, чем ресурсы команды — приоритизация это не разовое действие, а постоянный процесс.
- Ведёт план работ, сроки, зависимости и риски. Не ради самого плана, а чтобы видеть заранее, где команда упрётся в стену.
- Собирает и уточняет требования так, чтобы команда могла по ним работать. Требования должны быть переведены с языка бизнеса на язык, понятный разработке и дизайну.
- Фиксирует договорённости, чтобы не было разночтений. "Мы вроде так и договаривались" — самая дорогая фраза в проекте.
- Следит за выполнением и не допускает потери фокуса. Команды легко отвлекаются на срочное в ущерб важному — задача PM держать фокус на приоритетах.
Метрики и данные
Продуктовая компания живёт данными, а не мнениями. PM, который полагается только на ощущения команды или громкость голоса на встрече, рано или поздно приведёт проект не туда.
- Понимает метрики продукта и проекта. Не обязательно строить дашборды самостоятельно, но необходимо понимать, что стоит за цифрами и как они связаны с целями.
- Использует данные для принятия решений, а не только мнение участников. Данные не заменяют экспертизу команды, но дают общий язык для спора вместо субъективных аргументов.
Коммуникация и лидерство
80% успеха проекта зависит именно от того, как выстроено общение в команде. В продуктовой компании PM коммуницирует не только с разработкой, но и с продажами, маркетингом и руководством одновременно — и везде на разном языке.
- Умеет коммуницировать с разработкой, дизайном, аналитикой, продажами и руководством. Каждой аудитории нужен свой уровень детализации и свой фокус.
- Может проводить встречи так, чтобы они давали конкретный результат. Встреча без результата — это не коммуникация, а трата времени всей команды одновременно.
- Умеет управлять конфликтами и снимать напряжение в команде. Конфликт, оставленный без внимания, не исчезает — он уходит в пассивное сопротивление и падение мотивации.
- Обеспечивает прозрачность статуса проекта для всех заинтересованных сторон. Никто не должен узнавать о проблемах проекта последним.
Качество и адаптивность
Последний блок — про баланс. PM легко скатывается в одну из крайностей: либо гонит скорость в ущерб качеству, либо цепляется за первоначальный план и теряет управляемость при первом же изменении.
- Контролирует качество, а не только скорость. Быстро сделанная, но некачественная работа почти всегда возвращается в виде более дорогой переделки.
- Умеет адаптироваться к изменениям без потери управляемости. В продуктовой разработке планы меняются постоянно — задача не в том, чтобы этого избежать, а в том, чтобы менять план управляемо, а не хаотично.
Критично важно: без этого чек-лист не работает
Все навыки выше — зона ответственности самого PM. Но есть вещи, которые PM обеспечить себе сам не может — это должна дать компания. Без них даже самый компетентный интегратор (вспоминая роль PM из "Треугольника талантов") физически не может интегрировать.
- Есть доступ к людям, которые принимают решения. Иначе любой сложный вопрос упирается в стену ожидания.
- Есть право синхронизировать команды и ставить приоритеты. Без этого права PM превращается в наблюдателя за чужими решениями.
- Есть возможность влиять на сроки, объём и порядок работ. Иначе PM отвечает за результат, на который не может повлиять — заведомо проигрышная позиция.
- Есть ясные границы ответственности. Мутные границы порождают либо перегрузку PM чужими задачами, либо пустоты, за которые никто не отвечает.
- Есть поддержка руководства, если нужно убрать блокеры. Эскалация без реакции сверху — это просто крик в пустоту.
Заключение
Этот чек-лист — не разовая проверка "подхожу я или нет", а рабочий инструмент: для самооценки, для найма и для роста внутри профессии. Он логично собирает то, о чём я писал раньше про треугольник талантов и топ компетенций, — но применительно к конкретной среде: IT-продуктовой компании, где руководитель проекта одновременно интегратор, коммуникатор и человек, который переводит бизнес-цели на язык задач для команды.