Менеджер должен обладать прокаченными навыками коммуникации. Это значит легко находить язык с командой, с Заказчиками, с руководством. Это значит уметь быстро сглаживать любые конфликты как внутри команды, так и с Заказчиками (в идеале, без потерь). Заказчики бывают сложными в общении, некоторые обучены навыкам манипуляции, и легко продавливают на большие работы, за меньшие деньги. Да и исполнители бывают не подарок – кто-то косячит, кто-то ленится, кто-то просто токсик и расшатывает всю команду.
В продолжении – менеджер должен иметь прокаченные навыки ведения переговоров. Это означает, что необходимо обладать таким набором скилов, которые позволят склонить оппонента к принятию выгодного для менеджера решению. Также менеджер должен уметь поддерживать высокий уровень лояльности у Заказчика, особенно в случае недовольства в адрес проектной команды (например, когда команда в чем-то сильно накосячила).
Менеджер должен обладать сильными лидерскими качествами. За слабым менеджером команда не пойдет. И Заказчик не будет прислушиваться к его просьбам и рекомендациям. Нужно заслужить авторитет и у команды, и у руководства, и у Заказчика. Сильный лидер мотивирует команду, по его просьбе команда может выходить работать сверхурочно, если сроки горят, а Заказчик будет прислушиваться к его предложениям.
Менеджер должен уметь принимать правильные решения в условиях неопределенности. Сложные IT-проекты – синоним неопределенности. Не ясны требования, не ясны функциональные возможности вендорского решения, непонятно, что там у Заказчика с инфраструктурой, какие есть ограничения от смежных подразделений и тд. И во всем этом многообразии неопределенностей нужно быстро и правильно принимать решения. Много. Каждый день. Если менеджер принял неправильное решение – с него спросят. Если принял правильное – никто даже не заметит.
Менеджер должен брать на себя ответственность за проект. За то, насколько он получился успешен, за то, превышен ли бюджет, за то, всё ли удалось реализовать и в какой срок, за то, доволен ли Заказчик результатом работы и будет ли продолжать с вами дальнейшее сотрудничество. Именно с менеджера спросит и руководство, и Заказчик, если что-то из перечисленного выше пошло не так.
Менеджер должен уметь работать в условиях ограниченных ресурсов. Всегда. Зачастую в компаниях матричная структура - это когда существует четкая орг.структура с руководителями подразделений и, одновременно, существуют проекты с руководителями этих проектов. Это означает, что формально руководитель в проекте ставит задачи, спрашивает за результат и имеет рычаги влияния, но по факту люди не находятся у него в подчинении. Более того, в любой момент их могут забрать, перевести на другой проект или просто понадобятся дополнительные люди в команду. Менеджеру в таком случае придётся их где-то искать и договариваться об условиях привлечения в команду.
Менеджер должен уметь грамотно работать с рисками. В голове должны автоматом срабатывать связи между какими-то действиями и потенциальными рисками, к которым эти действия могут привести. Пример – Заказчик прислал письмо о том, что к команде присоединился новый сотрудник с их стороны. Менеджер должен сразу понимать, что от этого человека могут начать поступать новые требования, причём совершенно непонятно, в каком месте (к функционалу, к процессам, к документам, к чему угодно). Более того, у этого человека могут быть свои ожидания от результатов проекта. Это значит, что задача номер один – рассказать ему, что мы делаем, какие цели проекта, зоны ответственности и сформировать правильные ожидания. В работе с рисками главное не просто выявлять эти риски, а правильно их обрабатывать – в каком-то случае нужно предусмотреть план Б, в каком-то случае нужно сформировать правильные ожидания у Заказчика, как в примере выше, в каком-то случае принять решение потратить больше трудозатрат сейчас, чем потенциально потом потратить их в 2 раза больше, в каком-то случае своевременно эскалировать проблему и тд.
Менеджер должен уметь правильно работать с ожиданиями. Это значит сделать так, чтобы картинка в голове у Заказчика совпадала с картинкой в голове у менеджера и проектной команды по всем вопросам. Если с ожиданиями не работать, то весь проект вас будут сопровождать фразы «всё фигня, переделывайте», «это вообще не то, что мы хотели», «мы думали вы эксперты, а вы делаете такую фигню» и тд.
Менеджер должен обладать хорошим техническим бекграундом и техническими знаниями в своей предметной области. Во-первых, без этих знаний не получится принимать правильные решения на проекте. Во-вторых, это один из факторов, который отличает лидера, которому и команда, и Заказчик доверяют. В-третьих, менеджер должен быть в состоянии разговаривать на одном языке и с командой, и с представителями Заказчика. Любое отсутствие главного технического специалиста на проекте не должно тормозить проект, и менеджер должен в состоянии один провести встречу с Заказчиком и объяснить ему какое-нибудь техническое решение (тут в пределах разумного, конечно). Или наоборот, задать нужные вопросы для уточнения требований. Также технически подкованный менеджер может сразу на этапе идеи обосновать Заказчику возможность реализации того или иного функционала, а не тратить время на уточнение такой возможности у технических специалистов.
Менеджер должен понимать, где у Заказчика «болит» и как ему в этом помочь. Это значит уметь правильно собирать требования, обрабатывать их, находить пути решения проблем, описывать их, рассчитывать стоимость и защищать. Другими словами, участвовать в пресейле и расширять присутствие в Заказчике.
(в пресейле, конечно, работают не только РП)
Ещё один из немаловажных софт скиллов руководителя проекта – проактивность. Это значит предотвращать пожары, а не тушить их. Появился вопрос, что-то непонятно, появился риск, требуется согласование – сразу действуешь. То есть не тогда, когда появилась возможность спросить, риск реализовался, а согласование требований уже просрочено, а заранее. Звучит просто и логично, но этим навыком обладает меньше 20% менеджеров (среди других ролей этот процент ещё меньше).
Менеджер должен уметь анализировать и оптимизировать бизнес-процессы. Например, если он видит, что команда работает неэффективно, он должен сам понять причину, продумать, как можно улучшить ситуацию, описать, и, самое главное, внедрить это в жизнь.
В случае возникновения каких-либо проблем, менеджер должен не просто рассказывать о них, а продумывать варианты решений. Более того, у опытного менеджера в голове уже есть пул сформированных за годы работы шаблонов, как действовать в той или ной ситуации.
Менеджер должен следить за психологическим и эмоциональным состоянием своей команды, и знать, что необходимо делать в случае возникновения проблем из-за этого. Необходимо своевременно выявлять выгорание, конфликтные ситуации, а также недовольство и отвращение к выполняемой работе среди коллег. Более того, менеджер должен поддерживать комфортную рабочую атмосферу в команде.
Требование о «стрессоустойчивости» в описании вакансии на должность руководителя проектов – не дань моде. Менеджер отвечает за весь проект, с него спрашивает и руководство, и Заказчик (см. п.5), а ресурсов для реализации всегда не хватает (см. п.6). А ещё в условиях такого перманентного стресса надо правильные решения принимать, когда ничего непонятно (см. п.4). Так что уметь правильно справляться со стрессом – это рабочая необходимость.
Руководитель проекта должен обеспечивать работоспособный и эффективный рабочий процесс. Понятно, что аналитик может сам собрать требование у Заказчика, и вместе с архитектором поставить задачу разработчику. А когда нужно приступить к реализации какого-то функционала? А когда нужно начать обследование и согласование требований? А как учесть, в какой момент кто из исполнителей освободится, чтобы привлечь его к той или иной задаче? Взаимосвязей в проектах очень много. Особенно, если речь идёт о длительных и сложных проектах. И именно менеджер должен отслеживать все эти взаимосвязи и делать так, чтобы команда не буксовала, работала слаженно и эффективно.
Менеджер должен уметь правильно расставлять приоритеты. От этого очень сильно могут зависеть, как сроки, так и успех всего проекта. Почему сейчас инженер должен делать именно эту задачу, а тех.пис работать именно над этим документом? Как выбрать, над каким инцидентом работать в первую очередь? Как понять, почему сначала надо показать Заказчику одну задачу, а потом другую? Для того, чтобы правильно расставлять приоритеты, надо понимать весь объем задач, их взаимосвязи, ближайшие цели, понимать, что срочно и какие текущие ожидания у Заказчика, а также загрузку команды текущую и потенциальную.
