Comments 19
Для решения серьезных и очень серьезных задач годится только демократический централизм.
Это, например, когда генерал Гровс советуется с Оппенгеймером и отдает приказы.
Ну или Лаврентий Павлович, поговорив с советом главных конструкторов, предлагает кого-то расстрелять с отсрочкой.
Эта тема - источник бесконечных споров, какой строй в каком контексте, временах, условиях будет эффективным. Конечно, это все важно, важно учитывать мнение, важно делегировать власть, ответственность и т.д., но это не исключает необходимости договариваться, формировать правила и действовать по согласованным правилам. Да, демократический централизм это рабочий вариант, но где-то он сработает, а где-то нет. А я говорю о том, что должны быть правила и как эти правила, по которым строится проектное управление, должны работать. В любом государстве есть свое законодательство. И если переложить тему статьи на модель управления государством, то мы говорим про то, как устроены законы, а не то, как организован, например, процесс принятия решений. Это все может быть организовано как угодно, в зависимости от того, как в компании договорились.
Заинтересовал заголовок. «подробно расскажу - как сделать» в описании. А потом - «смотрите мой программный продукт». Всё скатилось к саморекламе. Нафиг…
Кажется, вы не до конца или не совсем внимательно прочитали статью. Потому что я достаточно подробно описал, каким требованиям должен соответствовать работающий фреймворк управления. А во-вторых это не программный продукт. Лучше напишите, с чем конкретно вы согласны. И что критического в том, что я предлагаю свой подход, если он работает и проверен?
Спасибо за комментарий. Я саму статью читать не стал и сразу полез смотреть в комментарии, чтобы понять стоит ли читать такую простыню. Благодаря вашему комментарию сэкономил время и нервные клетки :-)
А вы что ожидали у автора же а одет и ясно сказано: УПРРавление проектами и изменениями pmlogix
Читал и другие статьи автора — заголовки интригующие, по факту — ответов нет. Вначале автор хаит существующие методологии — они про процессы, а не про результат, регламенты, инструкции. Но в конце статьи при описании метода— хоп, а оказывается тоже нужны инструкции.
А вот эти вопросы «зачем мы это делаем» — заказчик заказал, что мы делаем — что заказчик заказал, кто делает — разработчики, как делаем — берем и разрабатываем.
чем это принципиально отличается от других методологий. Они тоже требуют определить что, кто , когда, тоже требуют definition of done и тпт.
Потому пафоса в статье много, а что предлагается взамен — да примрено то же самое.
«Определите, что назначен руководитель проекта нужной квалификации» — ну да, взяли рп на проект с большим опытом. Как еще определить? Наверное, автор имел ввиду что рп должен знать его метод парацельс — и тогда да, это рп нужной квалификации, а если pmbox — это плохой рп, так что ли?
получается все то же самое — сами должны определить что и когда делать, за что ругает автор другие методологии, но его методология — да то же самое, только с другим название , назвав это аспектами или артефактами, сути дела принципиально не меняет.
Вообще, назвав это результатоориентированным — еще ничего не значит, не видел ни одной методологии которая декларирует, что результат не важен, гдавное процесс. Просто чтобы добиться результата, требуется правильно выполнять процессы в нужной последовательности, но автор говорит — а вы сами там определитесь с «аспектами, артефактами». Впрочем, я уже повторяюсь — разницы автор не показал, по делу поругал других, а чем он принципиально отличается со своей методологией — донести не смог
Мне сложно уследить за вашей мыслью. Задачи хаить не было, была задача конструктивно показать недостатки, проявляющиеся на практике при использовании процессноориентированных стандартов управления проектами. И я их описал с примерами, настолько красочно, насколько смог.
То, что ни в одной моей статье вы не нашли ни одного ответа скорее говорит о том, что вы не пытались ничего извлечь, ну или задать конкретные вопросы, ответ на которые вас интересует. Я даю конкретные практические рекомендации и примеры, но они требуют релевантного опыта и насмотренности, чтобы ими воспользоваться. То, что у статей десятки сохранений, говорит об их пользе.
Про отличия методологий читайте статью внимательно. Все написано черным по белому. Если совсем не видите разницы, то я сдаюсь. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым.
В статье объяснено, почему мой подход является результатоориентированным, а не процессноориентированным. Но, если вы не поняли разницы, то я бессилен.
Речь не о цели метода. Конечно же любой метод нацелен на получение результата, а об его архитектуре, в которой результатам (артефактам) уделяется особое внимание.
Во многом Prince2 несмотря на использование процессов, как объекта архитектуры не исключает важной роли результатов (артефактов). Даже выделяет отдельный принцип "фокус на результате". Так что я развил и усилил этот принцип.
Если ваши вопросы и тейки будут нацелены на понимание разницы и плюсов предлагаемого подхода, буду рад прояснить непонятные моменты. Но я не вижу смысла перессказывать другими словами то, что я уже написал. Как говорится "Sapienti sat".
Мне сложно уследить за вашей мыслью
Я мог бы ответить, как Вы "Все написано черным по белому. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым. " или "Но, если вы не поняли ...., то я бессилен "
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Пока у меня сложилось впечатление, что просто переименовано/переупаковано все то, что есть в других методолгиях и подано, как некая панацея.
Тем более, мы на ИТ-ресурсе, в первую очередь интересны проекты по разработке ПО.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от 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 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Мне не близка критика без аргументов, которую я увидел в вашем посте. Просто нет столько времени, чтобы пытаться другими словами сказать то, что уже сказал, особенно, когда звучат обесценивающие нотки про "ответов нет". На конкретные вопросы отвечу.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от Scrum или упоминаемого Вами Prince2.
Об этом статья. Для начала полноценного участия в дискуссии предлагаю прочитать руководство по моему методу. Его можно здесь забрать. @PMLogixBot,а также посмотреть вебинар, по мотивам которого родилась эта статья https://vkvideo.ru/video-211146584_456239038?
Особенно слабо выглядит вот эта фраза:
"Как понять, что действительно важно? .... И тут нужно понять, что из этого набора важно именно в вашей организации и нужно ли добавить свои уникальные аспекты."
То есть, чтобы понять, нужно понять (спасибо, кэп)
В тексте статьи конкретно описано, как понять, см. часть про определение аспектов управления.
Далее по вашим конкретным вопросам:
1. В Scrum тоже есть набор обязательных артефактов. Чем ваша работа с артефактами отличается от этой практики?
Точно подмечено, что Scrum хорош тем, как работает с артефактами, НО он очень узок в покрытии аспектов (нет рисков, содержания и качества, ресурсов и т.д. и т.п.), а также охватывает крайне короткий горизонт планирования. Если угодно мой подход можно интерпретировать, как использование конкретики Scrum: артефакты + события + регулярность (привязка к структуре проекта) к более широкому спектру аспектов и как краткосрочным, так и долгосрочным критериям успеха и рискам проектов.
(продолжение следует)
(продолжение ответа)
2. Как смещение фокуса на артефакты влияет на ежедневные действия команды разработки или проектной команды? Можете описать день/неделю работы в вашей системе и в Scrum – чем они будут различаться? (Кстати, почему-то scrum обошил стороной в своей статье, а разве нет этот подход/методлология сейчас самый популряный в разщличных вариациях)
Для ежедневных действий будет некоторое сходство со Scrum. В руководстве по методу указаны артефакты и ритуалы для всех временных горизонтов (уровней), в т.ч. для ежедневного, но все же фокус именно на реализацию проектов, а не организацию процесса по разработке ПО. Про Scrum я уже написал в ответе на один из вопросов - он слишком узкий для того, чтобы быть проектным фреймворком, кроме того, он построен в результатоориентированной логике, так что критиковать его было бы бессмысленно ). В целом я не думаю, что много кто использует чистый Scrum, скорее отдельные элементы или вариации на тему.
3. Как ваш метод помогает в приоритизации задач и распределении ресурсов по сравнению с уже ставшим "классическим" спринтовым планированием? И вообще, что-то про планирование особо не увидел в вашей методологии, а я считаю это одним из ключевых моментов в любой методлоогии управления проектами.
Я думаю, что он никак его дополнительно не улучшает. Задачи полностью заместить "производственный" фреймворк в принципе нет. Фреймворк управления идет поверх него. Тем не менее в методе есть артефакты - план фазы / этапа / релиза. Такой категории, как спринт в методе нет. Планирование выполняется в поточном режиме как в Kanban. Данная статья не является полным описанием методологии. Оно есть в руководстве, котое можно найти в моем тг-канале.
5. Если у нас есть несколько команд (разработка ПО, интеграция, тестирование), как ваш метод организует их взаимодействие? Чем это отличается от использования Scrum of Scrums или масштабированных фреймворков?
Я не изучал Scrum of Scrums. Взаимодействие организовано через систему ритуалов (у нас они являются частью так называемых событий). Подробнее, о тех событиях, которые мы используем можно почитать в руководстве.
6. И вообще, где подробное описание методологии? По Scrum есть официальные руководства и статье, доступные всем желающим. Ваша методология, я так понимаю, закрытая и платная – "закажите у меня, и вы не прогадаете?"
Сама методология бесплатная. Посмотрите, пожалуйста в тг-канале. Если не найдете, то напишите мне лично в тг @malakhov_andrey.
Надеюсь, автор
придет в сознаниеперейдет к конструкивному диалогу, иначе забавно видеть - пытается продвинуть свои идеи, но при возникновении вопросов занимает оборнительную позицию и пытается оскорбить вопрошающего.
Сознание меня не покидало. На конструктивные вопросы и замечания буду давать конкретные ответы. Цель - прояснить свою позицию для тех, кому она интересна, а не тем, кто хочет обесценить или потроллить. Поэтому на ваши конкретные вопросы я ответил.
Пока выглядит, как в известном меме "в мире есть 20 стандартов, а я сделаю один, нормальный. И теперь в мире 21 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Спасибо за переход к конкретике и конструктиву. Я не сомневался, что мне придется отстаивать преимущества своего метода с аргументами, а не только с пеной у рта. Отличного дня!
Первый момент. Стоимость принятия решения, риски принятия решения, стоимость владения решением, вопросы на которые реальный управленец отвечает на автомате при любой задаче, время обдумывания ответа может отличаться от сложности задачи.
Второй момент - согласования, вытекает из первого, если согласование элементарной вещи занимает дни/недели, то какую методологию не бери тут проблема в качестве менеджмента, а не методологии.
Третий момент - процессы никак не отменяют результат, если в описании процесса нет результата, так не процесс плох, а формализован он плохо.
Четвертый момент - делегирование, у части менеджеров с этим все плохо, как следствие они занимаются не эффективной деятельностью, например сами делают отчеты на каждый пчих. Проблема в процессах/PM book - нет, проблема в когнитивных способностях конкретного персонажа и понимании на каком участке процесса должны быть отчеты.
Пятый момент - распределение времени. Если взять к примеру разработку ПО, то на сам кодинг должно уходить не более 20% времени, тестирование 50%, документация (включая как раз те самые отчеты) 30%, тогда все будет работать с хорошими финансовыми показателями.
Шестой момент. Я видел кучу формализованных систем в которых отсутствовала финансовая составляющая, как следствие результат плачевен. Я когда ставлю задачу всегда понимаю, сколько стоит ее выполнение, а не просто тут задача "Петру" на 5 часов. Если у "Петра" стоимость часа работы 20 000 рублей, то грузить его всякой фигней это риск получить в лоб от финансового департамента за нерациональное расходование бюджета, однако подобный подход в реальном времени наблюдается не часто на рынке.
Не со всем согласен, но в целом поддерживаю. Сейчас вот хочу выделить время написать ответ автору, пока не решил, уподобляться ли его стилю
Второй момент - согласования, вытекает из первого, если согласование элементарной вещи занимает дни/недели, то какую методологию не бери тут проблема в качестве менеджмента, а не методологии.
Мы тут под методологии подразумеваем правила, по которым работает менеджмент, в данном случае проектный, но и менеджмент компании в целом безусловно влияет. Теоретически правила можно поправить, исправить культуру компании сильнос сложнее.
Третий момент - процессы никак не отменяют результат, если в описании процесса нет результата, так не процесс плох, а формализован он плохо.
Процесс плох - как способ передачи ноу-хау по поводу того, что конкретно нужно делать. Плохо передает суть и образ результата, следовательно, его сложно воспроизвести с нужным качеством.
Четвертый момент - делегирование, у части менеджеров с этим все плохо, как следствие они занимаются не эффективной деятельностью, например сами делают отчеты на каждый пчих. Проблема в процессах/PM book - нет, проблема в когнитивных способностях конкретного персонажа и понимании на каком участке процесса должны быть отчеты.
Общая менеджмент культура, включая делегирование, касается как отдельных людей, так и компании в целом. Но в целом любые системы управления по сути это способ делегировать решение сложных задач без потери управляемости.
Шестой момент. Я видел кучу формализованных систем в которых отсутствовала финансовая составляющая, как следствие результат плачевен. Я когда ставлю задачу всегда понимаю, сколько стоит ее выполнение, а не просто тут задача "Петру" на 5 часов. Если у "Петра" стоимость часа работы 20 000 рублей, то грузить его всякой фигней это риск получить в лоб от финансового департамента за нерациональное расходование бюджета, однако подобный подход в реальном времени наблюдается не часто на рынке.
Оцифровка времени классно отрезвляет и позволяет задуматься, сколько нам стоят те или иные действия, включая исправление ошибок, переделки, управленческие ритуалы. Здорово, когда эти данные используются в принятии решений.
PMBoK не методология и не фреймворк. Он не может применяться в этом качестве. Сказать "Мы управляем проектами по PMBoK" это примерно как сказать "мы строим химический завод по таблице Менделеева".
Возможно на уровне глубочайшей компетенции, позволяющей налету рассуждать о различиях и особенностях управленческих моделей разница между процессным подходом и результативным очень ощутима и перевешивает остальные проблемы и риски менеджмента, но на мой взгляд разница, достаточная что бы говорить об отдельном подходе(модели) в статье не была продемонстрирована.
ИМХО, проблемы непонимания когда и в каком порядке использовать те или иные инструменты, описанные в разных моделях это родимое пятно от происхождения всех этих моделей: с начала люди изучает менеджмент, общую школу управления и набираются знаний о профессиональной сфере в которой они будет руководить и только потом они придумывают модели для проектного управления.
Если не забывать о главной особенности, что проект от сервиса/процесса отличается уникальностью, то очень многое становится на места, а заодно всплывает вопрос, а управление разработкой софта со стандартным функционалом для стандартной сферы применения может ли являться проектом или это сервис, знания о котором у конкретного исполнителя недостаточны.
Ведь если вы никогда не брали в руки сварочный аппарат, то попытка сварить две рандомные железяки для вас будет проектом, а для сварщика с двадцатилетним стажем, фигней не стоящей потраченного времени.
Тем кто работал исключительно в разработке может быть не очень понятно, но проект это не только необходимость проведения изыскательских работ на разных стадиях, включая формирование ТЗ, его корректировку, тестовые прогоны для доработки и опытную эксплуатацию, все эти стадии проходят автолюбители покупающие новую НИВУ в замен старой, например, и даже зная, что за машина и что от нее ждать, все эти стадии будут присутствовать. Проект подразумевает, что на практически каждом этапе требуется исследование и уникальный подход.
ИМХО разработка это не проект, вот интеграция разработанного это проект, да и то не всегда.
Кроме того при накоплении базы знаний в компании интеграторе, при внедрении этой БЗ в управленческие процессы, и их оптимизация с учетом набранного опыта нивелирует уникальность новых проектов превращая их в процесс/сервис. Стандартный, понятный, прозрачный и прогнозируемый на 99%.
И вот тут начинается вся свистопляска между правомочностью применения тех или иных моделей и подходов.
Ну и до кучи про жизнеспособность западных управленческих теорий. Как известно крупные деньги это бюджет или околобюджет и отрасль так или иначе подстраивается под те модели, что живут в кабинетах чиновников, а там зачастую жесточайшая иерархия со своим сводом правил для всех контрагентов, которые гнут под свои хотелки и подходы всех настолько в составе проектной команды оказывается генеральный директор вместе с коммерческим и начальниками департаментов, что по сути уже совсем другая песня, нежели проектная команда внутри компании.
ИМХО, проблемы непонимания когда и в каком порядке использовать те или иные инструменты, описанные в разных моделях это родимое пятно от происхождения всех этих моделей: с начала люди изучает менеджмент, общую школу управления и набираются знаний о профессиональной сфере в которой они будет руководить и только потом они придумывают модели для проектного управления.
Когда и что использовать точно не проистекает из общей менеджмент теории. Ее бы, конечно, знать не помешало, но тех, кто имеет хоть какое-то менеджерское образование (я, например, заканчивал факультет "Менеджмент" в ГУ-ВШЭ) ИМХО в разы меньше, чем тех, кто в курсе темы управления проектами. Так что это чересчур оптимистичный тейк.
Если не забывать о главной особенности, что проект от сервиса/процесса отличается уникальностью, то очень многое становится на места, а заодно всплывает вопрос, а управление разработкой софта со стандартным функционалом для стандартной сферы применения может ли являться проектом или это сервис, знания о котором у конкретного исполнителя недостаточны.
Бесспорно, управление процессом требует своих фреймворков и в управлении проектами не нуждается. Но не всю разработку софта можно сделать только на управлении процессами, особенно, когда есть интеграции и внедрение. Вы об этом также упомянули далее.
Ну и до кучи про жизнеспособность западных управленческих теорий. Как известно крупные деньги это бюджет или околобюджет и отрасль так или иначе подстраивается под те модели, что живут в кабинетах чиновников, а там зачастую жесточайшая иерархия со своим сводом правил для всех контрагентов, которые гнут под свои хотелки и подходы всех настолько в составе проектной команды оказывается генеральный директор вместе с коммерческим и начальниками департаментов, что по сути уже совсем другая песня, нежели проектная команда внутри компании.
Все же обычно чиновники не настолько погружены в процесс управления, чтобы там что-то сильно диктовать. Так что в их требования безусловно нужно вписываться, но это часто не мешает выстроить свой управленческий фреймворк. В коммерческих организациях все сильно попроще и даже большая часть проектной деятельности нерегламентирована.
Почему ваше проектное управление никогда не будет работать