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