Это, кстати, очень важная штука, о которой повсеместно забывают.
И тут речь не только о работе архитектора, но и о работе PM-а/TL-а, т.к. разработчик, который пишет код, в достаточно большом проекте единовременно может или охватить головой реализацию конкретной функции, или охватить её смысл в рамках проекта(а иногда в принципе этого не может, т.к. не обладает необходимыми познаниями в части технологического стэка). Точно также, как PM/TL/архитектор не может охватить реализацию конкретной функции.
В своей работе сейчас сталкиваюсь с этим.
В идеале, должно получаться разделение труда: Архитектор/PM/TL продумывает разделение решения на модули, каждый из которых решает конкретную задачу. На каждый из этих модулей составляется ТЗ/req.list, после чего разработчик уже не думает о том как этот модуль будет взаимодействовать с остальной системой — он думает о том, как наиболее эффективно и красиво реализовать функционал.
Это, конечно, не гарантирует, что решение будет легко поддерживать/разрабатывать и так далее, но, по крайней мере, снижает вероятность того самого страха из-за невозможности охватить мыслью всю структуру решения разом.
И тут речь не только о работе архитектора, но и о работе PM-а/TL-а, т.к. разработчик, который пишет код, в достаточно большом проекте единовременно может или охватить головой реализацию конкретной функции, или охватить её смысл в рамках проекта(а иногда в принципе этого не может, т.к. не обладает необходимыми познаниями в части технологического стэка). Точно также, как PM/TL/архитектор не может охватить реализацию конкретной функции.
В своей работе сейчас сталкиваюсь с этим.
В идеале, должно получаться разделение труда: Архитектор/PM/TL продумывает разделение решения на модули, каждый из которых решает конкретную задачу. На каждый из этих модулей составляется ТЗ/req.list, после чего разработчик уже не думает о том как этот модуль будет взаимодействовать с остальной системой — он думает о том, как наиболее эффективно и красиво реализовать функционал.
Это, конечно, не гарантирует, что решение будет легко поддерживать/разрабатывать и так далее, но, по крайней мере, снижает вероятность того самого страха из-за невозможности охватить мыслью всю структуру решения разом.