Просмотр исходного текста страницы Блог:Максима Цепкова/2026-03-26: Дмитрий Ильенков. Управление проектами по методу p3.express - годный метод хорошая книга

{{Book-Ref}} {{RightNote|[[:Категория:Управление проектами|Еще об управлении проектами]]}}
Прочитал книгу '''Димы Ильенкова «Управление проектами по методу p3.express»'''. Книга – о легком, минималистичном фреймворке управления проектами '''p3.express''', который мне в целом понравился. В нем есть важные фишки, шаги, которые редко используют, а они могут дать ценный вклад. Это ревью внешними коллегами планов и хода проекта, регулярное возвращение к решению идём или нет, рассылка информации о ходе проекта, отдельное поле для извлеченного урока и много других. Да и в целом фреймворк – вполне работоспособный. Я о нем слышал на конференциях в нескольких докладах, и тогда для себя отметил, поэтому книгу читал с интересом. И сама книга написана хорошо, с многими примерами из реальной жизни. Так что рекомендую. Книга пока не вышла из печати, находится на стадии предзаказа. Так что, если вас заинтересует мой отзыв, то заказывайте.

Теперь несколько слов про фреймворк, его достоинства и недостатки. Более двадцати лет назад на смену классическому проектному управлению пришел Agile, для начала – в виде Scrum. И оказался годным и перспективным методом. Так что PMI Institute с 4 версии PMBOK 2008 года пытается сделать гибрид, но у него получается плохо. Несколько лет назад я подробно разбирал это на TeamLead в выступлении [[Почему проектный подход не работает в IT (Teamlead-2022)|Почему проектный подход не работает в IT]].

А вот у авторов p3.express получилось сделать годный вариант, который я бы лично назвал расширением scrum для управления проектами. Но поскольку слово «scrum» вызывает у некоторых неконтролируемое эмоциональное отвращение, то назовем его легким гибридом классики и agile-методов. 

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

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

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

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

Этапы запуска проекта, его завершения и анализа, а также планирования и завершения цикла описаны очень подробно и с примерами. Я не буду тут пересказывать всю книгу, отмечу несколько моментов. Например, на этапе запуска проекта готовят его резюме, дальше идет несколько шагов уточнения, включая работу с рисками, ревью коллегами, а потом защита перед стейкхолдерами на проектном комитете, на котором и принимается окончательное решение о старте. Характерно, что шаг защиты проекта имеет говорящее название «Решить Go/No-Go», подчеркивающее, что проект может не состояться. 

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

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

Конечно, фреймворк не является идеальным – как и любой фреймворк. И часть вещей там, с моей точки зрения, не акцентированы, хотя они важны. Например, работа с вехами проекта, которые фиксируют достижение некоторого результата, они есть в любом большом проекте. Или фокуса на завершение задач, чтобы не плодить много незавершенной работы, в Scrum это обеспечивается требованием релиза по завершению цикла. 

Нет внимания на конструкцию, которую создаем: мы на начальном этапе разбили на кусочки, и надо чтобы они были между собой согласованы, чтобы из них собралось целое. В ИТ-разработке это обеспечивает непрерывная интеграция. Вообще на начальном этапе надо бы еще проверить принципиальную реализуемость проекта командой в заявленные деньги и сроки. В руководстве есть презумпция разумности планов, а это есть далеко не всегда. 

Еще один аспект: сроки проектов регулярно съезжают, и вряд ли метод будет тем волшебным лекарством, который избавит от этого. На мой взгляд, во фреймворке есть шаги, где это можно сделать – в ходе регулярной переоценки в начали цикла. Но для пересмотра нужны основания, и их надо готовить. В целом фреймворк дает место для такой активности – на обсуждение рисков, но прямо такой риск («вскрылась новая информация») записать обычно не дают, говорят «вы что, плохо подготовились», но приемы есть. Это, конечно, очень продвинутая тема, но я бы ее затронул, потому что проблема-то типичная и обозначена во введении.

Так что в целом для всего этого есть место. Например, прохождение вех проекта можно отменить в виде отдельных задач. А проверять реализуемость в рамках работы с рисками. И так далее. Так что тут речь о дополнениях. На этом я закончу свой рассказ про книгу. 

Желаю Диме всяческих успехов, а методу p3.express – популярности и широкого использования.
{{wl-publish: 2026-03-26 13:13:45 +0300 | MaksTsepkov }}