Не просто PM, а консультант. Как эволюционирует менеджер проектов
Привет всем, меня зовут Роман, и я уже больше 8 лет тесно связан с управлением проектами. Стартовал на должности джуниор PM’а , и дорос до руководства отделом кастомной разработки.
Через меня прошло сотни проектов, часть из которых вел лично, частью занимались мои коллеги, а я был в качестве наставника. В статье поделюсь наблюдениями об эволюции менеджеров проектов, а также опишу три этапа их становления с точки зрения баланса между интересами команды и заказчика.
Этап 1. Клиент всегда прав
С этой стадии начинают практически все юные менеджеры. Они фокусируются на заказчике, плохо понимают техническую часть проекта и не погружены в работу девелоперов.
Менеджер систематически пропускает чендж реквесты от клиентов, не доносит позицию и мнение команды, стесняется задать заказчику важные, но неудобные вопросы. Как результат — проект совершенно не устраивает ни одну из сторон.
Команда теряет мотивацию, когда понимает, что ее усилия не ценят, и не показывает максимальную самоотдачу. Это неизбежно приводит к натянутым отношениям в коллективе, что сказывается на результатах.
На ретроспективе менеджер разводит руками и говорит: «Ну а что я мог поделать? Это заказчик так захотел». При этом, кроме перекладывания ответственности, он забывает, что его роль — не исполнять, а скорее консультировать (об этой роли я расскажу детальнее в описании третьего этапа). И усилия нужно направлять на успешное завершение проекта, а не на удовлетворение малейших неаргументированных капризов клиента.
Кейс из жизни. Один из менеджеров, назовем его З., во время демки дизайнерского решения соглашался со всеми правками заказчика и не давал дизайнеру вставить ни слова. Делал он это из лучших соображений, будучи уверенным, что в итоге клиент будет счастлив от того, насколько мы клиентоориентированная компания.
Но получил не только недовольного клиента (который воспринял согласие со всеми правками как низкий уровень экспертности компании), но и демотивированного сотрудника, который не имел возможности аргументировать и защитить свою работу. После срочного звонка нам удалось донести свою мысль до заказчика, и большая часть правок отпала.
Еще одна проблема на этом этапе — менеджер-копипастер. То есть менеджер, который, не вникая в суть, просто передает слова от заказчика команде и наоборот. Тогда по любому вопросу ему приходится идти и все уточнять, постоянно отвлекая сотрудников от работы.
Причина этому проста — вопрос пока сложный для понимания, но срочный, а потому приходится выполнять роль ретранслятора. И в некоторых случаях это приемлемо. Но если подобное поведение становится привычкой, есть риск получить менеджера, который вместо экономии времени будет только тратить время обеих сторон. Тогда «добавочная ценность» сводится к отрицательному значению. В случае прямой коммуникации — все стороны выигрывают.
Вывод очевиден: бездумное согласие, чтобы во всем угодить клиенту, не только снижает продуктивность команды, но и бьет по самому бренду компании, ведь заказчик начинает сомневаться, туда ли он отдал свои деньги, если он сам рулит проектом.
Для выхода из тупика менеджеру проектов необходимо меняться. Ему нужно включать фильтры и пропускать через них идеи клиента.
Таким фильтром могут быть вопросы:
- Какая ценность для конечных пользователей?
- Поможет ли эта фича достичь успеха проекту? Это исключительно вкусовые предпочтения заказчика или чрезмерная ориентация на референсы?
- Сколько это будет стоить проекту?
Но иногда изменения заходят в другую крайность — когда права всегда команда.
Этап 2. Team is the King
После того как менеджер получает обратную связь и начинает переориентацию на команду, он может разбивать аргументы заказчика даже без попытки понять суть запроса. Так может происходить, например, когда задача предполагает переделывание уже сделанного, а менеджер знает, что разработчики не любят выполнять двойную работу. Они аргументируют это тем, что работа выполнена по ТЗ и переделывание — это плюс к срокам и бюджету.
В итоге заказчик полностью уверен, что его не слышат или не хотят слышать, что он говорит с каменной стеной. Менеджер же понимает, что идет по своему плану, и готов со рвением отстаивать каждое свое решение, опираясь на поддержку команды. Закономерно, что заказчик требует поменять менеджера. А это может быть непросто, ведь менеджер уже обладает уникальным знанием о проекте, договоренностях, о том, что было в скоупе и что было решено вынести за его пределы.
Также отмечу, что роль консультанта в том, чтобы вникнуть в суть проблемы и предложить возможные варианты решения. Например, если речь идет о какой-то новой фиче в связи со сменой фокуса бизнеса, есть смысл пожертвовать другой фичей, чтобы остаться в сроках и в бюджете. При этом важно предупредить, что могут быть вопросы по качеству, так как ранее это не обсуждалось.
Кейс из жизни. Один из менеджеров, назовем его Л., находясь в дружественных отношениях с командой проекта, любую обратную связь от заказчика воспринимал в штыки. Клиент был в недоумении, почему вместо конструктивного диалога приходится сражаться за каждую правку. Это переросло в неприязнь и отсутствие желания работать с менеджером. Выявив проблему, мы провели работу над ошибками, объяснили менеджеру, что «не все то плохо, что правки» и у клиента нужно обязательно уточнять цели их внедрения. В итоге Л. начал обсуждать причины изменений и давать конструктивные комментарии. Эффективность работы по проекту стала расти, как и лояльность клиента к команде и компании.
Вывод очевиден: когда менеджер заигрывается в адвоката команды, то вместо того, чтобы быть клиенту партнером, он превращается в антагониста. В итоге недовольны все стороны и вероятность того, что клиент решит найти более дружелюбную компанию для развития своего бизнеса, очень высока.
Как понять, что перекос в одну или в другую сторону? Попросите фидбэк от команды или от заказчика. О недовольстве не принято говорить, но, если менеджер запрашивает обратную связь, ему мягко дадут понять, где не хватает его усилий.
Как только менеджер осознает, что его ключевая роль — быть партнером как для клиента, так и для команды, а задача — дать заказчику результат, при этом сохранив баланс отношений с коллективом, тогда мы и приходим к третьему этапу эволюции менеджера.
Этап 3. Золотая середина (консультант)
Менеджеры этого типа уже наступили на грабли недопонимания с командой и получили нелестные отзывы от клиента. В голове сформировалось четкое мнение: «Всем любим не будешь, более того — это нормально». И тут начинается самое интересное — поиск баланса, понимание своей роли консультанта для заказчика и мотиватора для команды.
Менеджер этого типа ставит выше всего интересы проекта. А это значит — иногда может попросить команду задержаться, а иногда отказать заказчику во внедрении фичи, так как она не до конца продумана или попросту не была запланирована. Конечно, кроме соблюдения баланса, есть еще много подводных камней, но без него говорить о развитии менеджера в принципе не приходится.
N.B. Подробнее о роли консультанта
Важно понимать, что ценность любого менеджера зависит от сложности вопроса, который он может решить самостоятельно. У заказчика всегда хватает задач, кроме разработки сайта или приложения, и, конечно, он рассчитывает на то, что все проблемы будут решены на стороне партнера. Или по крайней мере будут предложены варианты решения с возможными рисками.
Поэтому при возникновении трудностей предложите способ их устранения, а лучше несколько, и никогда не идете к заказчику с вопросом «Что делать дальше?». В этот момент все позитивное впечатление разрушается и клиент понимает, что, кроме него самого, проект никому не нужен.
Также, если у заказчика появляется какая-то гениальная мысль, важно понять, как это отразится на скоупе проекта. Возможно, эту мысль лучше отложить или дополнительно проработать. Поэтому практикуйте критическое мышление и рассматривайте не только положительный исход вопроса.
Кейс из жизни. Во время очередного планирования спринта заказчик настоятельно просил о внедрении сразу двух больших фич. Команда уперлась, настаивая на том, что есть смысл сделать только одну фичу, а вторую перенести на следующий спринт. После диалога с владельцем продукта удалось договориться о том, чтобы одну из фичей запустить не в полном виде, а также перенести часть функционала «на потом» (речь шла об адаптивности и времени фронтенд-разработчика). Заказчик пошел навстречу, и команда в итоге сделала тот минимальный функционал, который был согласован с инвесторами.
Резюмируя
Часто в начале карьеры менеджеры проектов не находят баланс между тремя заинтересованными сторонами — компанией, командой и клиентом. Многое зависит от предыдущего опыта сотрудника, культуры компании, заказчиков и команды. Но если у менеджера нет компаса, куда идти, то этот путь может занять гораздо больше времени. Поэтому помните о крайностях и не впадайте в них. Найти баланс — нелегкая задача, которую без креатива, нарушения правил и постоянной работы над собой будет сложно выполнить. И именно в этом прелесть роли менеджера.
