Второй минус - ответственность, ИИ ошибся и кто виноват?
Человек ошибся и что ты с него возьмешь? Уволишь, максимум, да и то это не просто. А кем заменить уволенного — пока новый въедет, пройдет куча времени.
Не понял, описана просто база, то, что было «до» — это просто разгильдяйство.
Это стандратная практика — имитировать бурную деятельность, говорить «мы завалены задачами», хотя по факту это было не так. Зато удобно чуть что свалить на «много задач» , «не хватает рук».
Вижимо, директора разработки просто набо было гнать в шею — он наюивал себе цену, пытадся казаться добреньким для всех. Наверняка не задавал вопросы хотя бы такие «а когда это реально нужно» или «вместо какой задачи берем»
Прилетала задача от CEO - все бросали всё.
Ну да, и скорее всего сел не говорил бросать все. Он хотел, чтобы задачу взяли в работу — запланировали, дали бы оценки, назвали срок выполнения. Но в хаосе лучше лебезить перед тем кто выше и потом при люблм удобном случае, когда директора рангом ниже спрашивали «ну как там моя задача» многозначительно говорить «нам САМ поставли задачу, делаем его, потом вернемся к твои»
Считать capacity, акутализировать бэклог, планировать спринт — это БАЗА процесса разработки, которая просто не делалась, а имитировалась бурная деятельность.
пиэма не было, а потом, видимо, его наняли. Видимо, судя по статье, автора, который сделал необходимый минимум базовых вещей.
но по статье есть вопросы все же:
Каждую задачу оценивали в часах в три этапа: сначала аналитик, потом разработчик, потом архитектор.
не понял, это как это аналитик и архитектор могли оценить задачу джависта? Или фронтэндщика? Впервые вообще-то вижу, чтоб аналитик или архитектор оценку задач разработки давали. Не, ну если задачи типовые, то возможно.
После релиза считали, сколько оценочных часов реально дошло до пользователей - это и была фактическая ёмкость
Что такое «оценочные часы дошли до пользователей»? Сделали задач на 40 часов, задеплоили — но юзеры стали пользоваться только доработками на 20 часов, так что ли? Не понятно, нужны пояснения
Отдельно смотрели точность плана: какой процент обещанного вышел в срок. Первое нужно для расчёта backlog, второе - для оценки предсказуемости команды.
Что значит процент общеанного в срок? Есть три задачи, выполнили 2 (одна на 3 часа, другая на 2 часа, а не выполненная на 30 часов) — каков процент обещанного? И как это используется для бэклога и оценки предсказуемости? Несделанное возвращаете в бэклог а оттуда в новый спринт — дык, это тоже база.
Для каждой системы определили одного человека: не "кто использует", а "кто отвечает за то, как система работает". Это дало точку ответственности для каждого входящего запроса.
Звучит красиво на словах, а на деле — прилетело три запроса от разных директоров депратаментов, все они, например, в ранге вице-перзидента или зама гендира — кого первым возьмете, кого в последнюю очередь, если все трое просят срочно и сразу?
Далее на схеме:
Если нет оценки и владельца вернуть инициатору
Не понял, как инициатор может дать оценку? Оценку дает разработка.
Далее:
Зафиксировали правило: 50% рабочего времени разработчик тратит на создание нового. Остальное - исправление ошибок, технический долг, переключения.
Это все здорово, но что если выяснилось, что в стсьеме накопилось куча багов, многие из них коитические и на их фикс нужно…. А фиг знает сколько нужно, но часов 300 точно — что будете дедать со своим правилом?
Да, и добавлю: это прекрасно, когда делаешь типовые задачи и можно давать оценку, особенно багам — баг на то и есть баг, что пока не понятно, как его испавлять и сколько времени на это нужно. Как будете планировать загрузку клманды тогда? Заплагировали что 160 часов на разработку остальное на три бага — но неделя прошла а еще даже один не пофиксили?
Привыкли к тому, что сроки - разговор ни о чём.
Ну да, потому что был бардак, потому что ИБД — все пипец как заняты, только никто не может сказать чем и плчему это важно
Три месяца. Не три года.
Ха-ха. Видимо скоро придет сео и скажет, что команду надо бы прдсократить. Зачем кормить лишние рты.
Изменилось другое: компания начала выбирать, что делать, и прекратила делать то, что не нужно
То ли плакать, то ли смеяться. А зачем деалли то, что не нужно? Ибд? Прям как в госконторах. Кто то сильно ездил сео по ушам
Нет культуры отказа. Если руководители не готовы говорить "нет" на запросы сверху, BP-фильтр перегружается исключениями. Всё "срочное" попадает в обход правил.
Не понял, а азчем отказывать? Если есть что то срочное, то инициатор срочного должен определить или согласовать, что выбрасываем из спринта / ближайшего плана. Если это сам сео — пусть и скажет, определится с другими постановщиками задач, если не сео — то пусть с другими департаментами договорится, чья задача «срочнее». это уже не проблема отдела разработки.
Просто руководитель разработки был либо тюфяк либо, скорее всего, прожженный конъюнктурщик («а семь шапок сможешь? — да не вопрос!»)
Одно исключение от CEO - и модель начинает разрушаться.
Значит хреновая у вас модель. И чуть что всегда можно свалить на сео. Дескать, он не знал текущих приоритетов.
я же убежден, нормадьная модель не разрушится от такого, а как надо действовать — написал выше. И не стесняться сообщать сео текущую ситуацию а не подобострастно поддакивать(«а то вдруг скажу нет и уволят нафиг»)
Очередь задач становится управлением только после жёсткого отбора по деньгам, владельцу и ресурсу. Всё остальное - список желаний без обязательств.
Это вы переоткрыли заново основы теории менеджмента, проектный треугольник и иже с ним.
Методика была простой, но требовала дисциплины.
Дык, это и есть ключевое. Это то, чем должен заниматься ПМ. Но они привыкли просиживать штаны на дейликах, «коммуницировать» (сиречь балаболить не по делу) и чуть что — спихивать все на команду разработки. А как попросишь capacity посчитать — тут же садятся в лужу. От какой «высшей математике» как риск-менеджмент вообще умолчу.
В общем, статья хорошая, показательная. Жаль, что такие вещи, что должно быть само собой разумеющимся, часто не делаются — лень, некомпетентность, отсутствие дисциплины.
Не понимаю, почему вы называете «статьей» нейрослоп, который выдала нейронка. Здесь нет ни одного нормального предлодения. Кроме стандартного текста дисклеймера, который вы также попоросили сгенерить нейронку из страха, что вас гипотетически накажут за эту статью.
никакхи признаков статьи не вижу — о чем, для чего, завязка, выводы. «Что доказывает» — а вы оказывается что то хотели доказать? А что? И что доказывает что разрабочтки по 7 раз на дню проверяют разрешения, например. Какой вывод должен сделать читатель? «Вот и думайте»?
вы даже не удосужились под спойлер заказтать куски кода — зачем нам оэто в статье без спойлера?
извините, вы просто скопипастили то, что выдала нейронка, не удосужились причесать это нормально, в виде статьи, даже поленились промт в нейронку написать. Считаю, проявили полное неуважение к читателям. Высосали из пальца «статью» просто скормив результаты декомпиляции. И прикрыв это все «я не автор, потому заюзал ии» ну раз не автор, так и не писали бы! С экономили бы нам кучу времени.
Зато желтый заголовок написать догадались. Вот только доказательной базы «аудита» никакой что-то не увидел. Что доказывали то хоть?
«Слышали звон, да не знали, где он.» Возможно, отобрали аккредитацию за то, что студенты не были офрмлены должным образом, или компания по факту занималась не задекларированной деятельностью. А «слишком много студентов» как правильно уже откомментировали — такого критерия нет. И это не запрещено.
По-моему, любого поставит в тупик вопрос «сколько раз вы за год признавали свои ошибки?»
А что, кто-то считает? Если один раз — ну тогда еще можно было бы запомнить.
Далее: правильно сказаны про навыки. Делиться идеями и не нести пургу — надо уметь и иметь эти самые идеи. Вон товарищ выше написал — руковобство не хотело решать про лемы. Ну значит у рокводсства не было этих проблем.
Часто наблюдал «а давайте сделаем так», но на вопрос что это даст — внятного ответа и не было. Оказывалось, чтобы кому то стало проще что то делать за счет других.
Не думаю, что руковолство хорошие идеи прямо будет отметать — не ну эффективных манагеров никто не отменял — присвоить себе хорошую идею да, могут, но если «хорошую идею» не принимают, то может, она хороша только в голове самого автора идеи.
А вообще, вся эта новоядвенная терминология и явления «психологическая безопасность» для чего она? Надо выполнять свою работу хорошо и быть ответственным. Если видишь проблему — надо ее доносить. Не принимают — ну, если считаешь что она важна и нельзя с таким жить — ну, увольняйся тогда.
Честность — вот главное качество, остальное производные.
и еще позабавило в статье про «дурацкий выбор» между честностью и уважением. А что, нельзя честно и уважительно? Конструктивно, по делу, вежливо? Это же и есть те базовые навыки коммуникаций в обществе.
Если приходит с идеей «вы дуркаи и ничего не понимаете» — то такой в коллективе не нужен, зато по мнению автора статьи, это высокая психологическая безопасность в коллективе. Бред.
Вот это и должно настораживать, а не факт использования ИИ. Люди настолько обленились, что для подавляющего большинства интернет — это развлечения и соцсети, а не кладезь знаний. ИИ дает возможности, а нежелание и лень разбираться — исходят от человека
Спасибо, полезно. А подскажите, в чьи обязанности должно входить написание инструкций, планов онбординга, составления проверочных заданий и их проверка, на ваш взгляд, и сколько времени на хто треьуется?
Я мог бы ответить, как Вы "Все написано черным по белому. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым. " или "Но, если вы не поняли ...., то я бессилен "
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Пока у меня сложилось впечатление, что просто переименовано/переупаковано все то, что есть в других методолгиях и подано, как некая панацея.
Тем более, мы на ИТ-ресурсе, в первую очередь интересны проекты по разработке ПО.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от 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 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Хм, интересно, а откуда деньги у фонда, кто за ним стоит, реальные бенефициары, вряд ли бабушкин из собственного кармана будет это делать. Такие серьезные шаги просто так, спонтанно не делаются
Ну что же вы самое интересное не сделали и не рассказали, что там опасного в их репозитории, понимаю что много всего там, ну хотя бы ии натравили. Тогда статья была бы гораздо полезнее и интереснее. Но все равно спасибо
Человек ошибся и что ты с него возьмешь? Уволишь, максимум, да и то это не просто. А кем заменить уволенного — пока новый въедет, пройдет куча времени.
Не понял, описана просто база, то, что было «до» — это просто разгильдяйство.
Это стандратная практика — имитировать бурную деятельность, говорить «мы завалены задачами», хотя по факту это было не так. Зато удобно чуть что свалить на «много задач» , «не хватает рук».
Вижимо, директора разработки просто набо было гнать в шею — он наюивал себе цену, пытадся казаться добреньким для всех. Наверняка не задавал вопросы хотя бы такие «а когда это реально нужно» или «вместо какой задачи берем»
Прилетала задача от CEO - все бросали всё.
Ну да, и скорее всего сел не говорил бросать все. Он хотел, чтобы задачу взяли в работу — запланировали, дали бы оценки, назвали срок выполнения. Но в хаосе лучше лебезить перед тем кто выше и потом при люблм удобном случае, когда директора рангом ниже спрашивали «ну как там моя задача» многозначительно говорить «нам САМ поставли задачу, делаем его, потом вернемся к твои»
Считать capacity, акутализировать бэклог, планировать спринт — это БАЗА процесса разработки, которая просто не делалась, а имитировалась бурная деятельность.
пиэма не было, а потом, видимо, его наняли. Видимо, судя по статье, автора, который сделал необходимый минимум базовых вещей.
но по статье есть вопросы все же:
не понял, это как это аналитик и архитектор могли оценить задачу джависта? Или фронтэндщика? Впервые вообще-то вижу, чтоб аналитик или архитектор оценку задач разработки давали. Не, ну если задачи типовые, то возможно.
Что такое «оценочные часы дошли до пользователей»? Сделали задач на 40 часов, задеплоили — но юзеры стали пользоваться только доработками на 20 часов, так что ли? Не понятно, нужны пояснения
Что значит процент общеанного в срок? Есть три задачи, выполнили 2 (одна на 3 часа, другая на 2 часа, а не выполненная на 30 часов) — каков процент обещанного? И как это используется для бэклога и оценки предсказуемости? Несделанное возвращаете в бэклог а оттуда в новый спринт — дык, это тоже база.
Звучит красиво на словах, а на деле — прилетело три запроса от разных директоров депратаментов, все они, например, в ранге вице-перзидента или зама гендира — кого первым возьмете, кого в последнюю очередь, если все трое просят срочно и сразу?
Далее на схеме:
Не понял, как инициатор может дать оценку? Оценку дает разработка.
Далее:
Это все здорово, но что если выяснилось, что в стсьеме накопилось куча багов, многие из них коитические и на их фикс нужно…. А фиг знает сколько нужно, но часов 300 точно — что будете дедать со своим правилом?
Да, и добавлю: это прекрасно, когда делаешь типовые задачи и можно давать оценку, особенно багам — баг на то и есть баг, что пока не понятно, как его испавлять и сколько времени на это нужно. Как будете планировать загрузку клманды тогда? Заплагировали что 160 часов на разработку остальное на три бага — но неделя прошла а еще даже один не пофиксили?
Ну да, потому что был бардак, потому что ИБД — все пипец как заняты, только никто не может сказать чем и плчему это важно
Ха-ха. Видимо скоро придет сео и скажет, что команду надо бы прдсократить. Зачем кормить лишние рты.
То ли плакать, то ли смеяться. А зачем деалли то, что не нужно? Ибд? Прям как в госконторах. Кто то сильно ездил сео по ушам
Не понял, а азчем отказывать? Если есть что то срочное, то инициатор срочного должен определить или согласовать, что выбрасываем из спринта / ближайшего плана. Если это сам сео — пусть и скажет, определится с другими постановщиками задач, если не сео — то пусть с другими департаментами договорится, чья задача «срочнее». это уже не проблема отдела разработки.
Просто руководитель разработки был либо тюфяк либо, скорее всего, прожженный конъюнктурщик («а семь шапок сможешь? — да не вопрос!»)
Значит хреновая у вас модель. И чуть что всегда можно свалить на сео. Дескать, он не знал текущих приоритетов.
я же убежден, нормадьная модель не разрушится от такого, а как надо действовать — написал выше. И не стесняться сообщать сео текущую ситуацию а не подобострастно поддакивать(«а то вдруг скажу нет и уволят нафиг»)
Это вы переоткрыли заново основы теории менеджмента, проектный треугольник и иже с ним.
Дык, это и есть ключевое. Это то, чем должен заниматься ПМ. Но они привыкли просиживать штаны на дейликах, «коммуницировать» (сиречь балаболить не по делу) и чуть что — спихивать все на команду разработки. А как попросишь capacity посчитать — тут же садятся в лужу. От какой «высшей математике» как риск-менеджмент вообще умолчу.
В общем, статья хорошая, показательная. Жаль, что такие вещи, что должно быть само собой разумеющимся, часто не делаются — лень, некомпетентность, отсутствие дисциплины.
Не понимаю, почему вы называете «статьей» нейрослоп, который выдала нейронка. Здесь нет ни одного нормального предлодения. Кроме стандартного текста дисклеймера, который вы также попоросили сгенерить нейронку из страха, что вас гипотетически накажут за эту статью.
никакхи признаков статьи не вижу — о чем, для чего, завязка, выводы. «Что доказывает» — а вы оказывается что то хотели доказать? А что? И что доказывает что разрабочтки по 7 раз на дню проверяют разрешения, например. Какой вывод должен сделать читатель? «Вот и думайте»?
вы даже не удосужились под спойлер заказтать куски кода — зачем нам оэто в статье без спойлера?
извините, вы просто скопипастили то, что выдала нейронка, не удосужились причесать это нормально, в виде статьи, даже поленились промт в нейронку написать. Считаю, проявили полное неуважение к читателям. Высосали из пальца «статью» просто скормив результаты декомпиляции. И прикрыв это все «я не автор, потому заюзал ии» ну раз не автор, так и не писали бы! С экономили бы нам кучу времени.
Зато желтый заголовок написать догадались. Вот только доказательной базы «аудита» никакой что-то не увидел. Что доказывали то хоть?
У нейронок, как правило, все норм с запятыми. Что то вы не то сказали
«Слышали звон, да не знали, где он.» Возможно, отобрали аккредитацию за то, что студенты не были офрмлены должным образом, или компания по факту занималась не задекларированной деятельностью. А «слишком много студентов» как правильно уже откомментировали — такого критерия нет. И это не запрещено.
Скорее не …ляди, а …асы
По-моему, любого поставит в тупик вопрос «сколько раз вы за год признавали свои ошибки?»
А что, кто-то считает? Если один раз — ну тогда еще можно было бы запомнить.
Далее: правильно сказаны про навыки. Делиться идеями и не нести пургу — надо уметь и иметь эти самые идеи. Вон товарищ выше написал — руковобство не хотело решать про лемы. Ну значит у рокводсства не было этих проблем.
Часто наблюдал «а давайте сделаем так», но на вопрос что это даст — внятного ответа и не было. Оказывалось, чтобы кому то стало проще что то делать за счет других.
Не думаю, что руковолство хорошие идеи прямо будет отметать — не ну эффективных манагеров никто не отменял — присвоить себе хорошую идею да, могут, но если «хорошую идею» не принимают, то может, она хороша только в голове самого автора идеи.
А вообще, вся эта новоядвенная терминология и явления «психологическая безопасность» для чего она? Надо выполнять свою работу хорошо и быть ответственным. Если видишь проблему — надо ее доносить. Не принимают — ну, если считаешь что она важна и нельзя с таким жить — ну, увольняйся тогда.
Честность — вот главное качество, остальное производные.
и еще позабавило в статье про «дурацкий выбор» между честностью и уважением. А что, нельзя честно и уважительно? Конструктивно, по делу, вежливо? Это же и есть те базовые навыки коммуникаций в обществе.
Если приходит с идеей «вы дуркаи и ничего не понимаете» — то такой в коллективе не нужен, зато по мнению автора статьи, это высокая психологическая безопасность в коллективе. Бред.
Senior vibe coder
Вот это и должно настораживать, а не факт использования ИИ. Люди настолько обленились, что для подавляющего большинства интернет — это развлечения и соцсети, а не кладезь знаний. ИИ дает возможности, а нежелание и лень разбираться — исходят от человека
Как щаз модно стало говорить — кто понял, тот понял )
Дисклеймер в конце в принципе и не особо-то нужен, так как к нему уже совсем всё понятно становится.
Судя по первому комменту, все таки дисклеймер нужен
Свечку держали?
Спасибо, полезно. А подскажите, в чьи обязанности должно входить написание инструкций, планов онбординга, составления проверочных заданий и их проверка, на ваш взгляд, и сколько времени на хто треьуется?
Что такое демонстративные специальности? А какие надо было выбрать «неспециально»?
Все говорят , что делать (научиться видеть разницу), но никто не рассказывает, как.
Что за система, которая создает условия для выгорания?
Что за система, которая не создает условия для выгорания?
Медицина, работа в мчс, учителем в школе, работа шахтером в шахте— это системы, создающие условия для выгорания или нет? И что такое выгорание?
Н-да, хорошо философствовать, особенно если не платишь из своего кармана за неэффективность.
Почему-то не упоминается, а где та грань или критерий, чтобы понять — это лень или «выгорание».
Я мог бы ответить, как Вы "Все написано черным по белому. В этом случае я категорически вам не рекомендую читать другие статьи, и что-то искать в них. Скорее всего результат будет тем же, т.е. нулевым. " или "Но, если вы не поняли ...., то я бессилен "
Но я сделаю вид, что не заметил Вашей пассивной агрессии, Вашего высокомерного "кто не дурак, тот меня поймет". "Интересный", конечно, подход: цель-то статьи продвинуть свою методологию, а когда пошли вопросы по ней, переход на личности (известно же, когда не хватает аргументов, переходят на личности).
Пока у меня сложилось впечатление, что просто переименовано/переупаковано все то, что есть в других методолгиях и подано, как некая панацея.
Тем более, мы на ИТ-ресурсе, в первую очередь интересны проекты по разработке ПО.
И тут вообще не увидел, чем отличается ваша "методология" от известных и распространненных других, например от 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 стандарт". А здесь пока вещь в себе, без руководства и описания.
В общем, хотелось бы видеть конкретные, четкие ответы на вопросы выше, без софистики и переходы на личности.
Не со всем согласен, но в целом поддерживаю. Сейчас вот хочу выделить время написать ответ автору, пока не решил, уподобляться ли его стилю
Хм, интересно, а откуда деньги у фонда, кто за ним стоит, реальные бенефициары, вряд ли бабушкин из собственного кармана будет это делать. Такие серьезные шаги просто так, спонтанно не делаются
Ну что же вы самое интересное не сделали и не рассказали, что там опасного в их репозитории, понимаю что много всего там, ну хотя бы ии натравили. Тогда статья была бы гораздо полезнее и интереснее. Но все равно спасибо