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

Забавный случай я ощутил недавно - если у тебя появляется много проектов, где твоя работа сводится к быстрому копанию конкретной проблемы и выносу вердикта с минимальными записями в документации, то начинаешь себя ощущать архитектором, который прыгает от проекта к проекту (от сервиса к сервису) и указывает направления их развития. Но как аналитик ты уже не можешь работать, так как на детали не хватает времени, особенно детали больших, размазанных по времени, проектов.

Пока думаю что с этим делать.

Хотя уже сейчас можно сказать, что надо меняться самому и переставать остро реагировать на такие вещи. Искать дзен, когда вокруг звездец, а ты остаёшься спокоен + допускать черновую работу (у которой качество аналитики в разы ниже, чем ты привык).

Прокомментирую с поляны архитекторов.
Режим работы в стиле “тушения пожаров” он явно ненормальный.
Чтобы работать со множеством проектов одновременно,
нужно повышать уровень абстракции, оставляя технические детали реализации другим.
Мозги и время не резиновые,
имея недостаток времени/оперативной памяти на то чтобы вникать в задачу, архитектор начинает творить глупости и нести вред вместо пользы.

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

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

И появляется между фазой разработки и тестирования фаза собачек:

не мешай людям стрелять себе в ногу,
пока ногу не отстрелят все равно не поймут.

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

Фаза с собачками - это когда n команд написали код без общей спеки интеграции как они её видят, и началась фаза интеграции (которой при правильном цикле разработки ПО внутри компании почти нет).

И ты начинаешь исправлять свою спеку интеграции по тому, как написали код команды.

Ты теряешь время, команды теряют время, клиенты орут что сроки проходят, ПМ рвёт волосы. Зато разработку запустили чуть раньше.

иными словами, ищи кому идет профит от бардака

Я их знаю. Просто не знаю, что с этим можно сделать ибо концепт подобной работы принят на всех уровнях. =)

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

Если это так, то 1) концепт подобной работы идет с верхнего уровня 2) на нижнем уровне фих что возможно исправить

Именна! =)

с такими кадрами надо вот так
https://habr.com/ru/post/471678/

Ну, вообще это нормальная работа аналитика. Просто на разных системных уровнях