Семь бед — один ответ: как мы решали проблему постоянных исправлений

[VolCh]

Была подобная практика на одном проекте. Правда обычно без обсуждения с командой и командного ревью: архитектор ревьвил то, что вы называете техническим решением. Мне не понравилось — он требовал более детальных описаний, которые я предоставлял только уже решив задачу почти полностью и скопипастив код. Причём подходы у нас были разные и часто мне приходилось переделывать.

[Gastarbayter]

На сколько я понял смысл в том, что бы не переделывать ;-)
Сначала рисуется диаграмма последовательностей, потом алгоритм взаимодействия, потом входные/выходные параметры на каждом этапе и потом все это согласовывается. После апрува можно переходить к разработке. И не переделывать потом решение так, как кто-то из принимающих не так объяснил, а кто то из реализующих не так реализовал.
По итогу получится хорошая документация. В которую можно посылать будет направлять, что бы меньше задавали вопросов ;-)

[VolCh]

Вот это всё рисование (у нас больше было текстовое описание) занимало у меня больше времени чем сделать MVP, а потом переделать… В разы больше времени — нифига я не художник мышкой. Под конец уже троллил откровенно: рисовал ручкой на бумажке, сканировал/фоткал и прикреплял к задаче