Как долго мы будем молчать о том, что популярные стандарты по управлению проектами не работают? Почему в организациях продолжают бездумно внедрять PMBoK и прочие «фреймворки», которые только тормозят проекты? Сколько еще вы готовы потерять времени и денег только потому, что выбрали привычный процессный подход вместо реально работающего?
Вот уже 20 лет я настраиваю системы управления проектами как в небольших компаниях, так и в крупнейших российских организациях, таких как Сибур, Новабев, Сбербанк, Hoff, Рулог и пр. Лично управлял портфелями проектами стоимостью свыше 70 млн. евро. В прошлом году моя команда разработала методологию управления программой ИТ‑трансформации в компании с годовым оборотом свыше 1 триллиона рублей. Так что, в управлении проектами меня уже ничем не удивить. Кроме одного: почему до сих пор многие компании внедряют стандарты с фокусом на процессы, которые красиво описаны, но не адаптированы к реальным проектам.
В этой статье я подробно расскажу, почему ваши проектные регламенты всего лишь бесполезная бюрократия. А также, как это исправить, чтобы начать реально управлять проектами и получать нужные результаты.
Также разберу:
почему PMBoK и другие «фреймворки» напрочь оторваны от реальности;
почему единственный способ создать работающую систему управления проектами это внедрить результатоориентированный подход; почему именно этот подход позволяет достигать нужных результатов даже в условиях высокой неопределенности;
как устроен мой метод управления проектами Парацельс ПМ с результатоориентированным подходом, который я успешно применяю во всех своих консалтинговых кейсах.
Обо всем это читайте ниже в статье.
Сколько стоит ошибка при выборе подхода в управлении проектами?
Начну с того, что технология управления (методология, фреймворк) может быть источником как выгод, так и огромных финансовых потерь. Все зависит от того, какой подход вы выберете.
Если вы допустили ошибку при выборе подхода и внедрили технологию, которая не подходит вашим проекамв, масштабу и особенностям процессов организации, вы получите:
Трудоемкость при использовании. Чтобы выполнить все процедуры, заполнить документы, все со всеми согласовать… Могут уходить недели и даже месяцы. Например, в одной организации во время диагностики проектного управления мы выяснили, что на подготовку отчетов, который примет проектный офис, у каждого руководителя уходило до 25% рабочего времени! Но даже это оказалось не самым критичным. Изучая содержание такого «вымученного» отчета, мы обнаружили, что там нет самой важной информации — данных об отклонениях по срокам. Получается, время, потраченное на его создание, было выброшено впустую.
Непокрытие ключевых рисков. Например, одним из ключевых рисков в вашей организации является некачественное документирование результатов проектов, приводящее к потере экспертизы в случае ухода ключевого сотрудника. Если в вашей методологии не заложены меры по профилактике такого риска… Восстановление потерянной информации потребует существенных затрат. А если ее восстановить не удастся, то такая потеря приведет к ущербу в десятки или даже сотни миллионов.
Высокие затраты менеджмента на управление. Если методология не позволяет предотвращать риски, то руководству организации приходится постоянно вникать, что происходит в проектах. Точечно опрашивать всех участников, разруливать пожарные ситуации. То есть, в итоге тратить свое дорогостоящее время на работу рядового руководителя проекта. А все почему? Потому что вы внедрили методологию, которая работает по принципу фар ближнего света: видно только ближайшие 30 метров, а что там дальше — неизвестно.
Негибкость и торможение проектов. Когда технология содержит огромное количество сложных форм и длительных процедур согласования, запуск каждого проекта превращается в муку. И во многих компаниях такое торможение может длиться по несколько месяцев, а то и лет. И тут уже делайте выводы сами: во сколько вам обходится каждая неделя откладывания запуска важного, стратегического проекта?
А еще есть и другие потери. Не так давно я видел живой пример, как компания потеряла на разработке корпоративной ИТ‑системы десятки миллионов рублей. Как так вышло? Внедрили готовое «коробочное» решение, которое не отвечает критическим требованиям. В итоге компания отказалась от системы вовсе. А все потому, что требования к системе собирались по изначально «кривой» методологии, не покрывающей ключевые риски.
Кроме неудачи с дорогостоящими ИТ‑инструментами, вы также можете понести убытки в результате внедрения методологии. Поддержка сотрудников при переходе на новые процессы, сбор обратной связи, инструктажи и тренинги, преодоление сопротивления и т. д. — все это время и нервы руководства и ключевых сотрудников. И если вы внедряете неработающую методологию, считайте, что инвестиции, вложенные в ее внедрение, потрачены впустую.
Так что, ошибка при выборе технологии управления проектами может быть очень дорогой: в виде неуспешных проектов, высоких трудозатрат, потери времени руководства, длительности процедур и дорогостоящих бесполезных инструментов.
Откуда берутся эти ошибки? Почему технология управления так часто превращается в источник огромных финансовых потерь? Причем, даже без осознания, что их причина именно в ней?
Потому что вы выбираете процессный подход, вместо результатоориентированного.
Почему процессный подход в управлении проектами это худший выбор для организации и безнадежно устаревшая конструкция, которую невозможно адаптировать к реальности, поясню ниже на примере известных стандартов.
Что такое процессный подход в управлении проектами и почему его нельзя внедрять, если вы хотите получать нужные результаты в нужные сроки
Что такое процесс? Это линейная последовательность шагов. Простой бытовой пример: человек проснулся, встал с кровати, выключил будильник, оделся, поставил чайник. Ежедневный процесс, который состоит из предсказуемых действий. В управлении проектами к таким процессам можно отнести выполнение рутинных действий — например, процедуру согласования документов, которая состоит в основном из последовательных шагов.
И хотя предсказать шаги отдельных процедур мы можем, но чего мы точно не можем, так это выстроить систему из предсказуемых действий для управления проектом в целом. Почему?
Если рутинный линейный процесс можно назвать процессом здорового человека, то управление проектами — это процесс курильщика, где есть цикличность действий, параллельное прохождение шагов, пропуск шагов, а также добавление новых, внеплановых шагов и т. д. И вот именно здесь и начинаются сложности с применением популярных стандартов — все они представлены в виде описания процессов: сделай А, сделай Б и придешь в точку С (но чаще в Ж).
Разберем PMBoK – схему управления рисками:
Схема разбита на несколько процессов: планирование, идентификация и качественный анализ. Однако внутри этих процессов мы видим набор инструментов и практик, который не дает ни малейшего представления, как именно их нужно применять. Нужно ли их применять все или выборочно в зависимости от специфики конкретного проекта? В каком порядке? В какой момент времени? Как их комбинировать? Здесь нет ответа ни на один из этих вопросов. Получается, руководитель проекта должен взять этот стандарт и как‑то сам решить, что он из этого берет, а что нет. А в итоге приходим либо к большому количеству ненужны инструментов, что тормозит проекты и делает процессы трудоемкими, либо к игнорированию критичных рисков. И в том, и другом случае финансовые потери неизбежны.
PMBoK хорош также, как хорош строительный магазин Леруа Мерлен — тут есть все. Но если вы хотите построить дом своей мечты, вряд ли вы будете покупать все, что есть, или же покупать что‑либо «вслепую». Вам нужен набор конкретных инструментов и материалов с точной инструкцией, как и когда их нужно применять, чтобы построить качественный и красивый дом.
Теперь возьмем другой стандарт – Prince2
На мой взгляд, он чуть конкретнее, но все равно сильно оторван от реальности.
Рассмотрим такой процесс, как обновление проектного плана:
Из плюсов предлагаемого подхода — здесь мы хотя бы понимаем, какие артефакты (результаты) должны быть на выходе: план проекта, реестр рисков, реестр открытых вопросов. Однако что и в какой последовательности нужно делать также непонятно.
Однако по сравнению с PMBoK, который делает упор на описание процессов, в Prince2 все же есть грубая структура в виде унифицированного жизненного цикла: инициация, планирование, реализация и завершение. И для каждой фазы здесь определены процессы с описанием инструментов, как на схеме выше. Грубо говоря, если PMBoK это как Леруа Мерлен, где есть миллион инструментов и материалов на выбор… То Prince2 это как тот же магазин, но уже со специальными отделами под каждый этап строительства: вот здесь все для закладки фундамента, здесь для возведения коробки, а здесь для чистового ремонта.
Но никакой инструкции, что, кому, как и когда нужно делать здесь, само собой, тоже не прилагается.
Ну и напоследок разберем еще один популярный в России «фреймворк» P3Express
Возьмем описание процесса по планированию цикла:
Вот тут уже не просто набор действий, а вроде бы понятная последовательность шагов. Однако есть нюансы.
Давайте приземлим данный процесс планирования на практику и представим, что у нас идет не первый, а уже n‑ый цикл планирования. Главный вопрос: сможем ли мы обновить и детализировать планы до того, как проведем ежемесячное ревью со всеми выводами и корректировками? Точно нет.
Другой вопрос: можем ли мы принять решение остановить проект (шаг Go/No‑Go) без какого‑либо обоснования? То есть просто взять и сказать — проект дальше не идет. Тоже нет. Этому шагу должны предшествовать другие шаги, которые включают подготовку обоснования, почему проект нужно остановить. Здесь этого также нет.
А что насчет шага «Провести стартовую встречу»? Когда именно ее нужно проводить и можно ли ее совместить с ежемесячным ревью, чтобы сэкономить время? Ответа на этот вопрос не найти.
И хотя создатели фреймворка решили определить последовательные шаги для каждого процесса, следовать им в реальности невозможно. Точнее, можно, но если проект максимально простой и делается выделенной командой. То есть, для приготовления пюре — ок, но если нужно приготовить сложное блюдо мишленовского уровня — ничего не получится. А ведь технология управления проектами нужна именно для таких «блюд».
Да, когда читаешь все эти стандарты, не возникает никакого сопротивления — все по делу, все инструменты толковые. Я не говорю, что все это бесполезно. Полезно для понимания ассортимента инструментов, теоретической последовательности шагов, но не для создания работающей технологии управления. Потому что фундамент реального управления проектами это, в первую очередь, создание ясной картины всего происходящего на проектах для всех участников. А ясность это понимание, что, кому и когда нужно делать, чтобы минимизировать риски и добиваться нужных результатов в нужные сроки.
Как же добиться этой ясности?
Только с помощью доказательств реальных действий. Доказательств того, что:
руководителем проекта назначили именно того, кого нужно, с необходимой квалификацией; его назначили именно так, как нужно — с достаточными полномочиями и закреплением ответственности;
цель проекта, от которой зависит требования к результату и объем работ, внезапно не поменяется; что она железно согласована с нужными стейкхолдерами и зафиксирована в нужном виде;
команда проекта сформирована таким образом, что каждый участник четко понимает, какая ответственность за ним закреплена и каких результатов от него ожидают в каждой значимой точке проекта и т,д.
Так что, главный вопрос, который нужно задать, это не «Какие шаги нам нужно пройти?», а «Как быть уверенными, что то, что должно быть сделано, реально сделано?». Или, как говорил главный герой фильма «Красная жара» — какие ваши доказательства?
Если у нас есть доказательство в виде документа об официальном назначении руководителя проекта нужной квалификации, мы понимаем, что все сделано как надо и важный проект передан в руки опытного спеца. А если этого доказательства нет, то… Ну что ж. Тут результаты проекта, которые напрямую зависят от квалификации руководителя, можно будет спрогнозировать с такой же точностью, как и результаты игры в русскую рулетку.
Так что, чтобы быть уверенными, что все делается как надо, необходимо создать систему, опирающуюся на доказательства нужных действий.
И ниже я расскажу, как это сделать. А именно: поделюсь идеологией своего метода управления проектами Парацельс ПМ с результаториентированным подходом.
Что такое результатоориентированный подход. Почему это единственный способ управлять проектами на практике, а не в теории, и получать предсказуемые результаты
Когда‑то я работал с заказчиками в своей консалтинговой практике, используя те стандарты и фреймворки, что есть на рынке — как международные, так и российские. Однако часто мне приходилось сталкиваться с ситуациями, когда система управления проектами, построенная на базе этих стандартов, практически не работает (в начале статьи я уже описал, почему).
Идея создать Парацельс ПМ пришла мне в голову в 2018 году в связи с моим интересом к гибридным методам управления и попыткой сделать компактный, целостный и практичный метод. Спустя семь лет и опробирования Парацельс ПМ на всех моих клиентских проектах, я понял, что получилось именно то, что нужно — метод управления проектами с результатоориентированным подходом. При этом я не изобретал каких‑то новых инструментов. Но взял все лучшее и проверенное, собрав метод Парацельс ПМ, который легко приземлить на практику.
Главная выгода метода: с его помощью можно всего за месяц собрать собственную технологию управления, которая:
дает ясную картину всего происходящего в проектах, благодаря чему можно с максимальной точностью прогнозировать результаты и заранее выявлять и устранять возможные угрозы;
закрывает важные потребности организации и решает конкретные проблемы;
легко встраивается в днк организации и учитывает имеющийся опыт, что позволяет быстро внедрить и преодолеть сопротивление.
Самое главное, если вы создаете свою технологию управления на базе этого метода, вы можете реально проверить, что все делается так, как нужно делать. Либо же использовать готовое решение Парацельс ПМ с минимальной адаптацией под себя.
Ниже вкратце опишу, из чего он состоит.
Парацельс ПМ – фундамент работающей технологии управления проектами
Определение аспектов управления — первое, с чего мы начинаем сборку своей технологии по Парацельс ПМ. Это то, о чем нужно договориться как на уровне менеджмента, так и на уровне исполнителей — чему нам реально важно уделять внимание, чтобы достигать целей как проектов, так и организации? Нужно выбрать только то, что действительно важно, потому что уделять достаточное внимание всем аспектам невозможно.
Вот в PMBoK есть 10 областей знаний, но в зависимости от специфики организации и ее проектов обычно нужны далеко не все. Например, зачем нам утяжелять методологию и создавать правила для управления ресурсами, если у нас все делается выделенными командами? Или наоборот — для организации и успеха будущих проектов важен аспект сохранения экспертизы, чтобы избежать проблем, когда кто‑то из ключевых руководителей уйдет вместе со всеми знаниями в голове. В большинстве стандартов этого аспекта нет. Так что, определяя аспекты, нужно опираться, в первую очередь, на здравый смысл и специфику организации, а не на внешние стандарты.
Как понять, что действительно важно? В методе Парацельс ПМ у нас есть набор аспектов, которые чаще всего важны. И тут нужно понять, что из этого набора важно именно в вашей организации и нужно ли добавить свои уникальные аспекты.
Ниже поделюсь небольшим лайфхаком, как определить важные аспекты.
Для начала определите:
критерии успеха проектов. Это может быть высокая маржинальность, новые проекты с тем же заказчиком, высокая приживаемость результатов и т. д.
критерии неуспеха проектов. Например, нарушение сроков, требований по информационной безопасности, требований к документированию, увеличение бюджета.
причины возникающих проблем. Высокая текучка, неэффективное использование ресурсов, разрастание требований на проекте и т. д.
Объедините похожие смыслы из каждого списка и попробуйте выделить ключевые аспекты. Например, если взять:
критерий успеха — приживаемость результата
критерии неуспеха, связанные с нарушением каких‑либо требований
проблему разрастание требований
Все это про аспект содержание и качество. Очевидно, что уделять внимание ему критично важно.
Когда вы определились с аспектами, остается понять, как вы собираетесь уделять им внимание? Если вам важны сроки, бюджет, содержание и качество, сохранение экспертизы — как именно вы будете управлять этими аспектами, чтобы проекты были успешными с нужными результатами и бизнес‑эффектами для организации?
Ниже расскажу, почему аретефакты и события — главные инструменты, чтобы уделять внимание выбранным аспектам.
Где ваши доказательства? Артефакты и события
Приведу простой бытовой пример. Представьте, что вы решили начать контролировать свои расходы. Но если просто себе пообещать, что «все, с понедельника я начинаю следить за ним», вряд ли вам это поможет начать экономить.
Чтобы действительно сделать то, что вы задумали, вам нужно регулярно уделять внимание этому вопросу: завести табличку в Excel или скачать приложение, ежедневно заносить данные о каждой покупке и раз в МЕСЯЦ анализировать их.
Уделять внимание — значит создавать и использовать артефакты, подтверждающие действия или результаты (отчет за неделю, выгруженный из приложения), и анализировать их в специально выделенное для этого время. Такое выделенное время мы называем событиями — например, совещания, которые проходят по определенному расписанию или с нужной регулярностью. То есть, сами по себе артефакты не несут никакой ценности. Она появляется, когда артефакты используют во время обсуждения на совещаниях для принятия нужных решений по проекту и фиксации договоренностей.
То, в каком виде представлен артефакт для обсуждения, также имеет большое значение — если отчет по проекту наглядный и удобный и сразу дает понимание, какие есть отклонения и в чем их причина, то решения принимаются быстро и точно. А если нужно тратить время, чтобы докопаться до сути отчета… Форму этого артефакта точно нужно менять.
Так что, основными инструментами, которые позволяют управлять важными для организации и проектов аспектами, это артефакты (доказательства) и события.
Но это, конечно, не все.
Как я уже писал ранее, любой метод или технология должны давать четкий ответ на следующие вопросы:
зачем мы это делаем?
кто делает?
что делает?
как делает?
когда делает?
И если аспекты отвечают на вопрос «Зачем мы это делаем?», а артефакты и события на вопрос «Что мы делаем для получения нужного результата?», то:
на вопрос «Кто делает?» отвечают назначенные роли и закрепленная ответственность;
на вопрос «Когда делает?» отвечает жизненный цикл проекта, к которому привязаны артефакты и события;
на вопрос «Как делаем?» отвечают шаблоны и инструкции по подготовке артефактов и событий, где реально описать последовательность шагов.
Если мы знаем ответ на каждый из этих вопросов и можем проверить в любой точке жизненного цикла проекта, действительно ли все делается правильно (что надо, кем надо, как надо и когда надо), то все, что остается, это упаковать ответы на эти вопросы в правила, а правила в регламент.
Этот метод — единственный способ сделать управление максимально понятным. А когда у вас есть четкое понимание, как именно вы приходите к нужному результату, у вас есть ясность, что происходит в любой момент времени, А значит, есть возможность предпринимать нужные и своевременные действия, чтобы заранее устранять возможные проблемы.
Прозрачность‑предсказуемость‑результат — только в такой связке и никак иначе.
Ещё советую почитать эту статью, где я рассказываю про создание кастомной технологии с опорой на уже имеющийся опыт организации.
Подписывайтесь на мой Телеграм канал Андрей Малахов | От проектов к изменениям, где я делюсь проверенными инструментами управления проектами и изменениями, мыслями о менеджменте и полезными гайдами. Также в канале я регулярно публикую клиентские кейсы, записи подкастов с топовыми экспертами России и свои авторские наработки. А в ближайшее время проведу вебинар, на котором подробно расскажу, как легко внедрить Парацельс ПМ в вашу организацию.
Комментарии (17)
Alex_Chicot
14.08.2025 14:24Заинтересовал заголовок. «подробно расскажу - как сделать» в описании. А потом - «смотрите мой программный продукт». Всё скатилось к саморекламе. Нафиг…
PMLogix Автор
14.08.2025 14:24Кажется, вы не до конца или не совсем внимательно прочитали статью. Потому что я достаточно подробно описал, каким требованиям должен соответствовать работающий фреймворк управления. А во-вторых это не программный продукт. Лучше напишите, с чем конкретно вы согласны. И что критического в том, что я предлагаю свой подход, если он работает и проверен?
kokanov
14.08.2025 14:24Спасибо за комментарий. Я саму статью читать не стал и сразу полез смотреть в комментарии, чтобы понять стоит ли читать такую простыню. Благодаря вашему комментарию сэкономил время и нервные клетки :-)
bromium
14.08.2025 14:24Читал и другие статьи автора — заголовки интригующие, по факту — ответов нет. Вначале автор хаит существующие методологии — они про процессы, а не про результат, регламенты, инструкции. Но в конце статьи при описании метода— хоп, а оказывается тоже нужны инструкции.
А вот эти вопросы «зачем мы это делаем» — заказчик заказал, что мы делаем — что заказчик заказал, кто делает — разработчики, как делаем — берем и разрабатываем.
чем это принципиально отличается от других методологий. Они тоже требуют определить что, кто , когда, тоже требуют definition of done и тпт.
Потому пафоса в статье много, а что предлагается взамен — да примрено то же самое.
«Определите, что назначен руководитель проекта нужной квалификации» — ну да, взяли рп на проект с большим опытом. Как еще определить? Наверное, автор имел ввиду что рп должен знать его метод парацельс — и тогда да, это рп нужной квалификации, а если pmbox — это плохой рп, так что ли?
получается все то же самое — сами должны определить что и когда делать, за что ругает автор другие методологии, но его методология — да то же самое, только с другим название , назвав это аспектами или артефактами, сути дела принципиально не меняет.
Вообще, назвав это результатоориентированным — еще ничего не значит, не видел ни одной методологии которая декларирует, что результат не важен, гдавное процесс. Просто чтобы добиться результата, требуется правильно выполнять процессы в нужной последовательности, но автор говорит — а вы сами там определитесь с «аспектами, артефактами». Впрочем, я уже повторяюсь — разницы автор не показал, по делу поругал других, а чем он принципиально отличается со своей методологией — донести не смог
PMLogix Автор
14.08.2025 14:24Мне сложно уследить за вашей мыслью. Задачи хаить не было, была задача конструктивно показать недостатки, проявляющиеся на практике при использовании процессноориентированных стандартов управления проектами. И я их описал с примерами, настолько красочно, насколько смог.
То, что ни в одной моей статье вы не нашли ни одного ответа скорее говорит о том, что вы не пытались ничего извлечь, ну или задать конкретные вопросы, ответ на которые вас интересует. Я даю конкретные практические рекомендации и примеры, но они требуют релевантного опыта и насмотренности, чтобы ими воспользоваться. То, что у статей десятки сохранений, говорит об их пользе.
Про отличия методологий читайте статью внимательно. Все написано черным по белому. Если совсем не видите разницы, то я сдаюсь. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым.
В статье объяснено, почему мой подход является результатоориентированным, а не процессноориентированным. Но, если вы не поняли разницы, то я бессилен.
Речь не о цели метода. Конечно же любой метод нацелен на получение результата, а об его архитектуре, в которой результатам (артефактам) уделяется особое внимание.
Во многом Prince2 несмотря на использование процессов, как объекта архитектуры не исключает важной роли результатов (артефактов). Даже выделяет отдельный принцип "фокус на результате". Так что я развил и усилил этот принцип.
Если ваши вопросы и тейки будут нацелены на понимание разницы и плюсов предлагаемого подхода, буду рад прояснить непонятные моменты. Но я не вижу смысла перессказывать другими словами то, что я уже написал. Как говорится "Sapienti sat".bromium
14.08.2025 14:24Мне сложно уследить за вашей мыслью
Я мог бы ответить, как Вы "Все написано черным по белому. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым. " или "Но, если вы не поняли ...., то я бессилен "
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Пока у меня сложилось впечатление, что просто переименовано/переупаковано все то, что есть в других методолгиях и подано, как некая панацея.
Тем более, мы на ИТ-ресурсе, в первую очередь интересны проекты по разработке ПО.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от Scrum или упоминаемого Вами Prince2.
Изменены названия элементов, а по факту выглядит, как просто параллельная реинкарнация Scrum/Agile-логики, которая и так уже закрывает почти все, что автор в статьях описывает как некую «революцию» в управлении.
При том, что Scrum, к примеру, уже готовая и проверенная реализация того, что "Парацельс ПМ" называет результатоориентированным подходом.
Разница в том, что Scrum чётко описан и стандартизирован, а "парацельс" – это, получается, кастомный набор правил, построенный вокруг тех же базовых вопросов («зачем, кто, что, как, когда»), но без жёсткой структуры.
При этом автор, критикуя "процессные" методологии пишет (что особенно смутило):
"Однако внутри этих процессов мы видим набор инструментов и практик, который не дает ни малейшего представления, как именно их нужно применять. Нужно ли их применять все или выборочно в зависимости от специфики конкретного проекта? В каком порядке? В какой момент времени? Как их комбинировать? Здесь нет ответа ни на один из этих вопросов."
Но далее, предлагая свой метод, пишет "нужно договориться как на уровне менеджмента, так и на уровне исполнителей", "нужно выбрать только то, что действительно важно, потому что уделять достаточное внимание всем аспектам невозможно."
Особенно слабо выглядит вот эта фраза:
"Как понять, что действительно важно? .... И тут нужно понять, что из этого набора важно именно в вашей организации и нужно ли добавить свои уникальные аспекты."
То есть, чтобы понять, нужно понять (спасибо, кэп)
То есть на самом деле тоже не дает ответов, все спихивается на того, кто будет применять метдологию. А для это нужно что? Бинго! "Нужно доказательств того, что руководителем проекта назначили именно того, кого нужно, с необходимой квалификацией"
Видимо, автор грезит, что как и PMI, будет сертифицировать спциалистов, овладевших сакральными знамиями его авторских методик. Желание понятное, ничего против не имею.
Не понятно только следующее:
1. В Scrum тоже есть набор обязательных артефактов. Чем ваша работа с артефактами отличается от этой практики?
2. Как смещение фокуса на артефакты влияет на ежедневные действия команды разработки или проектной команды? Можете описать день/неделю работы в вашей системе и в Scrum – чем они будут различаться? (Кстати, почему-то scrum обошил стороной в своей статье, а разве нет этот подход/методлология сейчас самый популряный в разщличных вариациях)
3. Как ваш метод помогает в приоритизации задач и распределении ресурсов по сравнению с уже ставшим "классическим" спринтовым планированием? И вообще, что-то про планирование особо не увидел в вашей методологии, а я считаю это одним из ключевых моментов в любой методлоогии управления проектами.
4. В случае, когда заказчик часто меняет требования (динамичные интеграционные проекты), как ваш подход предотвращает хаос? Как это отличается от change management в Prince2 или backlog refinement в Scrum?
5. Если у нас есть несколько команд (разработка ПО, интеграция, тестирование), как ваш метод организует их взаимодействие? Чем это отличается от использования Scrum of Scrums или масштабированных фреймворков?
6. И вообще, где подробное описание методологии? По Scrum есть официальные руководства и статье, доступные всем желающим. Ваша методология, я так понимаю, закрытая и платная – "закажите у меня, и вы не прогадаете?"
Надеюсь, авторпридет в сознаниеперейдет к конструкивному диалогу, иначе забавно видеть - пытается продвинуть свои идеи, но при возникновении вопросов занимает оборнительную позицию и пытается оскорбить вопрошающего.
Пока выглядит, как в известном меме "в мире есть 20 стандартов, а я сделаю один, нормальный. И теперь в мире 21 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.PMLogix Автор
14.08.2025 14:24Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Мне не близка критика без аргументов, которую я увидел в вашем посте. Просто нет столько времени, чтобы пытаться другими словами сказать то, что уже сказал, особенно, когда звучат обесценивающие нотки про "ответов нет". На конкретные вопросы отвечу.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от Scrum или упоминаемого Вами Prince2.
Об этом статья. Для начала полноценного участия в дискуссии предлагаю прочитать руководство по моему методу. Его можно здесь забрать. @PMLogixBot,а также посмотреть вебинар, по мотивам которого родилась эта статья https://vkvideo.ru/video-211146584_456239038?
Особенно слабо выглядит вот эта фраза:
"Как понять, что действительно важно? .... И тут нужно понять, что из этого набора важно именно в вашей организации и нужно ли добавить свои уникальные аспекты."
То есть, чтобы понять, нужно понять (спасибо, кэп)
В тексте статьи конкретно описано, как понять, см. часть про определение аспектов управления.
Далее по вашим конкретным вопросам:1. В Scrum тоже есть набор обязательных артефактов. Чем ваша работа с артефактами отличается от этой практики?
Точно подмечено, что Scrum хорош тем, как работает с артефактами, НО он очень узок в покрытии аспектов (нет рисков, содержания и качества, ресурсов и т.д. и т.п.), а также охватывает крайне короткий горизонт планирования. Если угодно мой подход можно интерпретировать, как использование конкретики Scrum: артефакты + события + регулярность (привязка к структуре проекта) к более широкому спектру аспектов и как краткосрочным, так и долгосрочным критериям успеха и рискам проектов.
(продолжение следует)
PMLogix Автор
14.08.2025 14:24(продолжение ответа)
2. Как смещение фокуса на артефакты влияет на ежедневные действия команды разработки или проектной команды? Можете описать день/неделю работы в вашей системе и в Scrum – чем они будут различаться? (Кстати, почему-то scrum обошил стороной в своей статье, а разве нет этот подход/методлология сейчас самый популряный в разщличных вариациях)
Для ежедневных действий будет некоторое сходство со Scrum. В руководстве по методу указаны артефакты и ритуалы для всех временных горизонтов (уровней), в т.ч. для ежедневного, но все же фокус именно на реализацию проектов, а не организацию процесса по разработке ПО. Про Scrum я уже написал в ответе на один из вопросов - он слишком узкий для того, чтобы быть проектным фреймворком, кроме того, он построен в результатоориентированной логике, так что критиковать его было бы бессмысленно ). В целом я не думаю, что много кто использует чистый Scrum, скорее отдельные элементы или вариации на тему.
3. Как ваш метод помогает в приоритизации задач и распределении ресурсов по сравнению с уже ставшим "классическим" спринтовым планированием? И вообще, что-то про планирование особо не увидел в вашей методологии, а я считаю это одним из ключевых моментов в любой методлоогии управления проектами.
Я думаю, что он никак его дополнительно не улучшает. Задачи полностью заместить "производственный" фреймворк в принципе нет. Фреймворк управления идет поверх него. Тем не менее в методе есть артефакты - план фазы / этапа / релиза. Такой категории, как спринт в методе нет. Планирование выполняется в поточном режиме как в Kanban. Данная статья не является полным описанием методологии. Оно есть в руководстве, котое можно найти в моем тг-канале.
5. Если у нас есть несколько команд (разработка ПО, интеграция, тестирование), как ваш метод организует их взаимодействие? Чем это отличается от использования Scrum of Scrums или масштабированных фреймворков?
Я не изучал Scrum of Scrums. Взаимодействие организовано через систему ритуалов (у нас они являются частью так называемых событий). Подробнее, о тех событиях, которые мы используем можно почитать в руководстве.
6. И вообще, где подробное описание методологии? По Scrum есть официальные руководства и статье, доступные всем желающим. Ваша методология, я так понимаю, закрытая и платная – "закажите у меня, и вы не прогадаете?"
Сама методология бесплатная. Посмотрите, пожалуйста в тг-канале. Если не найдете, то напишите мне лично в тг @malakhov_andrey.
Надеюсь, автор
придет в сознаниеперейдет к конструкивному диалогу, иначе забавно видеть - пытается продвинуть свои идеи, но при возникновении вопросов занимает оборнительную позицию и пытается оскорбить вопрошающего.Сознание меня не покидало. На конструктивные вопросы и замечания буду давать конкретные ответы. Цель - прояснить свою позицию для тех, кому она интересна, а не тем, кто хочет обесценить или потроллить. Поэтому на ваши конкретные вопросы я ответил.
Пока выглядит, как в известном меме "в мире есть 20 стандартов, а я сделаю один, нормальный. И теперь в мире 21 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Спасибо за переход к конкретике и конструктиву. Я не сомневался, что мне придется отстаивать преимущества своего метода с аргументами, а не только с пеной у рта. Отличного дня!
BeLord
14.08.2025 14:24Первый момент. Стоимость принятия решения, риски принятия решения, стоимость владения решением, вопросы на которые реальный управленец отвечает на автомате при любой задаче, время обдумывания ответа может отличаться от сложности задачи.
Второй момент - согласования, вытекает из первого, если согласование элементарной вещи занимает дни/недели, то какую методологию не бери тут проблема в качестве менеджмента, а не методологии.
Третий момент - процессы никак не отменяют результат, если в описании процесса нет результата, так не процесс плох, а формализован он плохо.
Четвертый момент - делегирование, у части менеджеров с этим все плохо, как следствие они занимаются не эффективной деятельностью, например сами делают отчеты на каждый пчих. Проблема в процессах/PM book - нет, проблема в когнитивных способностях конкретного персонажа и понимании на каком участке процесса должны быть отчеты.
Пятый момент - распределение времени. Если взять к примеру разработку ПО, то на сам кодинг должно уходить не более 20% времени, тестирование 50%, документация (включая как раз те самые отчеты) 30%, тогда все будет работать с хорошими финансовыми показателями.
Шестой момент. Я видел кучу формализованных систем в которых отсутствовала финансовая составляющая, как следствие результат плачевен. Я когда ставлю задачу всегда понимаю, сколько стоит ее выполнение, а не просто тут задача "Петру" на 5 часов. Если у "Петра" стоимость часа работы 20 000 рублей, то грузить его всякой фигней это риск получить в лоб от финансового департамента за нерациональное расходование бюджета, однако подобный подход в реальном времени наблюдается не часто на рынке.
bromium
14.08.2025 14:24Не со всем согласен, но в целом поддерживаю. Сейчас вот хочу выделить время написать ответ автору, пока не решил, уподобляться ли его стилю
GreyNoise
14.08.2025 14:24PMBoK не методология и не фреймворк. Он не может применяться в этом качестве. Сказать "Мы управляем проектами по PMBoK" это примерно как сказать "мы строим химический завод по таблице Менделеева".
PMLogix Автор
14.08.2025 14:24Все верно. Мы тут поэтому используем термин "стандарт". Но я слышал очень многих, кто так говорит!
Pabloritas
14.08.2025 14:24Возможно на уровне глубочайшей компетенции, позволяющей налету рассуждать о различиях и особенностях управленческих моделей разница между процессным подходом и результативным очень ощутима и перевешивает остальные проблемы и риски менеджмента, но на мой взгляд разница, достаточная что бы говорить об отдельном подходе(модели) в статье не была продемонстрирована.
ИМХО, проблемы непонимания когда и в каком порядке использовать те или иные инструменты, описанные в разных моделях это родимое пятно от происхождения всех этих моделей: с начала люди изучает менеджмент, общую школу управления и набираются знаний о профессиональной сфере в которой они будет руководить и только потом они придумывают модели для проектного управления.
Если не забывать о главной особенности, что проект от сервиса/процесса отличается уникальностью, то очень многое становится на места, а заодно всплывает вопрос, а управление разработкой софта со стандартным функционалом для стандартной сферы применения может ли являться проектом или это сервис, знания о котором у конкретного исполнителя недостаточны.
Ведь если вы никогда не брали в руки сварочный аппарат, то попытка сварить две рандомные железяки для вас будет проектом, а для сварщика с двадцатилетним стажем, фигней не стоящей потраченного времени.
Тем кто работал исключительно в разработке может быть не очень понятно, но проект это не только необходимость проведения изыскательских работ на разных стадиях, включая формирование ТЗ, его корректировку, тестовые прогоны для доработки и опытную эксплуатацию, все эти стадии проходят автолюбители покупающие новую НИВУ в замен старой, например, и даже зная, что за машина и что от нее ждать, все эти стадии будут присутствовать. Проект подразумевает, что на практически каждом этапе требуется исследование и уникальный подход.
ИМХО разработка это не проект, вот интеграция разработанного это проект, да и то не всегда.
Кроме того при накоплении базы знаний в компании интеграторе, при внедрении этой БЗ в управленческие процессы, и их оптимизация с учетом набранного опыта нивелирует уникальность новых проектов превращая их в процесс/сервис. Стандартный, понятный, прозрачный и прогнозируемый на 99%.
И вот тут начинается вся свистопляска между правомочностью применения тех или иных моделей и подходов.
Ну и до кучи про жизнеспособность западных управленческих теорий. Как известно крупные деньги это бюджет или околобюджет и отрасль так или иначе подстраивается под те модели, что живут в кабинетах чиновников, а там зачастую жесточайшая иерархия со своим сводом правил для всех контрагентов, которые гнут под свои хотелки и подходы всех настолько в составе проектной команды оказывается генеральный директор вместе с коммерческим и начальниками департаментов, что по сути уже совсем другая песня, нежели проектная команда внутри компании.
T968
Для решения серьезных и очень серьезных задач годится только демократический централизм.
Это, например, когда генерал Гровс советуется с Оппенгеймером и отдает приказы.
Ну или Лаврентий Павлович, поговорив с советом главных конструкторов, предлагает кого-то расстрелять с отсрочкой.
PMLogix Автор
Эта тема - источник бесконечных споров, какой строй в каком контексте, временах, условиях будет эффективным. Конечно, это все важно, важно учитывать мнение, важно делегировать власть, ответственность и т.д., но это не исключает необходимости договариваться, формировать правила и действовать по согласованным правилам. Да, демократический централизм это рабочий вариант, но где-то он сработает, а где-то нет. А я говорю о том, что должны быть правила и как эти правила, по которым строится проектное управление, должны работать. В любом государстве есть свое законодательство. И если переложить тему статьи на модель управления государством, то мы говорим про то, как устроены законы, а не то, как организован, например, процесс принятия решений. Это все может быть организовано как угодно, в зависимости от того, как в компании договорились.