В роли "Архитектор"

Прочтя соответствующую главу в СМ 2020, я узнал об этой роли, судя по всему это наиболее близкая к предпринимателю. Сначала, как я понял о чем «архитектура»: только о самом главном, про подсистемы и их отношение между собой.

Узнав о роли, посмотрел как я в ней действую, оказывается, что после описания самого важного почти всегда не останавливаюсь и иду на уровни ниже к частям главного или даже к частям частей. Какой-то видимой и осознаваемой отсечки: тут мне ещё важно а тут уже нет у меня не было. Почему же так происходит: 1. Иногда интуитивно чувствуется, что в этом направлении не хватает навыков и стоит углубиться и поработать. 2. Сильное чувство сопротивления, через которое перешагиваешь и идёшь в детали, при этом крайне медленно и неэффективно.

Воспользовавшись понятием «архитектурное решение» можно избежать отхода от важного. Важно что критерий субъективный, а значит учитывает и интуитивное понимание. Что же такое архитектурное решение? Такое решение, изменение которого повлечёт за собой существенное изменение (переделку) значительной части системы. Таким образом, при делении системы на более мелкие части спускаясь по уровням вниз, необходимо в явной форме задавать себе вопрос: потребуется ли мне принимать какие-либо архитектурные решения касаемо рассматриваемой части системы? Ответ может и не появиться, но будет ощущение, что вот этот уровень уже мне не интересен и тут моих важных решений нет, а значит можно остановится. А если моих решений тут уже нет, значит от процесса деятельности удовольствия будет меньше и значит, что есть более подходящая роль (и актёр) для этого.

Представляется, что подобный подход применим при постановке (в смысле нарезания границ) задач другим исполнителям, а если постепенно начать давать задачи на уровне +1 , т.е. где еще есть мои важные решения, то такой исполнитель будет быстрее развиваться. Принцип «заниматься только архитектурными решениями» можно использовать при сложностях с делегированием.

“Архитектор” в том виде, в котором вы его описываете, скорее инженерная роль)) тк обычно под архитектурой понимается часть описания системы (альфа “описание системы”, инженерная область интересов). Это если в самом общем виде)

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