Привет, меня зовут Руслан Усманов, я PM Head в Doubletapp. В конце прошлого года мы пересмотрели свою систему ведения проектов и внедрили методологию P3.express. В этой статье поделюсь опытом и расскажу, почему мы решили это сделать, как проходил процесс внедрения и к каким результатам мы пришли. 

С чего все началось

В 2024 году в работе у нас было больше 20 проектов. Задействованы в них были три проджект-менеджера, пять тестировщиков, несколько дизайнеров и целый парад планет различных разработчиков — реактщиков, питонистов, гошников и других специалистов. Мы задумались, как нам улучшить процессы ведения проектов, потому что у каждого PM – свой подход, свои артефакты и свои боли. Это создавало определенные трудности, например, для босса бизнес-юнита (мини-СЕО обособленного подразделения) при планировании или для самих проджектов при ротации: когда проекты ведутся разными людьми по-разному, очень сложно в них погрузиться.

В целом система работала. У нас не было какого-то факапа или ситуации, когда мы сели в лужу и после этого решили что-то поменять. Просто на полугодовом ревью посмотрели на свои процессы и поняли, что нет единого подхода, единого понимания, как можно вести проект.  

Что изменилось

Начали изучать варианты методологий. Остановились на P3.express. Это минималистичная и гибкая методология управления проектами, в основе которой лежит принцип цикличности. Ее легко освоить, легко применить. И на нее легко нарастить все, что нужно нарастить.

P3.express — это система управления проектами, которая представляет собой алгоритм из 33 конкретных шагов. Они разделены на семь этапов. Первый этап — подготовка проекта. Два последних — завершение и послепроектная работа. Остальные этапы (со второго по пятый) — это цикл проектной работы, который длится 2−4 недели и повторяется до завершения проекта.

Изучили информацию на открытом ресурсе, прошли курсы PMCLUB (кстати, после обучения можно пройти независимое тестирование и получить международный сертификат P3.express Practitioner). С учетом высокой нагрузки, у сотрудников проектного офиса ушло три недели на обучение — но вообще, при более вовлеченном погружении достаточно одной. Еще месяц (опять же, с учетом нагрузки) понадобился, чтобы адаптировать эту методологию под наши процессы. Внедрять ее начали в конце ноября 2024 года на новом проекте (корпоративный аналог Google Docs для российского бигтеха). Сделали это буквально с двух ног: методология не поменяла нам рельсы, но сделала процесс более структурированным, понятным и прозрачным для всех его участников.

Как теперь строится работа?

1. Перед стартом проекта собираем артефакты

Методология P3.express предполагает использование четырех артефактов.

Первый артефакт — резюме проекта. Маленький одностраничный документ, в котором собирается описание проекта: цель и ожидаемые выгоды, ожидаемая стоимость и продолжительность, требования и ожидания по качеству (не функциональные требования, а именно дополнительные нюансы, которые нам важно подсветить), перечень стейкхолдеров. Сюда же мы включили карту результатов. Этого артефакта у нас не было — все держалось в голове у PM или как-то было описано в договоре. Благодаря новому подходу мы опрозрачиваем проект для всех участников.

Второй артефакт — дорожная карта. Она включает таймлайн проекта и скоуп работ. Этот артефакт у нас уже был, но теперь он стал еще и отчетным документом: после каждого спринта (две недели) PM показывает внутреннему инвестору, какие работы и в какой срок были выполнены, подсвечивает проблемные моменты, если такие имеются. PM‑у это позволяет быть всегда собранным, смотреть на проект более строгим взглядом. А боссу бизнес‑юнита — быть погруженным в проект и вовремя реагировать на проблемы.

Третий артефакт — карта рисков, внутренних и внешних. Ее мы составляли раньше, но не в обязательном порядке, а по запросу клиента или на очень сложном и долгом проекте. И эта информация тоже была только в голове у PM. Теперь все участники команды знают, что мы можем попасть в риск и что мы будем делать, если риск сработает. 

Возможны четыре реакции на риск: эскалация, смягчение, избегание, принятие. Например, если мы говорим о риске «непопадание в ожидания заказчика» (который по умолчанию есть у любого проекта), то выбираем реакцию «избегание». Прозрачность процесса — через постоянную коммуникацию с заказчиком показываем ему, что у нас реализовано, что вызывает вопросы. И он также высказывается, дает свой фидбэк. Через эти коммуникации мы понимаем, правильно мы идем или нет. Четко согласованные ожидания, как правило, фиксируются в резюме и требованиях. В случае с другим риском, связанным с перерасходом по часам, могут быть и другие реакции — например, «смягчение».

Кстати, у PMCLUB есть отдельный курс «Как работать с рисками проекта». Он нам очень помог внедрить этот артефакт.

И четвертый артефакт, как и резюме проекта, новый для нас, — «Здоровье проекта». Чтобы измерить его, мы ежемесячно ревьюим заказчика и команду — подробнее об этом расскажу ниже.

Все эти артефакты регулярно пересматриваются и при необходимости актуализируются. Реже, чем остальные, обновляется резюме проекта. «Здоровье проекта» — ежемесячно и при закрытии проекта, дорожная карта — еженедельно, а карта рисков — в идеале ежедневно. И при этом, если реализовался риск, нужно фиксировать, что мы сделали в этой ситуации — чтобы потом обсудить на ретроспективе, обновить наши процессы и не повторять ошибок.

2. Ежемесячно запрашиваем обратную связь у заказчика

Фидбэк от заказчика получаем в виде ответа на опрос от аккаунт‑менеджера, прикрепленного к каждому заказчику. Задаем четыре вопроса: есть ли четкое понимание того, что мы делаем (это про результат и эффективность наших инструментов), прозрачно ли ведется проект, комфортно ли с нами взаимодействовать, есть ли предложения по улучшению взаимодействия. И еще есть пятый вопрос — свободный комментарий. Если мы получаем хотя бы один негативный ответ, идем и копаем, пока не докопаемся до сути. Наша задача — чтобы на все ответы мы получили положительный ответ, чтобы заказчик был доволен.

Благодаря этому мы не только выстраиваем четкие взаимоотношения с заказчиком на всех этапах проекта, но и измеряем NPS — Индекс потребительской лояльности.

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

3. Проводим ревьюинг

Если артефакты проекта и обратную связь от заказчиков мы в той или иной степени собирали и раньше, то этот элемент стал для нас абсолютно новым. Теперь ежемесячно проджект-менеджер ревьюит другихпроджект‑менеджеров и их проекты. Большой дополнительной нагрузки на команду это не принесло: мы договорились, что ревью одного проекта должно занимать не более двух часов в месяц. Но это принесло явный результат — меньше ошибок в артефактах и планах и порой нахождение оптимального аргументированного решения той или иной проектной проблемы.

К чему мы пришли

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

Что дает внедрение этой методологии?

• Во‑первых, проект становится более прозрачным для всех его участников, а не только для PM. Например, разработчики видят риски, команда проекта понимает свое влияние на риски, и порой это осознание ответственности помогает сделать работу более эффективной.

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

• В‑третьих, усиливается и становится качественной коммуникация — как с заказчиком, так и внутри команды. За счет этого уменьшается количество рисков (не попадем в ожидания заказчика, в оценки срока или бюджета) — а значит, повышается качество работы и удовлетворенность всех сторон. Снижается уровень стресса у команды, у PM, у заказчика, становится благоприятным микроклимат.

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

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