Проектный менеджер, который разбирается в технических нюансах с первого рабочего дня — миф. Единственное исключение — это PM-ы с бэкграундом в разработке. Итак, вы — проектный менеджер, который пришел на свою первую работу и ничего не смыслит в тонкостях проекта. На первых порах это нормально. Разработчики косо поглядывают? Ничего страшного, все мы там были.
Освоившись на проекте, вы задаетесь вопросом, а нужно ли вообще разбираться в деталях или это не имеет значения? Классическая дилемма, после которой каждый выбирает свой путь в проектном менеджменте. Прежде, чем определиться со своим выбором, советуем ознакомиться с преимуществами понимания деталей, которые обсуждают разработчики на митингах и перекурах.
Прежде всего, давайте договоримся, что проектный менеджер в небольшом стартапе по долгу службы выполняет совсем не те задачи, с которыми сталкивается проектный менеджер в крупной корпорации.
В стартапе вам, скорее всего, не придется масштабировать SCRUM, зато от вас будут ожидать экономии средств, умения договариваться с не всегда адекватными заказчиками и каждый раз прыгать выше головы.
Проектные менеджеры, которые выполняют только свои обязанности, принимайте наши сердечные поздравления с попаданием в 15% сотрудников крупных компаний с налаженными процессами. Остальные же 85%, добро пожаловать в реальный мир.
В реальном мире проектному менеджеру было бы неплохо понимать, о чем говорят разработчики. Это не обязательное условие, но очень желательное. Сейчас объясним, почему.
Работа с командой
Для работы над репутацией компании в медиапространстве, важно получать максимально возможный процент довольных заказчиков. Такое возможно только, если команда работает слаженно и на результат. Для результата обычно хватает выполнения одного из двух условий:
- процессы максимально налажены;
- проектный менеджер своей могучей спиной закрывает всевозможные проблемы и любой ценой остается другом и лидером команды.
И если на первый пункт вы можете влиять лишь частично, то реализация второго — ваша ответственность. Как это сделать, рассказали ниже.
1. Вникать в суть, а не просто улыбаться и кивать.
Если вам кажется, что разработчики ведут себя слишком надменно, поставьте себя на их место. Скорее всего, в начале своей карьеры ребята искренне пытались доносить технические нюансы до менеджмента, но сталкивались с волной непонимания.
А теперь честно ответьте себе на вопрос, чем вы отличаетесь от предыдущего менеджера? Так что не удивляйтесь, если их ответы будут односложными и никак не раскрывать суть. «Это либо можно реализовать, либо нельзя потому что нельзя»,— скажет вам разработчик и будет абсолютно прав, потому что какая разница, говорить просто «нельзя» или заменять «просто» кучей незнакомых слов?
«Нельзя» — оно и проще, и понятней. Если вам комфортно, когда с вами разговаривают, как с неразумным ребенком, значит, пора что-то менять.
2. Лидить команду, во что бы то ни стало.
Командовать разработчиками и быть менеджером проекта — не одно и то же. Быть менеджером проекта значит пахать больше всех и овертаймить вместе с командой. Если вы ничем не можете помочь разработчикам даже на элементарном уровне — толку с вас как менеджера?
Здесь можно было бы сказать о том, что менеджер свою задачу выполнил, можно идти домой, но с таким подходом не удивляйтесь, когда команда будет так же наплевательски относиться к вам, как и вы к ним.
Лучшее, что вы можете сделать на горящих проектах — постараться помочь. Если у вас нет бэкграунда в разработке, можете ускорить работу каким-то решением, коллом, письмом, параллельно выполняя свой незаканчивающийся список задач по другим проектам.
Самое важное здесь — оставаться на месте и максимально оперативно помогать, когда вы нужны. Но без понимания сути процессов вы будете скорее затягивать релиз, чем помогать команде.
3. Понимать, кого набираешь под проект / Адекватно оценивать уровень разработчиков.
Даже в небольших компаниях за вами должно оставаться право подбирать команду под проект. В противном случае вы можете вообще не понять, как разбить задачи и на чем команде сфокусироваться в первую очередь.
Судить о разработчике по послужному списку проектов сложно. К примеру, абсолютно гениальный питонщик Аркадий, который не сработался с предыдущими командами по причине своего перфекционизма, на вашем проекте может оказаться суперзвездой, если найти ему верных падаванов и правильно расставить приоритеты.
Приятный бонус: если команда поймет, что вы на их стороне и стараетесь сделать все возможное, чтобы не усложнять им жизнь, да еще и разбираетесь, почему здесь принято то или иное решение, они постараются работать с вами как можно дольше. Еще и умных друзей приведут, потому что увидят процессы во имя результатов, а не ради самих процессов.
Работа с заказчиком
1. Отвечать на вопросы сразу по мере их поступления.
Заказчики — не наивные дети, и чтобы убедиться в адекватности предлагаемых вами решений, стараются максимально подстраховаться, привлекая других технических специалистов и консультантов.
Таким людям платят за максимально возможное количество уточняющих и неудобных вопросов, и если на каждый из них вы не сможете ответить без команды разработки, то в глазах заказчика будете выглядеть лишним звеном в цепи. Зачем встречаться с человеком, который не готов вести конструктивный диалог, если можно сразу спрашивать разработчиков?
Кроме того, не стоит недооценивать конкуренцию. Раз уж заказчик ищет человека, готового моментально отвечать на его вопросы и разбирающегося в технической части, рано или поздно он его найдет. Этим человеком может стать один из самых сильных разработчиков, который давно интересовался менеджментом.
Старайтесь не выпадать из технического контекста. Ваша обязанность — менеджить проект, а не просто работать с документацией и напоминать всем о дедлайне.
2. Продавать дополнительные услуги
Во время обсуждения функционала, заказчик может озвучить какое-то пожелание, и если вы сумеете вовремя сгенерировать подходящее решение и озвучить хотя бы примерные сроки и стоимость — компания получит дополнительную прибыль.
Прибыль — это хорошо, но чтобы разработчики не грозились вас после этого предложения убить, надо понимать, что именно вы предлагаете, и насколько это предложение выглядит реалистично и здраво.
Приятные бонусы
1. Бюджет
Вы можете сказать, что для реализации всех озвученных выше задач достаточно привлечь специально обученных специалистов (читай бизнес-аналитиков, тех.лидов и тимлидов), но эти ребята вполне заслуженно стоят своих денег, которых компания на этапе масштабирования может не быть готовой выделить.
Вот и получается, что чем глубже у вас экспертиза в смежных областях, тем выше вы ценитесь как проектный менеджер. А еще такие знания отлично отражаются на вашей зарплате.
2. Объем работ.
Когда проектный менеджер знает матчасть и все происходящие процессы, можно быть уверенным, что, с одной стороны, без его аппрува в проект не «впихнется» то, что выходит за рамки бюджета, а с другой, что сам менеджер по незнанию не пообещает разработку адронного коллайдера.
3. Карьерный рост
Многофункциональный проектный менеджер — мечта любого CEO, так как вместо того, чтобы постоянно его контролировать, можно получать отзывы довольных заказчиков, разработчиков и деньги. Кого во время масштабирования повысят в первую очередь — думаю, рассказывать не надо.
Выводы:
Управлять тем, чего не понимаешь, можно, но нужно быть готовым грустить и часто выпадать из контекста. Чтобы получать больше свободы (и ответственности), проектному менеджеру было бы неплохо разбираться в технической матчасти.
Мы не призываем PM-ов становиться программистами, однако углубленное понимание процессов на проекте — отличное подспорье для профессионального роста. Доказано примером наших спикеров и менторов курсов DAO PM, Middle PM и Techmind.