П10. Онбординг нового PO: с нуля в проект

Отдельный случай, который не совпадает ни с «я один и внедряю методологию впервые» (раздел 0 и Часть III), ни с «у меня уже была команда, а нагрузка выросла» (основной сюжет документа). Вы приходите в проект без истории: не знаете ни репозитория, ни людей, ни того, чем на самом деле подтверждены обещания, которые числятся за проектом. Порядок первых недель зависит от одного вопроса: методология в департаменте уже работает или её ещё не было.

Сценарий А. Методологии в департаменте ещё нет

Вы оказываетесь в позиции первого PO из раздела 0, с одной поправкой: «День 1» из П3 — замер базовой линии по прошлому кварталу — сделать самостоятельно не получится, вы ещё не знаете истории. Его заменяет серия интервью с теми, кто вёл проект до вас.

• Первая неделя — не внедрять методологию, а восстановить факты. Разговоры с техлидами по формуле Шага 4 (не «как дела», а «под что вы готовы подписаться прямо сейчас»): это даёт честную стартовую картину вместо унаследованного оптимизма предыдущего PO.
• Уровень зрелости на старте — 0 (Шаг 1). Не проектировать CI, блокировку merge и автоприём — это поздние уровни, и попытка начать с них убивает затею на второй неделе.
• Три часа на репозиторий и правила (Шаг 2): /paf-profile, /paf-rules, /paf-bet, /paf-cp. Лестницу и распад калибруете не абстрактно, а сверяя с тем, что в вашем домене реально проверяемо — вы его пока знаете хуже, чем знал предыдущий PO.
• Дальше — чек-лист «Десять дней подготовки» (П3), начиная со дня 2: день 1 в вашем случае — это интервью, а не самоотчёт.
• Не наследовать committed-обещания предыдущего PO без проверки основания. Change_rate работает и здесь: то, что было подтверждено месяц назад, за время передачи проекта могло устареть.

Сценарий Б. Методология уже работает в департаменте

Задача обратная — не строить систему, а не сломать чужую, уже откалиброванную. Лестница ступеней, Нексус, правила распада общие на департамент (Шаг 9, стадия 3), и придумывать свои значения нельзя: это тот самый общий формат, до которого другие PO дошли за несколько кварталов калибровки.

• Не создавать репозиторий и правила с нуля — запросить доступ к существующему (nexus/, rules/, bets/) и прочитать rules/ladder.md, rules/gates.md, rules/decay.md прежде чем задавать вопросы вслух. Это тот контекст, который в классической модели пришлось бы неделями собирать по головам.
• Пройти /paf-profile и /paf-bet для своей зоны, но /paf-rules не пересобирать: калибровка уже общая на департамент, новое значение внутри неё делает ваши ступени несравнимыми с остальными.
• Получить не задачи, а текущие узлы Нексуса и открытые ставки по своей зоне — прочитать их до первого разговора с командой, чтобы не пересказывать статус, а проверять уверенность.
• На стыках с другими PO (П6-тер) не начинать контракт заново — сначала прочитать историю: стык мог существовать до вас, и обещания на нём уже кому-то даны.
• Встроиться в существующий ритуальный контракт (П4, П6-бис), а не предлагать свой формат отчётности, пока не увидели, как это делает департамент.
• Первый разговор с руководителем — не «вот мой план», а «вот что я прочитал, что подтверждено, что осталось неясным» (Шаг 8, стадия 2). Это самый быстрый способ не выглядеть новичком, который переизобретает то, что коллеги уже откалибровали.

Ключевое отличие: в сценарии А новый PO строит систему и поэтому вправе задавать её параметры. В сценарии Б параметры уже не его — их можно унаследовать, но не пересматривать в одиночку. Пересмотр лестницы или правил распада на зрелой стадии — разговор CPO и CTO о структуре (Шаг 9), а не решение одного PO, даже если он не согласен с тем, как откалибровали до него.