PM, который приносит результат: как управлять проектами без хаоса и выгорания

Начнем с главного – РМ – это не начальник. И это не просто человек с доступом к таск-трекеру и табличкой в xls, это связующее звено между клиентом, командой и бизнесом. Это своеобразное ядро с нитями, тянущимися к этим “секциям”, и задача РМ – не запутать эти нити, а заставить работать вместе и слаженно. Или, если сравнивать с работой дирижера, его дело – заставить разрозненный и незнакомый друг с другом коллектив выдать по итогу великолепное музыкальное произведение. 

  Хороший РМ должен сделать так, чтобы:

• у команды было четкое понимание задач;
• у клиента – уверенность в процессе;
• у бизнеса – результат без пожара.

Этот человек не пишет код, не рисует дизайн, не верстает и не наполняет контентом. Он создает условия, в которых это все работает максимально эффективно за счет усилий команды.

Так чем же он, все-таки, занимается?

• Он планирует работу. Но не просто расставляет сроки в диаграмме Ганта, а смотрит на проект как на живой организм: где может заболеть, где перегруз, а где нужна помощь. 
• Он планирует ресурсы. Именно PM следит и отвечает за рентабельность проектов. Именно PM, в идеале, собирает все данные о том, сколько будет стоить тот или иной компонент системы/сайт и т д.
• Он держит связь с клиентом: управляет ожиданиями, объясняет, почему нельзя сделать все и сразу, и что “сделайте как-нибудь” — это не бриф.
• Он снимает блокеры, организует встречи, добывает нужную информацию и данные и когда нужно — защищает от бессмысленных “впрыгов” сверху.

PM отвечает за: 

• Планирование и организацию проекта.
• Управление командой и ресурсами.
• Контроль за выполнением задач и сроками.
• Коммуникацию с заинтересованными сторонами.
• Решение возникающих проблем и рисков.

А еще, классный PM еще и немного технолог, но об этом чуть позже.

Как выглядит день проектного менеджера:

• Проведение утренних совещаний с командой.
• Обновление статуса задач и сроков.
• Взаимодействие с клиентами и заинтересованными сторонами.
• Решение возникающих проблем и адаптация планов.

Теперь рассмотрим, как PM работает в каждую из сторон.

Как PM помогает разработчикам?

Если вы DEV, то у вас наверняка были ситуации, когда задача приходит с описанием “нужно просто поправить немножко”, а по факту там 4 дня рефакторинга.

Или в вопросах дизайна клиент говорит что-то вроде «не, не то, давайте вы еще порисуете»

Так вот, хороший PM — это тот, кто перехватывает хаос до того, как он дойдет до вас. Он уточняет, обсуждает, приоритезирует, декомпозирует и выдает уже четкую задачу по SMART, которую можно просто брать и делать, в которой четко обрисовано то, какой должен получиться результат. В ней уже есть понятные сроки и все необходимые ресурсы.

Я, как «иногда PM» совсем не против того, чтобы в моменты, когда чего-то по задаче не хватает или что-то непонятно, DEV-ы спрашивали меня. Я имею в виду не столько техническую составляющую, сколько идеологическую. Как правило, я довольно хорошо знаю свои проекты, хорошо понимаю результат, который мне нужен и могу рассказать о том, чего хочу получить. А знаю я это потому что не стесняюсь общаться с клиентами – и будущими и уже действующими. В неделю проводится не менее 10 часов переговоров – все это нужно для понимания, что именно клиент хочет получить в итоге.

Как PM помогает клиенту?

Если с одной стороны у нам РМ и разработчики, то с другой — клиент. У него есть деньги и ожидания. Но он не всегда понимает, как устроен процесс, сколько реально занимает задача, и зачем вообще ему согласовывать структуру перед дизайном. PM помогает клиенту понять, как мы работаем, какие решения повлияют на результат, а какие только мешают. Он обеспечивает прозрачность: регулярные апдейты, демо, согласования — все это, чтобы клиент знал, что его проект не завис.

А еще, PM должен ПОНЯТЬ и ВЫТАЩИТЬ из клиента все, что необходимо для того, чтобы проект вообще можно было сделать. Именно ПОНЯТЬ и ВЫТАЩИТЬ, поскольку клиент не знает заранее что именно нам и в каком виде нужно.

А для того, чтобы понять, что будет нужно и в какой момент времени, PM обязан планировать. И свою работу, и работу клиента по подготовке материалов.

Делегирование

Какие процессы нужно делегировать? Те, которые повторяются из раза в раз? Что делегировать, если и самому ничего не понятно? Ключевая компетенция PM – из хаоса создавать что-то понятное. Как только «понятность» оформилась – делегируем.

Если понятность не возникает, то !Не пытаемся делать сами разбираясь по ходу, а учимся! Если проблема в процессе управления – учим процессы. Если непонятна технология – идем в документацию. Нужно делегировать абсолютно все, кроме тех вещей, которые можешь сделать только ты.

Важно понимать основную важность PM – он может понять и выстроить процесс. Понимая, при этом, что выстроенная работа – это нечто контролируемое, поскольку именно на PM лежит ответственность за развитие. Ответственность многогранная, но ограниченная его ролью. 

В разработке PM отвечает за 3 вещи – качество, сроки и время.

Главная мысль: “Мне пофиг, что, когда и кто. Важно, чтобы все знали, что мы делаем, зачем и чего не будет. Остальное — рюшечки.”

Эволюция проектного менеджера: от процесса к смыслу

Рассмотрим стандартные стадии развития проектного менеджера:

Начинающий PM:

• Сосредоточен на команде.
• Влюблен в инструменты.
• Не видит бизнес-целей.

Уверенный уровень: 

• Учится говорить «нет».
• Управляет ожиданиями.
• Слышит реальные потребности.

Опытный PM / Delivery / Head of PMO:

• Строит доверие.
• Оперирует смыслами, а не тасками.
• Приоритизирует пользу, а не активность

Парадокс зрелого PM: осознанный «пофигизм»

Главное — осмысленные ожидания и понятная цель.

Поговорим об ошибках начинающих PM:

• Не назначает конкретных ответственных.
• Ведет трекинг ради галочки.
• Забывает про риски после их идентификации.
• Не объясняет, чего проект делать не будет.

Что делает полезный PM?

• Делегирует и продает задачи, а не «скидывает сверху».
• Помогает команде формулировать задачи самостоятельно.
• Спрашивает: «Что может пойти не так?» и «На что влияет?».
• Практикует underpromise & overdeliver.
• Формирует ожидания и управляет ими на каждом этапе.

Что может PM (без приоритезации)

PM может и должен:

• Донести вижн продукта и убедить, почему он важен.
• Влиять на принятие решений в команде и у клиента.
• Понимать стадии формирования команды и действовать в соответствии с этими знаниями.
• Делегировать, учитывая рост и мотивацию людей.
• Понимать и грамотно выстраивать процессы: оценки, таймлайны, риски, метрики, UAT, релизы.
• Собирать и использовать документацию, отчеты, шаблоны.
• Вести проекты в разных фазах и контекстах.
• Оценивать бюджет, сроки и читать P&L.
• Фокусироваться на результате и вовлеченности.
• Строить отношения, а не только процессы.

Итог

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

Проектный менеджмент — это не про трекеры и методологии. Это про людей, смысл, ответственность и ясность.

Хочешь быть сильным PM? Учись слышать, понимать, объяснять и выстраивать доверие.