Спасибо, полезно. А подскажите, в чьи обязанности должно входить написание инструкций, планов онбординга, составления проверочных заданий и их проверка, на ваш взгляд, и сколько времени на хто треьуется?
Я мог бы ответить, как Вы "Все написано черным по белому. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым. " или "Но, если вы не поняли ...., то я бессилен "
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Пока у меня сложилось впечатление, что просто переименовано/переупаковано все то, что есть в других методолгиях и подано, как некая панацея.
Тем более, мы на ИТ-ресурсе, в первую очередь интересны проекты по разработке ПО.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от 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 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Хм, интересно, а откуда деньги у фонда, кто за ним стоит, реальные бенефициары, вряд ли бабушкин из собственного кармана будет это делать. Такие серьезные шаги просто так, спонтанно не делаются
Ну что же вы самое интересное не сделали и не рассказали, что там опасного в их репозитории, понимаю что много всего там, ну хотя бы ии натравили. Тогда статья была бы гораздо полезнее и интереснее. Но все равно спасибо
Читал и другие статьи автора — заголовки интригующие, по факту — ответов нет. Вначале автор хаит существующие методологии — они про процессы, а не про результат, регламенты, инструкции. Но в конце статьи при описании метода— хоп, а оказывается тоже нужны инструкции.
А вот эти вопросы «зачем мы это делаем» — заказчик заказал, что мы делаем — что заказчик заказал, кто делает — разработчики, как делаем — берем и разрабатываем.
чем это принципиально отличается от других методологий. Они тоже требуют определить что, кто , когда, тоже требуют definition of done и тпт.
Потому пафоса в статье много, а что предлагается взамен — да примрено то же самое.
«Определите, что назначен руководитель проекта нужной квалификации» — ну да, взяли рп на проект с большим опытом. Как еще определить? Наверное, автор имел ввиду что рп должен знать его метод парацельс — и тогда да, это рп нужной квалификации, а если pmbox — это плохой рп, так что ли?
получается все то же самое — сами должны определить что и когда делать, за что ругает автор другие методологии, но его методология — да то же самое, только с другим название , назвав это аспектами или артефактами, сути дела принципиально не меняет.
Вообще, назвав это результатоориентированным — еще ничего не значит, не видел ни одной методологии которая декларирует, что результат не важен, гдавное процесс. Просто чтобы добиться результата, требуется правильно выполнять процессы в нужной последовательности, но автор говорит — а вы сами там определитесь с «аспектами, артефактами». Впрочем, я уже повторяюсь — разницы автор не показал, по делу поругал других, а чем он принципиально отличается со своей методологией — донести не смог
Так это к вам вопрос, я сразу написал, что не понятно. И да, то ли вас позвали, а вы испытали ужас, то ли вы зачем то всех созвали и зафейлились — пока такие варианту на ум приходят
Детали реализации, определяют конкретные программисты, точнее, они определяются в ходе ежедневных встреч, которые в Agile называются Daily meeting
Извините, это бред, дейли митинг не для обсуждения деталей реалзиации, это раз, во вторых - можете прислать пруф, где в agile манифесте или еще каком документе agile написано про daily meetings?
Ну и конечно, видно, что статью генерировали с помощью ИИ — издалека что то похожее на статью, вблизи — а нет, показалось….
Все верно, но очень часто многие же жалуются на коллег и менеджмент, получается, они и есть те самые коллеги, с кем другим не повезло. Непривычно и неприятно же думать, что проблема в тебе, а не в других. Вот и получается, что бедный интроверт, который не умеет общаться, не интересуется другими и компанией, не знает о чем говорить, не знает даже, как его коллеги выглядят, потом садится и пишет вот такие статьи. А руководство пытается это хоть как то изменить, вбухивая деньги на это. Да, эффективность сомнительная может, если плохо организованно, да, эйчары филонят и не на своем месте, если не организовали не растрясли интровертов. С другой стороны, взрослые люди, как тут правильно отметили — командировки это здорово для смены обстановки, приехать, пообщаться, увидеть живьем людей, с кем работаешь.
Вообще, всегда поражало, когда люди оправдывают свои недостатки. Я интроверт, потому не умею общаться, я гуманитарий — потому не разбираюсь минимально в технике, в логике, я технарь — потому пишу с ошибками через слово. ..
Да понятно, а оказывается, она интроверт со страхом общения с людьми, при этом ит проджект менеджер 10+ лет. Что и настораживает. Кто то не на своем месте. Да и еще открыто пишет об этом )))
Майкрософт: и хочется, и колется. И вроде бы санкции надо соблюдать, и вроде бы бабки хочется продолжать получать и клиентскую базу не терять (а вдруг все вернется на круги своя)
Двуличие их мы все видим когда в вынь11 нет нет и вылезет окно с настройками с устаревшим интерфейсом. ))
Свечку держали?
Спасибо, полезно. А подскажите, в чьи обязанности должно входить написание инструкций, планов онбординга, составления проверочных заданий и их проверка, на ваш взгляд, и сколько времени на хто треьуется?
Что такое демонстративные специальности? А какие надо было выбрать «неспециально»?
Все говорят , что делать (научиться видеть разницу), но никто не рассказывает, как.
Что за система, которая создает условия для выгорания?
Что за система, которая не создает условия для выгорания?
Медицина, работа в мчс, учителем в школе, работа шахтером в шахте— это системы, создающие условия для выгорания или нет? И что такое выгорание?
Н-да, хорошо философствовать, особенно если не платишь из своего кармана за неэффективность.
Почему-то не упоминается, а где та грань или критерий, чтобы понять — это лень или «выгорание».
Я мог бы ответить, как Вы "Все написано черным по белому. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым. " или "Но, если вы не поняли ...., то я бессилен "
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Пока у меня сложилось впечатление, что просто переименовано/переупаковано все то, что есть в других методолгиях и подано, как некая панацея.
Тем более, мы на ИТ-ресурсе, в первую очередь интересны проекты по разработке ПО.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от 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 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Не со всем согласен, но в целом поддерживаю. Сейчас вот хочу выделить время написать ответ автору, пока не решил, уподобляться ли его стилю
Хм, интересно, а откуда деньги у фонда, кто за ним стоит, реальные бенефициары, вряд ли бабушкин из собственного кармана будет это делать. Такие серьезные шаги просто так, спонтанно не делаются
Ну что же вы самое интересное не сделали и не рассказали, что там опасного в их репозитории, понимаю что много всего там, ну хотя бы ии натравили. Тогда статья была бы гораздо полезнее и интереснее. Но все равно спасибо
Читал и другие статьи автора — заголовки интригующие, по факту — ответов нет. Вначале автор хаит существующие методологии — они про процессы, а не про результат, регламенты, инструкции. Но в конце статьи при описании метода— хоп, а оказывается тоже нужны инструкции.
А вот эти вопросы «зачем мы это делаем» — заказчик заказал, что мы делаем — что заказчик заказал, кто делает — разработчики, как делаем — берем и разрабатываем.
чем это принципиально отличается от других методологий. Они тоже требуют определить что, кто , когда, тоже требуют definition of done и тпт.
Потому пафоса в статье много, а что предлагается взамен — да примрено то же самое.
«Определите, что назначен руководитель проекта нужной квалификации» — ну да, взяли рп на проект с большим опытом. Как еще определить? Наверное, автор имел ввиду что рп должен знать его метод парацельс — и тогда да, это рп нужной квалификации, а если pmbox — это плохой рп, так что ли?
получается все то же самое — сами должны определить что и когда делать, за что ругает автор другие методологии, но его методология — да то же самое, только с другим название , назвав это аспектами или артефактами, сути дела принципиально не меняет.
Вообще, назвав это результатоориентированным — еще ничего не значит, не видел ни одной методологии которая декларирует, что результат не важен, гдавное процесс. Просто чтобы добиться результата, требуется правильно выполнять процессы в нужной последовательности, но автор говорит — а вы сами там определитесь с «аспектами, артефактами». Впрочем, я уже повторяюсь — разницы автор не показал, по делу поругал других, а чем он принципиально отличается со своей методологией — донести не смог
Да
А в чем (какой тулзе) делали эти схемы? Видимо, под этим понимается «онлайн-доска» или вы про что то другое?
Capcut
Или davinci
Так это к вам вопрос, я сразу написал, что не понятно. И да, то ли вас позвали, а вы испытали ужас, то ли вы зачем то всех созвали и зафейлились — пока такие варианту на ум приходят
Извините, это бред, дейли митинг не для обсуждения деталей реалзиации, это раз, во вторых - можете прислать пруф, где в agile манифесте или еще каком документе agile написано про daily meetings?
Ну и конечно, видно, что статью генерировали с помощью ИИ — издалека что то похожее на статью, вблизи — а нет, показалось….
Не понял, сравнивают мягкое с теплым и яблоки с апельсинами?
Как подход к разработке заменит ии? Ии это не подход к разработке!
Все верно, но очень часто многие же жалуются на коллег и менеджмент, получается, они и есть те самые коллеги, с кем другим не повезло. Непривычно и неприятно же думать, что проблема в тебе, а не в других. Вот и получается, что бедный интроверт, который не умеет общаться, не интересуется другими и компанией, не знает о чем говорить, не знает даже, как его коллеги выглядят, потом садится и пишет вот такие статьи. А руководство пытается это хоть как то изменить, вбухивая деньги на это. Да, эффективность сомнительная может, если плохо организованно, да, эйчары филонят и не на своем месте, если не организовали не растрясли интровертов. С другой стороны, взрослые люди, как тут правильно отметили — командировки это здорово для смены обстановки, приехать, пообщаться, увидеть живьем людей, с кем работаешь.
Вообще, всегда поражало, когда люди оправдывают свои недостатки. Я интроверт, потому не умею общаться, я гуманитарий — потому не разбираюсь минимально в технике, в логике, я технарь — потому пишу с ошибками через слово. ..
Да понятно, а оказывается, она интроверт со страхом общения с людьми, при этом ит проджект менеджер 10+ лет. Что и настораживает. Кто то не на своем месте. Да и еще открыто пишет об этом )))
Суперидея! А паспорт не нужен теперь? Или и паспорт, и суперприложение это, и госуслуги, и … еще что то.
Майкрософт: и хочется, и колется. И вроде бы санкции надо соблюдать, и вроде бы бабки хочется продолжать получать и клиентскую базу не терять (а вдруг все вернется на круги своя)
Двуличие их мы все видим когда в вынь11 нет нет и вылезет окно с настройками с устаревшим интерфейсом. ))