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

{{Book-Ref}} {{RightNote|[[:Категория:Управление проектами|Еще об управлении проектами]]}}
[[Файл:P3express-book.png|thumb|right|300px|[https://p3express.ru/book Предзаказ на сайте автора]]]

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

Теперь несколько слов про фреймворк, его достоинства и недостатки. Более двадцати лет назад на смену классическому проектному управлению пришел 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 }}