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

Э, так дизайн-ревью остается или в Jira или еще где-то. С обсуждением и описанием причин. И связями с кодом через коммиты.

Ну я же говорю - тяжелые проблемы. В том числе и в поиске виноватого, а не в решении проблемы отсутствия ошибок.

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

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

я не поняль

Не, у меня же не альфа спецназа совсем, в среднем крепкие миддлы.
Альфа спецназа вчера на Боль тимлида приходила, вот это был реально мрак )

Поиск виноватого не имеет конструктивного смысла.

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

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

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

Да, вы правы.

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

Поиск узких мест процессов или некорректных процессов важнее поиска виноватых

О, да... Яплакаль\

А вот последнее - это как раз про Design Review и ссылки на него при коммите.
Т.е. смотришь правки строчки со структурой БД или класса, смотришь коммиты, по ним находишь ревью, где все написано

Еще и со всей историей

Я сейчас вижу кейс когда опытные разработчики, успешно решающие задачи общего плана, вязнут в специфике предметной области. Структура классов или БД это одно, а непонимание порядка учёта валютных платежей это уже другое.

Разработчики не должны вникать в этот порядок, на это должен быть аналитик

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