Как я внедрял P3.express и что сломал: честный разбор ошибок, фейлов и управленческих выводов

Меня зовут Никита Новиков. Я руковожу инфраструктурными и цифровыми проектами ТЦИ в сфере веб-безопасности, электронной подписи, хостинга и ИТ-платформ. И это разбор внедрения P3.express в ИТ-компании Рунета: от первых успехов до управленческих провалов.

Если вы ищете:

• как внедрить P3.express в компании
• реальные ошибки при внедрении методологии управления проектами
• антипаттерны проектного менеджера
• почему не работает реестр рисков
• как проводить эффективное ревью проекта

— этот материал для вас.

Внедрение P3.express в ИТ-проектах

Я работаю в техническом центре, который поддерживает инфраструктуру национальных доменных зон. Проекты — от веб-безопасности до хостинга и интеграционных платформ.

Изначально я внедрял P3.express постепенно:

• начал с резюме проекта
• добавил карту результатов
• ввёл фокусированную коммуникацию
• аккуратно подключал реестр последующих действий (RICs)

Первые проекты шли спокойно. Команды были небольшими, циклы длинными (4–6 недель), зависимостей — немного.

И в такой среде очень легко поверить, что всё работает идеально.

Проблемы начались, когда:

• увеличилось число параллельных проектов
• появились продуктовые инициативы
• усилились юридические и финансовые зависимости
• компания начала переход к общей платформенной архитектуре

В какой-то момент картина стала тревожной: все заняты, но результата мало.

Первая неприятная мысль

Я пытаюсь делать идеально.

Страх выкатить неидеально. Страх ошибиться. Страх, что «сломаем».

Принцип 20/80 — где-то я это уже слышал. Тогда я открыл конспект P3.express… Начал проходиться по шагам. Смотреть типичные ошибки, детальнее вчитываться в суть.

И тут стало понятно: узкое место процесса — в моём кресле.

Заново «изучив» методологию, я увидел несколько узких мест.

Красным, серым и жёлтым помечены три точки, где я споткнулся (RIC, ревью и коммуникация) + зелёным – те места, где просто познал некоторые дополнительные истины.

Я не нарушал методологию.
Я неправильно её проживал.

Ошибка №1. Идеальный реестр рисков, который никто не открывал

Я потратил недели на идеальный RIC в Excel:

• корректные формулировки,
• чёткое разделение риск/проблема/изменение,
• продуманные меры реагирования,
• идеальная структура.

Файл лежал на корпоративном файлообменнике.
Доступ был у всех.

Им никто не пользовался.

Почему не сработал реестр рисков?

Потому что я оптимизировал форму, а не вовлечённость.

В мире технарей всё живёт в трекере. Если сущность не в Jira — её не существует. Я же пытался внедрять «по канону», а не «по среде».

Решение оказалось простым:

• риски переехали в карточки в трекере,
• стали частью привычного workflow,
• обсуждения стали регулярными.

Методология не требовала Excel.
Это требовал мой перфекционизм.

Вывод: P3.express гибкий. Если ПМ негибкий — ничего не спасёт.

Ошибка №2. Ревью как экзамен вместо обмена опытом

Изначально я воспринимал ревью проекта как аудит на соответствие методологии:

• рассказал статус,
• показал документы,
• получил молчаливое одобрение,
• поставил галочку.

Ценности — ноль.

Переломный момент случился, когда коллега показал свою схему запуска MVP. Я понял, что мог бы сэкономить себе недели работы, если бы раньше увидел его подход.

И только тогда я осознал:

Ревью в P3.express — это не проверка.
Это рынок управленческих решений.

Когда я начал приходить не с отчётом, а с вопросами: «А вы как решили это?», «Почему у вас критерии готовности такие?», «Что сработало, а что нет?» — ревью ожили.

Когда ревью стало про обмен, а не про проверку — оно ожило. Такой обмен позволяет перенимать лучшие практики, которые пекутся в твоём же контексте.

В компаниях, где внедрение идёт неравномерно, ревью — это способ ускориться через чужой опыт.

Почему формализованные ревью не работают?

Потому что шаг делается без понимания смысла.
Методология превращается в ритуал.

Эффективное ревью проекта — это обмен практиками, а не контроль каноничности.

Ошибка №3. Иллюзия независимого проекта

Самая дорогая ошибка.

Компания начала переход к общей бизнес-платформе. Проекты перестали быть изолированными.

А я продолжал управлять ими как независимыми.

Последствия:

• двойная работа между командами
• повторная фиксация одних и тех же багов
• месяцы экспериментов, уже пройденных соседями
• интеграционные проблемы на финальном этапе

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

Разработчики честно сказали:
«Если бы мы знали конечное окружение — сделали бы иначе».

И они были правы. Проект не живёт в вакууме.
Фокусированная коммуникация должна работать на уровне всей компании, а не только команды.

Я стал точкой отказа.

• отвечал клиентам сам
• занимался аналитикой
• лез в юридические детали
• держал задачи в голове
• принимал всё на себя

Мысли были классические:

«Сам быстрее сделаю»
«Лучше объяснять не буду»
«Сейчас закрою — и пойдём дальше»

В моменте это ускоряет.
В долгую — парализует.

Команда ждёт.
Готовый функционал лежит.
Проекты стоят.

Почему делегирование — не про разгрузку, а про развитие?

Когда ПМ делает чужую работу:

• он перегружается,
• команда не растёт,
• появляются скрытые задержки.

Методология это подсветила.
Но привычки — мои.

Процесс ради процесса

Вторая серьёзная управленческая ошибка — формальное внедрение шагов:

• документы создавались «для структуры»
• Confluence наполнялся «на всякий случай»
• шаги выполнялись ради соответствия

Методология стала самоцелью.
А людям важен смысл, не процесс.

Ключевая мысль:
Если шаг не создаёт ценность — он превращается в бюрократию.

Сколько стоили ошибки?

Я не считал в деньгах.
Но одна только выгрузка задач из головы в трекер заняла у меня три недели.

Три недели — на перенос того, что «существовало», но не было формализовано.

Если добавить простой команды, переделки и дублирование работ — цена исчисляется месяцами.

Что бы я сделал иначе при повторном внедрении P3.express

Если коротко:

1. Не стягивал бы чужую работу.
2. Сразу назначал владельцев задач.
3. Вёл бы риски в среде команды.
4. Проводил бы ревью как обмен практиками.
5. Проверял зависимости между проектами заранее.
6. Прописывал критерии готовности с учётом целевой архитектуры.
7. Ничего не держал бы в голове.

Работает ли P3.express в реальном ИТ-контексте?

Да.

Но методология:

• не лечит перфекционизм,
• не учит автоматически делегировать,
• не заставляет видеть систему,
• не спасает от управленческих привычек.

Зато она:

• делает проблемы видимыми,
• структурирует мышление,
• создаёт точки для рефлексии,
• показывает, где именно вы — узкое место.

И это её главная ценность.

Итог: я ломал P3.express — и стал управлять лучше

Методология не виновата.
Я внедрял её, оставаясь прежним.

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

Если у вас что-то «не работает» в фреймворке: возможно, проблема не в фреймворке.
Возможно, он просто честно подсвечивает управленца.

Если этот разбор поможет вам не платить за управленческие ошибки месяцами времени — значит, тот идеальный Excel с RICs всё-таки был не зря.