Если на крупный проект ставят человека из генерирующей компании или шоколадной фабрики, пусть даже с хорошим образованием, и если он не делал сложных проектов в разработке, с нуля, или в непростом окружении, то шансы упороть проект весьма высоки.

Даже если человек уже давно в ИТ, лет 15, но не делал проекты именно по разработке, причём с нуля, то шансы упороть проект тоже высоки.

Ключевая мысль - если менеджер не понимает, что такое технический долг, не осознаёт значимость архитектурной работы и не понимает менталитет инженеров, то это плохая история. Если верит в линейное масштабирование ресурсов, прямую зависимость продуктивности от числа нажатий клавиш на клавиатуре, то это тоже плохая история.

А от силы пиздюлей есть прямая зависимость? В шарашку если загнать инженеров, будет продукт?

Прямой завимости нет, это не эффективно, но может быть результативно, продукт будет скорее всего. Точнее прямая зависимость есть, но она не линейная.

На моём опыте зачастую менеджеры не умеют определять цели. Окончательные цели, которые выражаются в определённом денежном эквиваленте заработанных или сэкономленных средств для конкретного пула заказчиков, подменяются иными целями. Какие они могут быть:
1. Политические цели (продвижение по службе, повышение заработной платы, прочее);
2. Цели артефактов проекта (то, о чём говорил Роман);
3. Цели самосовершенствования (в этом случае цели проекта лишь сторонний инструмент достижения своих целей);
4. Цель минимизации работы (сидеть из дома и втыкать в телек с чипсонами - наивысший приоритет).
5. Цели компании-исполнителя.
6. Прочие.

Это самый первый уровень факапа у менеджеров. После этого идут подуровни:
- Недостаток квалификации
- Недостаточность входящих данных
- Управленческие блоки
- Недостаток ресурсов
- Прочие

В оптимальном случае, менеджер и аналитик должны ставить интересы заказчиков в приоритет. А порой даже интересы продукта, его успешности. Конечно есть роль продуктового менеджера, который берёт на себя это роль и начинает защищать позицию, но нормальных специалистов этой профессии я видел очень мало. Зачастую на них экономят.

Вообще научиться в аналитике протягивать к целям бизнес-требования, а от них функциональные требования не все могут смотреть. Вернее, смотреть могут не только лишь все, мало кто может это делать.

И начинается генерация требований из воздуха.
Вообще интересно отметить, что пока ты не научишься почти на уровне буддиста задавать себе вопросы в голове "Нафига?", то цели ты нормально проставлять не научишься.
Вот сидишь и думаешь:
- Зачем заказчик выдал такое требование?
- Затем-то.
- А зачем это ему?
- Затем-то?
- А это ему зачем?
- Вот для того что бы: ...

(и потом надо помнить. что твои суждения могут быть неверными и надо идти уточнять их у стейкхолдеров)

В 70% случаев у менеджера проекта будет следующая фраза, когда он увидит, что ты этим занимаешься: "Тебе заняться нечем? Задачу поставили, всё понятно что надо сделать, пиши схемы и логику!". Это с учётом постановки в абзац от одного Васи Пупкина кому может быть надо автоматизировать 5 минутную работу, которой он занимается раз в месяц.

это называется mushroom management

http://lurkmore.to/_/129883#mws_oe+J8eX

А вообще хорошо получается. Менеджеру и считать ничего не надо - есть бизнес-аналитик, менеджер продукта, прочие люди, которые должны этим заниматься. А ты кто? Ты просто человек, который заставляет маховик машины разработки крутиться. Размывается ответственность. У Дорофеева есть на эту тему объяснение, что когда между тобой и результатами твоей работы появляется значительное расстояние, тогда ты теряешь связи с землёй и начинаешь обустраивать свою "башню из слоновой кости", только менеджерскую. Панчи от факапов не прилетают, бояться нечего, зачем думать?

Ну и всё это приводит к тому, что в плохо работающем механизме появляются брузеры (с англ. "борец", термин как роль в игрока в онлайн игре). Вот они и начинают цепляться за цели и "тащить" проект, принимая на себя все удары со стороны кривых менеджеров, прокростинирующих разработчиков и пофигистичных заказчиков. При этом концентрируясь на результатах в критических точках, нередко принимая на себя чужие роли. Их ещё называют "драйверами". хотя у этого термина есть и другое описание.

интересный ресурс по архимейт:
https://wiki.vianovaarchitectura.nl/index.php/ArchiMate_Made_Practical

Действительно четко написано (сразу чувствуется северо-европейская культура). Однако настораживает упоминание ArchiMate 2.1, когда следующая после 2.1 версия 3.0 вышла в Июне 2016, потом ещё версия 3.0.1 в Августе 2017, потом новая версия 3.1 в Ноябре 2019-го.

ну... что поделаешь - как уже писал - в инете вообще сейчас все мало-мальски существенные примеры и разъяснения по 2-й версии... и это даже слегка запутывает бывает (особенно по цветам)

Хорошие примеры тут есть: https://online.visual-paradigm.com/diagrams/tutorials/archimate-tutorial/

и тут: https://www.hosiaisluoma.fi/blog/simplified-archimate-3-meta-model/
и тут: https://www.hosiaisluoma.fi/blog/useful-archimate-diagram-types/
и тут: https://www.hosiaisluoma.fi/blog/archimate-cookbook/

Я вот расшарил еще коллекцию (может там ещё что-то найдете):
https://yandex.ru/collections/user/amteterkin/ea/

Когда вы уже закончите рассматривать моделирование как рисование диаграмм) Курс по матмоделированию на архимейт, вот что было бы хорошо сейчас.

Моделирование - это 4д экзистенциализм. Диаграмки - это всего лишь один из вариантов просмотра части модели, понятный примерно всем. Архимейт - только архитекторам.

Хочешь не хочешь, придётся писать и то и то.