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

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

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

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

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

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

Шаги

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

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

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

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

- Поговорить с исполнителями. Это или ваша in-house команда или подрядчик. Цель встречи – вы собираете информацию о ходе дел, и какие есть проблемы. На встрече/встречах проверяете соответствие их слов плану. Если что-то не совпадает, задаете вопросы сразу. Во-первых, сразу покажете, что вы ориентируетесь, во-вторых, покажете, что хотите разобраться во всех мутных темах, в-третьих, проверите готовность команды идти вам на встречу (а то всякое бывает).Собираете их боли и проблемы. Отношения с командой или подрядчиками почти всегда болевая точка, очень важно всех выслушать. Вы приходите с чистой репутацией и можете использовать этот кредит доверия – вам много чего расскажут. Тоже все записываем, киваем головой, и ничего не обещаем. Но и не забываем: если просто послушаете и положите болт, все доверие между вами рухнет, не начавшись.

- Читать контракт. Очень многие Руководители проектов забывают этот пункт, а он ключевой. На встречах вам все будут говорить свои сроки и потребности. Это надо выслушать, это – их ожидания. Но потом это все надо осадить на контрактные обязательства. Никто не будет помнить про ваши контракты кроме вас. В конце дня, когда подрядчик или ваш заказчик тыкнут вас в контракт, вам будет очень больно. Для меня – такая ошибка менеджера — это Желтая карточка. Два таких залета – испытательный не пройден, до свидания. Если вы на стороне интегратора – вы свой контракт должны знать наизусть в части функционала, этапов, денег и штрафняков. Если вы на стороне внутреннего ИТ или продукта: Изучите все обязательства поставщиков перед вами, чего бы они вам не рассказывали в пункте 4 выше. Изучите все обязательства, которые были даны вашему бизнесу в соответствии с процессами из п 2 выше. Функциональные требования, служебные записки, согласованные дорожные карты – но только те, что были согласованы формальным путем «по закону». Это – ваша база. Вы должны выполнить все, что формально обещано или записать это в проблемы/риски на изменение.

- Поговорить с заказчиком. Основной заказчик – последний с кем надо встречаться. Туда надо идти готовым, имея за спиной результаты по всем пунктам выше. Причем от заказчика могут быть несколько ответственных, поговорить надо со всеми по очереди: РП заказчика, если такой есть. С ним лучше встретиться очно. Если он в том же городе – не поленитесь доехать. Он ваш главный заказчик, крайне важно наладить правильный контакт и понять все его боли и ожидания. Тоже – собираем фидбек, записываем, ничего не обещаем. Бизнес. Тут отдельно встречу собирать не надо, бизнесу, по идее, на вас плевать – ну сменился и сменился, «они там каждый раз новые, главное результат давайте». Здесь можно просто прийти на очередную встречу (сбор требований, статус) чтобы познакомиться. Если бизнес злой на ИТ команду, сами все увидите, а что не увидите – вам все скажут.

- Далее берете паузу и обрабатываете полученную информацию: Эмоциональный настрой всех участников. Соответствие сроков в плане и задач в беклоге ожиданиям всех сторон. Соответствие сроков в плане и беклога контрактным и другим обязательствам. Соответствие процессов компании и реальной работы (если все мимо процессов – признак управленческого бардака).В этом месте, как правило, вас ждет много удивительных открытий.
У меня, к примеру, было так, что вся команда забыла про контракт и работали «по понятиям». А бизнес заказчик ждал исполнения работ точно по контракту и ТЗ в нем. Вовремя обнаруженное расхождение удалось исправить.
- Далее стоит поговорить с предыдущим РП, если такая опция доступна, и его не уволили до вас. Предыдущий РП, как правило, очень ценный источник информации, которому можно задать вопросы. Но его надо очень аккуратно фильтровать: вы не знаете причин развода, и насколько стороны недовольны друг другом. Может быть РП не обладал достаточным опытом, чтобы тянуть проект, а может быть, заранее видит все проблемы и не хочет в этом балагане участвовать. В любом случае, его мнение тоже надо выслушать и учесть.

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

  1. Руководитель и регламенты
  2. ТЗ и беклог «по диагонали»
  3. Команда и подрядчики
  4. Читать контракт
  5. Заказчик
  6. Обработка результатов, вопросы
  7. Старый РП
  8. В перерывах между этими встречами надо:Формулировать вопросы и готовиться ко встречам.Читать ТЗ, изучать беклог – чтобы понимать, а что вообще вам надо делать?

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

  1. Далее надо сформулировать проблемы и риски, которые вы видите. Пути решения предлагать не надо, просто список проблем, список рисков. С этим вы идете к руководителю и проговариваете, что он считает важным и почему, а что нет и что с этим делать (Как работать с Рисками смотри здесь).Если у Руководителя на это нет времени – повод задуматься о том, что онбоардинг в компании никакой, а вам придется работать с Руководителем, который не может найти времени на важные вопросы, подставляя себя (а оно вам надо?).
  2. Формируете реальный список проблем и рисков с планом решения и пониманием, куда дальше идти.
  3. Всегда СПРАШИВАЙТЕ!! Не бойтесь спрашивать, наоборот: все в курсе, что человек, который всех задалбывает вопросами, реально хочет разобраться. Дурак не тот, кто спрашивает, а тот, кто боится спросить. Ваш руководитель знает: если новый сотрудник не задает вопросы, скорее всего, он нифига не понимает и боится. Это плохая характеристика для вас. Так что спрашивайте, спрашивайте и спрашивайте.

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

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

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

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

  • Знаете сутевку проекта: цели, зачем он, кому он нужен, ожидания от него, основные функции и технические решения, обоснование бюджета и сроков.
  • Видите основные проблемы и риски проекта: техдолг, невыполненные обещания, невыполнимые обещания и несоответствие планов и ожиданий.
  • Понимаете, что надо делать для выравнивания планов и ожиданий.
  • Понимаете боли исполнителей и что вам надо делать, чтобы они успевали.
  • Очевидно понимаете, насколько реальные сроки и запланированный бюджет проекта.

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

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

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

11
Начать дискуссию