Каждый РП рано или поздно меняет работу. Вы уходите со старого места, где вы уже хорошо ориентируетесь, и приходите в неизвестность:

• неизвестный проект с неизвестными рисками;

• непонятный руководитель (при первом знакомстве он душка, но какой будет в реале?);

• непонятные коллеги;

• непонятный заказчик.

Причем, как правило, проект, который вам отдают, уже несется на всех парах: команда пашет, заказчик чего-то хочет, у нового руководителя какие-то ожидания. И хорошо, если все так просто. А часто случается, что проект уже летит в бездну, бюджет израсходован, заказчик всех ненавидит, а руководство ждет от вас сдачи на следующей неделе (да, такие случаи тоже бывали ?).

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть. Ну и на все про все у вас примерно 2 недели. 4 от силы, если место ванильное, и поезд еще не разогнался.

Как не свернуть шею и не попасть под колеса на этом славном пути – по пунктам ниже (обратите внимание на последовательность, она важна. Ее изменение может привести к ненужным рискам).

Шаги

0. Нулевое и самое важное: ничего никому не обещать две недели. Если на вас очень давят – неделю. Просто говорим: «я пока только вникаю, могу поглядеть, но обещать не могу». В первую неделю-две сказать это можно кому угодно, хоть вашему ГД: это разумно и аккуратно, вы не лезете туда, куда не знаете.

   Если же давят и требуют быстрого решения в первую неделю, это повод серьезно задуматься об адекватности тех, кто давит, и о том, а надо ли вам оставаться здесь вообще?
   Дольше 2х недель тоже тянуть не надо: нормальный менеджер не должен быть слоупоком.  2х недель вам должно хватить, чтобы разобраться в базе проекта.

1. Поговорить с непосредственным руководителем. Что он от вас ждет, что первоочередное и тд. Если он вам называет сроки и дедлайны в течение ближайших 1-3 недель не смейте их подтверждать: просто слушаете. Это обещали не вы, это не ваша ответственность. Но вы же опытный РП и помните, что «НЕТ, это невозможно» мы не говорим, мы говорим «окей, понял, я пойду погляжу, что там».

   1. Все ожидания вашего руководителя очень советую выписать отдельно. Они важны, по ним он будет вас оценивать по итогу испытательного срока. Если вы их достигнете – отлично. Если что-то не получается, надо будет подойти и попросить о помощи. Забывать про такое нехорошо.

2. Изучить внутренние регламенты, если они есть. Как правило, дня должно быть достаточно на уровне РП. Если вы тратите больше – вы медленный или регламенты невыполнимые. Если регламентов очень много, читать надо только то, что относится к вашей работе. Если их все равно много, не стесняйтесь спросить своего руководителя – зачем их много, и что из этого читать?

3. Дальше надо повтыкать в план проекта/проектов или продуктовый беклог и ТЗ. Так вы сами увидите даты, сроки, этапы, задачи, расставленные по приоритетам и вникнете в базовые функции, которые надо делать. На данном этапе в трекер лезть и смотреть детали еще рано. Просто надо понять сроки, дедлайны и планы на ближайшие месяца три и функционал «по диагонали», чтобы пойти к исполнителю.
   После этого вы готовы к пункту 4 ниже.

4. Поговорить с исполнителями. Это или ваша in-house команда или подрядчик. Цель встречи – вы собираете информацию о ходе дел, и какие есть проблемы.

   1. На встрече/встречах проверяете соответствие их слов плану. Если что-то не совпадает, задаете вопросы сразу. Во-первых, сразу покажете, что вы ориентируетесь, во-вторых, покажете, что хотите разобраться во всех мутных темах, в-третьих, проверите готовность команды идти вам на встречу (а то всякое бывает).

   2. Собираете их боли и проблемы. Отношения с командой или подрядчиками почти всегда болевая точка, очень важно всех выслушать. Вы приходите с чистой репутацией и можете использовать этот кредит доверия – вам много чего расскажут. Тоже все записываем, киваем головой, и ничего не обещаем. Но и не забываем: если просто послушаете и положите болт, все доверие между вами рухнет, не начавшись.

5. Читать контракт. Очень многие Руководители проектов забывают этот пункт, а он ключевой. На встречах вам все будут говорить свои сроки и потребности. Это надо выслушать, это – их ожидания. Но потом это все надо осадить на контрактные обязательства. Никто не будет помнить про ваши контракты кроме вас. В конце дня, когда подрядчик или ваш заказчик тыкнут вас в контракт, вам будет очень больно. Для меня – такая ошибка менеджера — это Желтая карточка. Два таких залета – испытательный не пройден, до свидания.

   1. Если вы на стороне интегратора – вы свой контракт должны знать наизусть в части функционала, этапов, денег и штрафняков.

   2. Если вы на стороне внутреннего ИТ или продукта:

      1. Изучите все обязательства поставщиков перед вами, чего бы они вам не рассказывали в пункте 4 выше.

      2. Изучите все обязательства, которые были даны вашему бизнесу в соответствии с процессами из п 2 выше. Функциональные требования, служебные записки, согласованные дорожные карты – но только те, что были согласованы формальным путем «по закону».

   Это – ваша база. Вы должны выполнить все, что формально обещано или записать это в проблемы/риски на изменение.

6. Поговорить с заказчиком. Основной заказчик – последний с кем надо встречаться. Туда надо идти готовым, имея за спиной результаты по всем пунктам выше. Причем от заказчика могут быть несколько ответственных, поговорить надо со всеми по очереди:

   1. РП заказчика, если такой есть. С ним лучше встретиться очно. Если он в том же городе – не поленитесь доехать. Он ваш главный заказчик, крайне важно наладить правильный контакт и понять все его боли и ожидания. Тоже – собираем фидбек, записываем, ничего не обещаем.

   2. Бизнес. Тут отдельно встречу собирать не надо, бизнесу, по идее, на вас плевать – ну сменился и сменился, «они там каждый раз новые, главное результат давайте». Здесь можно просто прийти на очередную встречу (сбор требований, статус) чтобы познакомиться. Если бизнес злой на ИТ команду, сами все увидите, а что не увидите – вам все скажут.

7. Далее берете паузу и обрабатываете полученную информацию:

   1. Эмоциональный настрой всех участников.

   2. Соответствие сроков в плане и задач в беклоге ожиданиям всех сторон.

   3. Соответствие сроков в плане и беклога контрактным и другим обязательствам.

   4. Соответствие процессов компании и реальной работы (если все мимо процессов – признак управленческого бардака).
      

   В этом месте, как правило, вас ждет много удивительных открытий. У меня, к примеру, было так, что вся команда забыла про контракт и работали «по понятиям». А бизнес заказчик ждал исполнения работ точно по контракту и ТЗ в нем. Вовремя обнаруженное расхождение удалось исправить.

8. Далее стоит поговорить с предыдущим РП, если такая опция доступна, и его не уволили до вас. Предыдущий РП, как правило, очень ценный источник информации, которому можно задать вопросы из пункта 7 выше. Но его надо очень аккуратно фильтровать: вы не знаете причин развода, и насколько стороны недовольны друг другом. Может быть РП не обладал достаточным опытом, чтобы тянуть проект, а может быть, заранее видит все проблемы и не хочет в этом балагане участвовать. В любом случае, его мнение тоже надо выслушать и учесть.

Уф. На все шаги, указанные выше, у вас должно уйти никак не менее недели:

1. Руководитель и регламенты

2. ТЗ и беклог «по диагонали»

3. Команда и подрядчики

4. Читать контракт

5. Заказчик

6. Обработка результатов, вопросы

7. Старый РП

8. В перерывах между этими встречами надо:

   1. Формулировать вопросы и готовиться ко встречам.

   2. Читать ТЗ, изучать беклог – чтобы понимать, а что вообще вам надо делать?

Если ушло меньше, то одно из трех: вам повезло и проект в идеальном состоянии, вы сделали шаги некачественно, проект небольшой.

9. Далее надо сформулировать проблемы и риски, которые вы видите. Пути решения предлагать не надо, просто список проблем, список рисков. С этим вы идете к руководителю и проговариваете, что он считает важным и почему, а что нет и что с этим делать (Как работать с Рисками смотри здесь).

   1. Если у Руководителя на это нет времени – повод задуматься о том, что онбоардинг в компании никакой, а вам придется работать с Руководителем, который не может найти времени на важные вопросы, подставляя себя (а оно вам надо?).

10. Формируете реальный список проблем и рисков с планом решения и пониманием, куда дальше идти.

11. Всегда СПРАШИВАЙТЕ!! Не бойтесь спрашивать, наоборот: все в курсе, что человек, который всех задалбывает вопросами, реально хочет разобраться. Дурак не тот, кто спрашивает, а тот, кто боится спросить. Ваш руководитель знает: если новый сотрудник не задает вопросы, скорее всего, он нифига не понимает и боится. Это плохая характеристика для вас. Так что спрашивайте, спрашивайте и спрашивайте.

В базе это все. Займет оно у вас от недели до трех.

Почему именно такая последовательность важна: потому что входом в каждый новый шаг будет информация от предыдущего. Бессмысленно идти к заказчику, если вы не понимаете ни проекта, ни сроков. Глупо идти к команде, если вы не поглядели ТЗ/беклог и примерно не поняли , о чем речь. Нельзя идти к РП заказчика, пока вы не поговорите со своей командой, иначе можно случайно ляпнуть что-то не то. Отдельно, выстраивая шаги именно так, вы будете максимально готовы к каждой встрече, а значит получите максимум информации. Это сэкономит время на вход в проект (не придется сто раз ко всем бегать) и покажется вас профессионалом: все четко, кратко, по делу.

Что имеем на выходе

При качественном исполнении шагов выше, вы:

1. Знаете сутевку проекта: цели, зачем он, кому он нужен, ожидания от него, основные функции и технические решения, обоснование бюджета и сроков.

2. Видите основные проблемы и риски проекта: техдолг, невыполненные обещания, невыполнимые обещания и несоответствие планов и ожиданий.

3. Понимаете, что надо делать для выравнивания планов и ожиданий.

4. Понимаете боли исполнителей и что вам надо делать, чтобы они успевали.

5. Очевидно понимаете, насколько реальные сроки и запланированный бюджет проекта.

А это то, что надо, чтобы не страшась плыть в светлое будущее с готовым планом по устранению проблем и рисков  (ну или отчаливать на испытательном со словами: «вы тут все рехнулись что-ли?!»).

*** - небольшой проект, где РП может выполнять роль аналитика – до 10-15 человек. Это может быть один проект на 15 чел. или три по 5, но больше - почти наверняка нет.

Всем удачи на новых проектах!