Самый главный, и при том самый туманный вопрос – что должен делать менеджер проектов. В идеале, и в компаниях живущих “по канонам” руководитель проектов – высококвалифицированный специалист, тим-лид с развитыми софт-скилами (например, переговоры и психология), отвечающий за реализацию проекта в целом. В реальных условиях, помимо основных функций, менеджеру проектов могут поручить и работу на пресейле (сбор требований от заказчика), и курирование юридических вопросов.
Если ты работаешь в компании более-менее долго, ты знаешь, как все устроено изнутри и чего от тебя ждут. Вряд ли даже как-то акцентируешь на этом внимание. Но если ты только что пришел из другой организации (как я, пару месяцев назад), будешь сталкиваться с теми, кто привык к своему укладу (и не думает о том, что бывает иначе), и ожидает от тебя то, о чем заранее не предупредили. Часто узнаешь об этом уже в процессе. Хуже – если не узнаешь, когда претензии остаются за кадром.
Всякий менеджерский контент в телеграме: @zapostil
Ведение проекта
Управление проектами обычно ведется либо по одной из двух основных методологий – ”водопад” и набирающий популярность скрам/эджайл. Однако, чаще встречаются ситуации, когда никакой конкретной методологии нет, и проекты ведутся либо интуитивно (как придется), либо по гибридным техникам, придуманным внутри компании.
При смене компании имеет смысл выяснить, что используется конкретно здесь. Даже если вы привыкли всегда вести проекты по эджайлу, а в компании работают по водопаду, попытка принести свой уклад вызовет непонимание. При прохождении испытательного срока это может быть фатально. Сначала приноравливаемся к тому, что происходит в компании, со временем исправляем под себя – если это необходимо, и есть соответствующий опыт.
Работа с командой
Работа с командой в любом случае остается главной вотчиной руководителя проектов. Что бы ни происходило за пределами компании (например, в плане соприкосновения с клиентами), команда всегда остается на месте. Менеджер проектов это часть команды, с расширенной ответственностью за результаты ее работы. Потому отношениям внутри уделяем большое внимание. При том, чаще всего в зону ответственности менеджера проектов не входит возможность увольнения или поощрения участников команды.
При переходе в новую компанию, нужно выяснить границы ответственности и в направлении работы с командой. Менеджер может быть как полноценным руководителем, так и фактически помощником высшего руководства. В последнем случае, оно будет вмешиваться в ведение проекта, и перетягивание одеяла на себя создаст проблемы не только с командой, но и с руководством.
Помимо непосредственной команды разработки, в компании есть и другие люди, прямо или косвенно влияющие на работу. Например, может показаться, что системный администратор отстоит отдельно от команды. Однако, если возникнут проблемы, к которым нужно будет его подключить – придется побыть в роли фасилитатора. Точно так же с техническим обеспечением команды. Хорошей практикой является разговор “по душам”, где участник рабочей группы сможет рассказать тебе с глазу на глаз о проблемах, появляющихся в процессе реализации проекта.
Работа с клиентом
На стороне клиента может оказаться как их топ-менеджмент, так и такой же проджект, только с другой стороны. В запущенном случае, на той стороне будет команда разработки клиента. В самом запущенном – будет третья компания, обеспечивающая разработку для клиента. Не всегда понятно на старте, что хуже, но то, что тебе придется воспринимать клиента/его разработчиков как часть команды проекта должно быть понятно всегда. Клиент здесь выступает заказчиком и владельцем продукта, с которым у вас общая цель – сделать проект. А команда разработки = такая же команда разработки, которая встроится во внутреннюю рабочую группу. В идеале через одного человека с той стороны – например, тимлида.
Если компания работает с клиентом давно, клиент скорее всего знаком и с командой разработки, и с руководством. Действовать нужно по ситуации – где-то это и нормально, а где-то коммуникацию нужно полностью забирать на себя. Даже если коммуникация между другими участниками команды и клиентом сохраняется, нужно держать руку на пульсе. Например, не допускать переписок и созвонов между клиентом и специалистом тет-а-тет. Это поможет не терять роли и отслеживать отношения между людьми. У клиента может быть обиды на разработчика и наоборот – их придется либо решать, либо (в крайнем случае) менять разработчика на проекте. То, что под участником твоей команды подразумевается твой же директор – ничего не меняет. Если у тебя получится сделать так, что все вопросы будут решаться на твоем уровне, “спасибо” скажут обе стороны: за повышение скорости реакции для клиента и снятие рутинных задач для руководства.
В чем нужно разобраться при смене компании
Главный и лучший инструмент руководителя проектов – коммуникация. Со многими вещами можно разобраться, просто поговорив – с непосредственным руководством, с выгодополучателями, с коллегой за соседним столом. При работе с клиентом это работает точно так же: о его ожиданиях можно узнать, спросив о них напрямую. Считать, что ты покажешься непрофессионалом в их глазах не стоит. Наоборот, если выстраивать свою репутацию как во всем разбирающегося человека, и однажды не совпасть в поведении с репутацией, намного хуже.
- Какая методология используется
- Как выстроен процесс (как проект приходит в компанию, кто участвует в продаже, как решаются юридические и бухгалтерские задачи, что согласовываем с руководством, как оцениваем задачи, процессы закрытия проектов – особенно, если в компании есть проектный офис)
- Какие решения может принимать менеджер проектов, какие эскалируются наверх
- Какие технологии считаются в компании/департаменте основными
- Если клиент внешний – корректно ли подключать к коммуникации с ним ребят из команды разработки
- Что по поводу отчетности. Нужно ли, например, сдавать тайм-трекинг отдельно?
Сопутствующие работе процессы
Под этим понятием понимаю, в первую очередь, юридическую и бухгалтерскую службы. Здесь два варианта: либо они самостоятельны, и им можно передавать задачи, отпуская и коммуникацию с клиентом, либо не самостоятельны и все потребуется пропускать через себя. Второй вариант зачастую встречается в небольших компаниях.
В первом случае не пытаемся контролировать работу – только что напоминалки в тик-тик о том, на каком этапе находятся их задачи, если они могут повлиять на работу. Плюс, готовность прийти на помощь, если таковая потребуется. Во втором случае, это отдельный процесс, в нюансах которого разбираемся в каждом отдельном случае (компании). Здесь вопросы юридического и бухгалтерского характера превращаются в небольшие проекты внутри основных проектов – со всеми вытекающими.
Что еще?
Всего может быть тысяча обязанностей, о которых ты не предполагал, когда проходил курсы по УП, или работал на предыдущем месте. Однажды я сталкивался с ситуацией, когда менеджер проектов оказался ответственным за контент на сайте. Там я, конечно, не задержался, но работать ли в месте, где ожидание и реальность расходятся – выбор выбирающего. Менеджер проектов слишком общее понятие, для того чтобы точно знать, что тебя ждет в работе. Плюс к тому, менеджер проектов – роль, которая встречается в целой плеяде направлений работы – от диджитальных разработки/рекламы (где специфика работы абсолютно разная), до строительства и тяжелого машиностроения (где работают ребята, с которыми мы занимаемся кардинально разными вещами). И в каждом месте будет что-то свое.
Всякий менеджерский контент в телеграме: @zapostil
