Проектный Менеджер в IT. Обязанности без полномочий
Как появилась идея написать статью
Мне захотелось осмыслить свой опыт и те системные проблемы с которыми я сталкивался работая на позиции проектного менеджера (ПМа) в IT. Практически всегда я видел похожую картину — руководитель компании хотел передать часть ответственности линейному менеджменту, чтобы освободить себя для более стратегических задач. Поскольку работа в IT чаще всего проектная, найти ПМа кажется логичнее всего. Ищут человека, который не боится брать ответственность за проект целиком. При этом, остальные процессы в компании (инициация проекта, подписание контрактов) практически не меняются и остаются завязаны на ТОП менеджменте. В итоге к ПМу проект приходит на стадии, когда уже все решено: определена команда, выстроены ожидания заказчика, цель проекта, бюджет. И далее ПМ работает с тем что есть, не имея полномочий изменить состав команды, бюджет проекта, заказчика.
Но без делегирования полномочий не решается проблема загруженности ТОП менеджмента. Происходит интересная ситуация, когда есть человек «отвечающий» за проект, но все решения принимает ТОП менеджмент. Проблема становиться менее видимой, потому что «виноват» во всех принятых решениях ПМ. ПМ, как правило, ответственный человек, то он упорно ищет причины неудач в себе. В компании могут звучат красивые слова про то, что каждый может повлиять на ситуацию, у нас Lean, Agile и вот это все. Но это только мешает увидеть несоответствие обязанностей и полномочий.
Тут можно было бы поставить точку в статье и сказать, что все решается должностными инструкциями, описанием ролей, но это скучно. И все мастерство заключается не в инструментах, а в том как их применять на реальной ситуации. А для того чтобы применить их, нужно сперва увидеть что вообще происходит. О чем я и напишу.
Кстати, я слышал что в строительстве дела с ПМами обстоят лучше. Буду рад, если кто-то поделиться в комментариях.
Название роли
В случае с ролями, очень важно найти подходящее название роли ее назначение. У этого выбора есть свои последствия:
Публикуется резюме с этим заголовком
На него откликнется Вася, который прошел курсы по управлению проектами. На этих курсах ему сказали, что он отвечает за исполнение контракта (проектный треугольник: график, бюджет, объем работ), работу с командой, стейкхолдерами.
Васю поставят ПМом на проект Х. А внутри компании у всех сформируются ожидание, что теперь за проект Х отвечает Вася. Он им управляет, чтобы это не значило.
Если на проекте появится проблема, то все будут смотреть на Васю и ждать что он ее решит.
Давайте разберемся в названиях. Меня часто называли ПМом, но как бы называлась роль в соответствии с ее полномочиями?
Администратор
Бывает, что ТОП менеджмент хочет отдать ПМу функцию контроля за сроками и бюджетом. Фактически это выглядит так, что ПМ собирает отчеты о производительности команды и расходу бюджета. Много механистической работы, в которой, опять же нет принятия решений, а есть отправка отчетов ТОП менеджменту и информирование команды о том, что мы работаем согласно плану или отстаем от него. Поскольку на состав команды ПМ повлиять не может, то ему остается надеется на благоразумность каждого участника, проводить мотивационные беседы или же эскалировать проблему выше, находя в компании людей, которым не все-равно на проект, за который он несет ответственность. Тут он может перерасти в роль консультанта.
Консультант
Если ПМу повезет со своими навыками, окружением и своим влиянием, то он становиться консультантом. То есть, опять же, из-за отсутствия полномочий он своими руками ничего сделать не может, но зато может сделать руками других людей. Собственно это то, чем и занимаются консультанты. Это не плохо и не хорошо. Просто консультант не может отвечать за реализацию целей проекта, он может отвечать только за информированность всех участников процесса о проблемах и рисках.
Scrum Master
Когда у ПМа появляется экспертиза в гибких методологиях, то из роли простого консультанта он может стать консультантом по Scrum, Agile, Lean. Здесь появляется еще одна несостыковка, ведь в философии Agile нет проектного менеджера. Попадая в такую ситуацию, я обычно использовал роль-костыль «внутренний product owner», поскольку был не только хранителем процессов, но и коммуницировал команде приоритеты.
Бизнес Аналитик
Ответственный ПМ зачастую затыкает собой все пробелы между бизнесом и инженерами. Один из таких пробелов — это работа с требованиями и преобразование бизнес требований в технические задачи. В таком случае ПМ становится не только носителем эксперитизы по выстраиванию процессов производства, но и экспертом в доменной области проекта. Здесь он становится непосредственным участником производства продукта как на этапе постановки задачи, так и на этапе валидации результатов.
Какие полномочия имеет смысл делегировать ПМу
Я напишу о двух полномочиях, которые наиболее ярко проявлялись в моем опыте и которые, в моем понимании, превращают Консультанта в Менеджера Проекта.
Валидация и контроль договоренностей
Бывало так, что я не был вовлечен в составление контракта и инициацию проекта. Клиент договаривается о всех условиях контракта с одним человеком, а реализует его другой. В IT я сталкивался с этим как со стороны исполнителя, так и со стороны заказчика. Вводить дополнительные слои коммуникации в IT считается нормой.
Порой клиент сталкивается с такой цепочкой:
Sales→Account Manager→Solution Architect→PM c пресейла→ PM производства → команда
Передача информации и контекста между разными ролями — это сложная задача. На старте проекта формируются ожидания всех стейкхолдеров, создается общее видение, доверие. Как правило, много нюансов в ожиданиях и договоренностях остается в устной форме. В случае аутсорсинговых компаний, ситуация усугубляется еще тем, что есть задача «продать» себя, пообещать максимум из того что мы можем сделать. Конфликт между продажами и производством хрестоматийный и требует создание дополнительных связей между людьми работающими в продаже и производстве.
Чем раньше ПМ и команда вовлечены в коммуникацию, тем более синхронизированы они будут относительно целей проекта. Как правило после старта у всех есть ощущение что все уже обсудили и задавать «глупые» вопросы кажется не комильфо.
Совет ПМам, которым пришел уже подписанный контракт: устройте себе «медовый месяц» со всеми стейкхолдерами. Не бойтесь показаться тупыми, поймите на что тут вообще подписались и насколько, по вашему, реально соблюсти эти договоренности, можно ли сейчас, текущими ресурсами решить задачу такой сложности?
Самые частые и дорогие ошибки происходят из-за того, что люди усердно делают вид, что понимают друг друга.
Определение и изменения состава команды
Люди в IT это основной ресурс, главный риск и соответственно фактор определяющий производительность, маржинальность и успех проекта. Логично предположить, что у ПМа должны быть полномочия по изменению состава команды, но это далеко не всегда так. Я встречал ситуацию, где была отдельная роль — ресурсный менеджер. Этот человек следит за тем, чтобы все инженеры были заняты и пытался балансировать «занятость» с интересами проектов. У такой роли есть фокус на показателях процента бенча, общей маржинальности компании, но нет в фокусе целей отдельных проектов. Это приводит к усреднению результатов проектов и постоянным ротациям. Плюс добавляется сорревновательность за ресурсы между проектными менеджерами — побеждает самый убедительный или тот, у кого сложился хороший контакт с ресурсным менеджером.
Так же, у меня был опыт, когда я сам открывал вакансии, собеседовал инженеров и строил команду — в этом случае получилось сделать результативную команду, где есть доверие, хорошая групповая динамика и ресурс для решения сложных задач.
Делегирование полномочий VS пропаганда влияния
Делегирование полномочий — это изменение\создание таких бизнес процессов в которых у ПМа есть возможность принять решение и есть ресурсы на его осуществление.
Пропаганда влияния — это слова о том, что мы Lean, Agile, о том, что каждый может повлиять на процесс. Но без соответствующего бизнес процесса и ресурсов необходимых для осуществления этого влияние.
Пока встречи с обсуждением состава команды проходят без ПМа и контракты согласовываются без участия ПМа, ни какие Agile-Lean практики не сделают работу этой роли результативной.
Самоуправление и самоорганизация
В моем понимании, хороший менеджер — это тот, который смог выстроить структуру работающую самостоятельно, без его участия. Эволюционная цель ПМа, которая мне откликается — сделать так, чтобы роли ПМа больше не понадобилось. Путь к самоуправлению долог и тернист, у меня тут нет достаточной экспертизы и опыта, чтобы описать его целиком. Тем не менее пересмотр организационной структуры и ролей занимает в этом пути немаловажную роль. Мне хочется верить, что эта статья может помочь в том числе и с этим процессом. В случае с самоуправлением делегирование полномочий может производиться не отдельному человеку, а проектной команде целиком. Роли ПМа может не быть, а вместо него можно добавить, к примеру, бизнес аналитика и сделать переходящей роль фасилитатора встреч. Можно почерпнуть конкретные реализации таких организационных структур в сообществе практиков Социократии 3.0. В международном сообществе регулярно проходят вебинары на которых компании делятся своим успешным опытом и граблями, которые они насобирали.
