Это грустно, но факт – очень часто можно столкнуться с ситуацией, когда РМ от подрядчика откровенно “не тянет”, чуть что – просит понять и простить, выполняет роль формального администратора и не может управлять командой. Не вдаваясь в то, почему так происходит – давайте подумаем, что с этим можно сделать, чтобы ваш проект пострадал как можно меньше?
Во-первых – договор и еще раз договор
В идеале ответственность руководителя проекта со стороны подрядчика и подрядчика вообще должна быть прописана в плане управления проектом и в контракте (план может идти приложением к контракту). Необходимо четко разделять задачи заказчика и исполнителя, тогда при недоработке РМ от исполнителя это относительно легко решается эскалацией и заменой ресурса. Особенное очарование этом методу придает то, что, по крайней мере, в моем опыте, в большинстве компаний контракт подписывается после прочтения менеджером, ответственным за продажу (в лучшем случае – юристом), руководителю проекта или производственному подразделению на согласование он почти никогда не доходит. Продажники и юристы, понятное дело, в детали не вникают, а у вас появляется возможность вписать все, что нужно – регулярность коммуникации, SLA на ответы на почту и звонки, процессы передачи результатов, количество и регулярность встреч в офисе, процессы замеры ресурсов и все что угодно. Один раз написав внятное приложение к договору, вы получаете мощный работающий инструмент воздействия на подрядчика в любом проекте. Причем применять все свои же драконовские требования необязательно, при адеквате другой стороны работа будет идти в нормальном режиме и без того. Но наличие бумажки греет и, как показывает практика, спасает в самые неожиданные моменты.
Во-вторых – и снова договор
Если в договоре в самом начале вы по каким-то причинам ответственность РМа со стороны подрядчика не зафиксировали – на самом деле не поздно это сделать в любой момент. Можно начать со встречи, на которой проговорить ожидания от этой роли (хорошо, если на ней будет аккаут-менеджер), зафиксировать это в протоколе и предложить закрепить в дополнительном соглашении к договору. Тут уже есть вероятность, что подрядчик скажет, что он в оценку ваши условия не закладывал, и придется решить, что вам дороже – бюджет проекта или снижение рисков.
В-третьих – не делать не свою работу
Лучший способ получить головную боль до конца проекта – это начать управлять людьми подрядчика или выполняет задачи РМа со стороны подрядчика самому. Даже если договора нет – есть общепринятые требования к работе РМа, и все он этим требованиям не отвечает – это повод поднять вопрос о том, чтобы заменить сотрудника на проекте. Я как-то давно наступала на эти грабли, опомнилась только когда поняла, что разработчики со стороны подрядчика уже несколько месяцев отпрашиваются у меня с работы (!), предъявляют претензии по выплате премий, просят организовать им выдачу новых ноутбуков, чтобы вовремя сделать работу по проекту, сбалансировать нагрузку по другим проектам (выполняемым для моей компании, но ситуацию это не меняет), решить конфликты с группой тестировщиков и проч. Хорошо, что это было давно, с тех пор я стала умнее. В той ситуации оставалось только менеджером продукта самой еще стать, чего уж мелочиться. Теперь при первом запросе я вежливо шлю к PMу подрядчика, при втором – обсуждаю это с тем самым РМом (почему вопрос не решен), при третьем – поднимаю вопрос о замене. Даже если в реальности замена не нужна – все в этот момент напрягаются и начинают работать лучше.
В-четвертых – не бояться принять радикальное решение
Если РМ подрядчика недорабатывает в самом начале и одной воспитательной беседы оказалось недостаточно – меняйте сразу, пока он не сильно погружен в проект, дальше это будет делать сложнее, а лучше вряд ли станет. В моей практике не было ни одного случая внезапного улучшения, по крайней мере. Мысли «а вдруг я зря обидела человека» лучше оставить за бортом этой профессии, за проект перед конечным заказчиком ответственность несете именно вы, и принимать решение именно вам.
P.S. Достаточно специфический кейс, но все-таки напишу здесь, отдельного поста он недостоин. Нечасто, но встречаются компании, в которых разные направления разработки автономны, то есть вы получаете несколько групп автономно работающих сотрудников, рулить которыми приходится вам. Такую ситуацию лучше распознать и пресечь в самом начале, золотое правило «1 подрядчик = 1 РМ, ответственый за все» должно соблюдаться в 100% случаев. Вам неинтересна внутренняя структура и внутренние разборки этой компании, вам нужен от них результат, и за этот результат должен быть только один ответственный. Плюс для ИТ-проектов – в проекте со стороны подрядчика также должен быть человек, который от и до понимает архитектуру решения, иначе вероятность серьезных ошибок вырастает в разы.
Добавить комментарий