С чего начинать на новом месте (памятка для Руководителя проектов)
Нулевое и самое важное: ничего никому не обещать две недели. Если на вас очень давят – неделю. Просто говорим: «я пока только вникаю, могу поглядеть, но обещать не могу». В первую неделю-две сказать это можно кому угодно, хоть вашему ГД: это разумно и аккуратно, вы не лезете туда, куда не знаете.
Если же давят и требуют быстрого решения в первую неделю, это повод серьезно задуматься об адекватности тех, кто давит, и о том, а надо ли вам оставаться здесь вообще?
Дольше 2х недель тоже тянуть не надо: нормальный менеджер не должен быть слоупоком. 2х недель вам должно хватить, чтобы разобраться в базе проекта.
Поговорить с непосредственным руководителем. Что он от вас ждет, что первоочередное и тд. Если он вам называет сроки и дедлайны в течение ближайших 1-3 недель не смейте их подтверждать: просто слушаете. Это обещали не вы, это не ваша ответственность. Но вы же опытный РП и помните, что «НЕТ, это невозможно» мы не говорим, мы говорим «окей, понял, я пойду погляжу, что там».
Все ожидания вашего руководителя очень советую выписать отдельно. Они важны, по ним он будет вас оценивать по итогу испытательного срока. Если вы их достигнете – отлично. Если что-то не получается, надо будет подойти и попросить о помощи. Забывать про такое нехорошо.
Изучить внутренние регламенты, если они есть. Как правило, дня должно быть достаточно на уровне РП. Если вы тратите больше – вы медленный или регламенты невыполнимые. Если регламентов очень много, читать надо только то, что относится к вашей работе. Если их все равно много, не стесняйтесь спросить своего руководителя – зачем их много, и что из этого читать?
Дальше надо повтыкать в план проекта/проектов или продуктовый беклог и ТЗ. Так вы сами увидите даты, сроки, этапы, задачи, расставленные по приоритетам и вникнете в базовые функции, которые надо делать. На данном этапе в трекер лезть и смотреть детали еще рано. Просто надо понять сроки, дедлайны и планы на ближайшие месяца три и функционал «по диагонали», чтобы пойти к исполнителю.
После этого вы готовы к пункту 3 ниже.
Поговорить с исполнителями. Это или ваша in-house команда или подрядчик. Цель встречи – вы собираете информацию о ходе дел, и какие есть проблемы.
На встрече/встречах проверяете соответствие их слов плану. Если что-то не совпадает, задаете вопросы сразу. Во-первых, сразу покажете, что вы ориентируетесь, во-вторых, покажете, что хотите разобраться во всех мутных темах, в-третьих, проверите готовность команды идти вам на встречу (а то всякое бывает).
Собираете их боли и проблемы. Отношения с командой или подрядчиками почти всегда болевая точка, очень важно всех выслушать. Вы приходите с чистой репутацией и можете использовать этот кредит доверия – вам много чего расскажут. Тоже все записываем, киваем головой, и ничего не обещаем. Но и не забываем: если просто послушаете и положите болт, все доверие между вами рухнет, не начавшись.
Читать контракт. Очень многие Руководители проектов забывают этот пункт, а он ключевой. На встречах вам все будут говорить свои сроки и потребности. Это надо выслушать, это – их ожидания. Но потом это все надо осадить на контрактные обязательства. Никто не будет помнить про ваши контракты кроме вас. В конце дня, когда подрядчик или ваш заказчик тыкнут вас в контракт, вам будет очень больно. Для меня – такая ошибка менеджера — это Желтая карточка. Два таких залета – испытательный не пройден, до свидания.
Если вы на стороне интегратора – вы свой контракт должны знать наизусть в части функционала, этапов, денег и штрафняков.
Если вы на стороне внутреннего ИТ или продукта:
Изучите все обязательства поставщиков перед вами, чего бы они вам не рассказывали в пункте 3 выше.
Изучите все обязательства, которые были даны вашему бизнесу в соответствии с процессами из п 2 выше. Функциональные требования, служебные записки, согласованные дорожные карты – но только те, что были согласованы формальным путем «по закону».
Это – ваша база. Вы должны выполнить все, что формально обещано или записать это в проблемы/риски на изменение.
Поговорить с заказчиком. Основной заказчик – последний с кем надо встречаться. Туда надо идти готовым, имея за спиной результаты по всем пунктам выше. Причем от заказчика могут быть несколько ответственных, поговорить надо со всеми по очереди:
РП заказчика, если такой есть. С ним лучше встретиться очно. Если он в том же городе – не поленитесь доехать. Он ваш главный заказчик, крайне важно наладить правильный контакт и понять все его боли и ожидания. Тоже – собираем фидбек, записываем, ничего не обещаем.
Бизнес. Тут отдельно встречу собирать не надо, бизнесу, по идее, на вас плевать – ну сменился и сменился, «они там каждый раз новые, главное результат давайте». Здесь можно просто прийти на очередную встречу (сбор требований, статус) чтобы познакомиться. Если бизнес злой на ИТ команду, сами все увидите, а что не увидите – вам все скажут.
Далее берете паузу и обрабатываете полученную информацию:
Эмоциональный настрой всех участников.
Соответствие сроков в плане и задач в беклоге ожиданиям всех сторон.
Соответствие сроков в плане и беклога контрактным и другим обязательствам.
Соответствие процессов компании и реальной работы (если все мимо процессов – признак управленческого бардака).
В этом месте, как правило, вас ждет много удивительных открытий. У меня, к примеру, было так, что вся команда забыла про контракт и работали «по понятиям». А бизнес заказчик ждал исполнения работ точно по контракту и ТЗ в нем. Вовремя обнаруженное расхождение удалось исправить.
Далее стоит поговорить с предыдущим РП, если такая опция доступна, и его не уволили до вас. Предыдущий РП, как правило, очень ценный источник информации, которому можно задать вопросы из пункта 6 выше. Но его надо очень аккуратно фильтровать: вы не знаете причин развода, и насколько стороны недовольны друг другом. Может быть РП не обладал достаточным опытом, чтобы тянуть проект, а может быть, заранее видит все проблемы и не хочет в этом балагане участвовать. В любом случае, его мнение тоже надо выслушать и учесть.