Что ты на самом деле принимаешь
Документы в папке проекта описывают только часть того, что достаётся новому PM. Вместе с проектом приходят обещания, которые уже даны заказчику, решения, принятые в переписке и нигде не записанные, и договорённости с людьми, часть которых устная. Устав может быть формально утверждён, но если с тех пор менялись приоритеты, он описывает уже другой проект.
Поэтому первая задача — разделить четыре группы: что обещано, что решено, что сделано и что только числится. Для каждой группы свой источник. Обещания ищи в переписке за последние три месяца, решения в протоколах и журнале решений, сделанное в приёмке и у пользователя, а числящееся в отчётах, где статус зелёный без подтверждения.
- Обещания: письма и звонки, где назван срок или объём, даже если в протоколе этого нет.
- Решения: то, что все считают согласованным, но без записи и подписи.
- Сделанное: только то, что принято заказчиком или работает у пользователя.
- Числящееся: пункты в трекере без владельца или открытые дольше двух недель.
День 1: аудит до первых разговоров
Аудит — это список вопросов, а не документ на сорок страниц. Первый день уходит на чтение: реестр рисков, последние статусы, устав, план, переписка с заказчиком. Вопросы записывай сразу и рядом с тем, кому их задать. Так ты не тратишь время руководителя на то, что можно найти в папке.
В симуляторе это день 1. Ноутбук и доступы приходят не сразу, а техлид Сергей пишет с утра: «Если хочешь понять, что тут происходит, начни с реестра рисков, а не с планов». Совет работает и вне симулятора: реестр рисков показывает, чего люди боятся, а план показывает, о чём договаривались.
Первая встреча с руководителем: план на четырнадцать дней
Руководителю нужны не рассказ о прошлом, а ответ на два вопроса: что ты сделаешь за две недели и что уже понятно о причинах. Тому нужны пятнадцать минут без презентаций, поэтому говори в таком порядке: план с датами, первый результат, причины, которые уже видны, и то, что пока не обещаешь.
В симуляторе Том даёт две недели и говорит, что ищет нового PM, если не увидит результата. Отвечать на это лучше не про сроки проекта, а про то, что будет показано и когда. Например: «К пятнице сверю обязательства перед заказчиком и пришлю список. К среде назову даты, которые подтвердит команда. Первый результат — список от команды: что блокирует работу сейчас».
- Что выясню: обязательства перед заказчиком, открытые решения, состояние людей и денег.
- С кем поговорю: каждый участник команды и тот, кто со стороны заказчика подтверждает приёмку и даты.
- Что покажу к дате: один документ, а не презентацию.
Первые 1:1: спрашивать факты, а не мнения
Каждому участнику команды на первой неделе нужна получасовая встреча. Ты не проводишь опрос и не ведёшь протокол на весь разговор. Ты задаёшь несколько вопросов, ответы на которые можно проверить. Фраза «всё нормально» ничего не сообщает. Фраза «в прошлом месяце приёмку сдвигали дважды, из-за чего это было?» сообщает многое.
Исправлять по ходу разговора не нужно. Собеседник начнёт отвечать так, чтобы понравиться, а не помочь. Записывай ответы в ту же таблицу, что и аудит, и только потом решай, что делать.
- Что в твоей работе сейчас стоит, и почему?
- Какая твоя задача, если её не сделают, сломает чужую работу?
- Какой документ ты открываешь каждый день, а какой лежит нетронутым с весны?
- Что ты больше не делаешь, потому что никто не отвечает?
День 2: что делать с уставом, который устарел
Не переписывай устав целиком. Сначала отметь, какие пункты ещё действуют: цели, которые никто не оспаривает, границы, которые заказчик подтвердил, ограничения, видимые из реальных данных. Остальное помечай как «требует подтверждения» и назначай владельца на каждый такой пункт.
В симуляторе устав прошлого PM лежит в Confluence, но после трёх смен приоритетов его никто не утверждал. На второй день Том просит пересобрать устав за два дня, а Фарида, основной контакт заказчика, даёт двадцать минут. Её первый вопрос: что в новом уставе и почему на этот раз будет иначе. Работающий ответ называет не дату, а условие: от чего зависит дата первой поставки и к какому дню её подтвердят.
Разговор с тем, кто знает больше всех
В каждой команде есть человек, который помнит историю проекта и уже рассказывал её нескольким новичкам. Такой разговор полезен, если ты задаёшь вопросы о фактах, а не просишь подтвердить свою версию. Спрашивай, что сломано на самом деле, что уже пробовали, кто что обещал и что из обещанного выполнено.
В симуляторе Сергей открывает встречу фразой: «Слушай, я четвёртый раз рассказываю про этот проект новому человеку. Скажи сразу: ты здесь, чтобы разбираться, или чтобы писать план?» Честный ответ здесь: разбираться. Сроков пока не назову, назову, когда буду знать, от чего они зависят, и к какому дню это будет.
Письмо команде: что написать и чего не обещать
Первое письмо команде короткое. Оно говорит, кто ты, как будешь работать две недели, что попросишь от каждого и что пока не делаешь. Главное правило: до аудита не давать новых сроков. Даты появятся, когда за ними будут цифры тех, кто их выполняет.
Вариант, который можно адаптировать: «Коллеги, я новый PM на проекте. Первые две недели читаю документы и встречаюсь с каждым из вас на полчаса 1:1. Попрошу назвать, что мешает работе, и что бы вы исправили первым. Ссылки присылайте на источник, а не на копии файлов. Если обязательство перед заказчиком под угрозой, скажите мне в день, когда узнали. Новые даты назову после сверки с вашими оценками».
Признаки, по которым видно, что проект буксует
Эти сигналы стоит записывать в первый же день, потому что к концу месяца они становятся фоном и перестают удивлять. Поставок не было дольше трёх месяцев, а отчёты зелёные. Деньги учтены, но прогресс с ними никто не сверял. Документы устарели, и по ним никто не работает. Ключевые люди на полставки или в отпуске, а задачи висят на них.
В симуляторе на старте именно такая картина: четыре месяца без поставки пользователю при статусе Amber в отчётах, BA в отпуске, DevOps на полставки. Если записать это списком фактов с датами, а не тревожным тоном, руководитель и ты будете говорить об одном и том же.
Конец второй недели: что показать одним документом
Через две недели у тебя должен быть один документ, который объясняет проект в том виде, в каком он тебе достался: что обещано, что решено, что сделано, какие риски и кто владелец каждого. Он же становится основой устава, реестра рисков и реестра стейкхолдеров. Не делай три разных файла там, где хватит одного.
Шаблоны ниже помогут собрать эти части. Они на английском, как у большинства проектных документов в международных компаниях: названия колонок можно оставить, описания переписать на язык команды. Если хочешь отработать этот порядок без риска для реального проекта, в PM Simulator первые два дня проходят именно так: аудит, встреча с руководителем, устав за два дня. Разбор делает ИИ-ментор, он читает работу, которую ты сдаёшь за день, и говорит, что сильно, что не проходит и как переписать одну строку.
Частые вопросы
Что делать, если предыдущий PM недоступен и передать нечего?
Собери историю из того, что осталось: переписку за последние три месяца, протоколы, отчёты, журнал решений в трекере. Пустые места записывай как вопросы и отправляй тем, кто участвовал. Отсутствие передачи тоже факт, и о нём лучше сказать руководителю в первый день, а не через месяц.
Нужно ли сразу менять устав, если он устарел?
Нет. Сначала отметь, какие пункты действуют, и согласуй с заказчиком те, что меняются. Устав, переписанный за два дня без подписи заказчика, устареет так же быстро, как прежний.
Сколько встреч провести в первую неделю?
Столько, чтобы поговорить с каждым участником команды и с людьми заказчика, которые подтверждают приёмку и даты. Обычно это получасовые 1:1 и две-три встречи со стейкхолдерами. Важнее число не встреч, а то, что после каждой ты записываешь, что удалось узнать и что обещано.
