(немного передам контекст) у нас на проекте три арха. Они разделяются по областям абстракции, высокий уровень (близко к solution), средний, компонентный (близко к application) и технологически сложные моменты нижнего уровня (в большей степени system). Все читали вопрос и ответы, так как мы все тут у меня. Это как раз так из-за того, о чем писал @emacsway  - спасибо за формализацию.

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

Шесть месяцев работы, при этом вы заранее _не_ договорились о сроках, когда будет готов результат, о виде результата,а также о результатах промежуточных?
Не надо так. Это же не дружеский междусобойчик.
Если человеку "надо обдумать", то с ним надо договориться, сколько он будет думать и что по итогу думанья выдаст - например, оценку трудозатрат на полноценную свою работу и список необходимых для этого вещей (людей, условий и тд).
Любая, абсолютно любая задача, любое r&d, НИР, все даже самое "исследовательское" можно оценить, всюду можно вычленить хотя бы первый измеримый шаг (призванный улучшить измеримость дальнейшей работы)

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

Как следствие, я в вопросе пытался уйти от этой проблемы (так как цель была другая), смещая акцент на то, что "роль какая то не такая".

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

Так что да, все так. Я понял, что такое невозможно. Но с другой стороны, все же интересные мысли удалось получить.

Дарья, мое субъективное мнение, что арх - созидатель систем. Каких систем, частность его профессионального опыта.

Вот смотрите, допустим, я провожу собес с архом, который не может удостовериться в приемлемости моих условий (работодателя). Вопрос - это арх?

Если он не может оценить систему, выявить ключевые процессы и мысленно встроить себя в нее. Как он будет ее модифицировать?

Можно сказать - архитектор это опыт использования стека. Но... это не совсем так. Опыт он получал во взаимодействии с людьми. Результат его работы нужен людям. И именно они оценивают его успешность. Т.е. без людей его работа ничтожна.

Т.е. какой бы стек арх не покрывал, он должен понимать, что его деятельность не ограничена результатом в виде проектируемой системы. Он еще и часть других систем. И он обязан уметь с ними работать тоже.

Так вот... можно ли оценить работу архитектора по исполнению инструкций? Про это ли архитектор? Или в его негласной власти модифицировать систему и низложить действующие инструкции? Как это измерить?

Исполнение инструкций - это часть производственного процесса. Сам ли он их придумает, встроится ли в новые - вопрос второй. Архитектор - это прежде всего роль по отношению к разрабатываемой (создаваемой, модифицируемой) системе.
А систему организации, которая разрабатывает, могут проектировать и изменять совсем другие люди. И он тоже может, но уже в другой роли.
Он может рекомендовать и/или проводить изменения в оргструктуре, если это нужно для улучшения процесса разработки.
А если это хаотичный творец, плюющий на правила, "низлагающий" инструкции без согласования - то это не архитектор. Это яжхудожник, который "так видит". Недоговороспособный, непредсказуемый, с непонятным профитом в итоге.

Если все же по поднятой теме выше,
интересно, а чтобы вы предприняли по отношению к художнику?

Например, у меня есть UXUI дизы. Они коты еще те! ))) И я их за это люблю.
Но случись такое с архом, это все считают проблемой, или нет?

Хм... сложно емко сформулировать мысль, которая изменит ваш взгляд. Попробую так:

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

Обратите внимание, что для этого нужно:
1. Поставить цель
2. Изучить условия
3. Определить проблему (разрыв)
4. Определить путь
5. Пройти путь
6. Получить результат и верефицировать с ожиданиями.

Т.е. это системное мышление во всем.

Если я этого не сделаю, я не получу результата, а следовательно, я плохой архитектор.

И то, что я что-то там рекомендовал и это не сделали... скорее неспособность брать на себя ответственность. Или неадекватные предложения.

P.S. Инструкции, это закрепленная методология выполения функции. Если мы вводим новую фичу, несомненно инструкции преобразуются.

To @momentics:
Договариваться о вменяемых сроках и результатах, в том числе - обязательно - промежуточных. Желательно - сделать так, чтобы можно было заглядывать, движется ли дело (появляется ли в репе код, а в вики - страницы, общается ли с аналитиками и разрабами, другими архами).
Если он выполняет, пусть и со сдвигами - еще куда ни шло, мб и можно работать, просто оценки "внешние" увеличивать. Если от самой идеи отказывается, результаты промежуточные прячет, и согласен только по итогу показать - нафиг с пляжа.
Был у меня такой коллега, под соусом "этожиисследование" уходил на 2-3 мес с концами, при попытке провентилировать работу - обижался и уходил в игнор. Потом его модули скрытно выпиливали, чтоб не обижался (и я не шучу).
Человек, с которым нельзя обсудить и соблюсти (хотя бы попытаться) сроки и результаты, к коммерческой разработке малопригоден.
Пусть сидит в нии и проектирует к нему лексическую редупликацию с эротическим уклоном.
Поэтому я считаю это проблемой, да.

To @RPiontik : вы путаете процесс проектирования и проектирование процессов.
Можно спроектировать 10 фич в рамках одного процесса. Сама фича не повод для изменения. Повод - недостижение в процессе нужных критериев (сроки, качество, и тд).

Ну я попытался:))

Нет, я не путаю. Проектирование это такой же процесс подверженный таким же изменениям. И в него так же встраиваются фичи.

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

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

Можете сказать, что это не так?

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

Коллеги, прям интересная беседа получилась.

@dkaftan
"этожиисследование"
У меня за несколько десятков лет такая предпосылка была. Правда я в то время перевел прям на ежедневное таск-планирование (фу ужас! я такое не люблю очень. Прям как в тюрьме). Но это помогло, хотя в сторону расставания, но было это лет эдак 15 назад и не в Москве.

Но мне больше нравится мысль @RPiontik. Она какая-то более глобальная, что ли. Более романтик :)
Хотя, конечно, процесс проектирования и проектирование процесса, согласен, разные вещи. Но мне кажется, что Роман тут прав, если рассматривать компанию одного продукта. Там это одно и тоже. По сути солюшен полностью включает и методы его создания.

Например об этом очень много говорил Александр Лучков. Прям все разложил с конца географии

Чушь и ещё раз чушь. Сначала надо провалидировать реальную необходимость того что надо сделать, потом поднять вопрос о противоречии (основы разрешения конфликта), определить какая из предпосылок не верна и если инструкции имеют некорректные или не актуальные предпосылки то рассмотреть вариант как в целом изменить систему

Я ни в коем случае не спорю, что архитектор может и при случае должен изменять процессы. Но только этим занимаются все лиды. И менеджеры. И я бы не слепляла это с ролью архитектора, вот в чем мой посыл. И уж тем более не наделяла этим исключительно архитектора.
И вместо романтизма внесла бы рациональность (т.е. обусловленность изменений целями).

Я не знаю в чем вы увидели противоречия с моим утверждением (1..6), но... я с вами во всем согласен.

Итог один - если нужно менять, то нужно менять. Брать на себя ответственность и менять.

@inoise я также сделал акцент на системности. Видимо недостаточно ясно.

@dkaftan почему не слепляли бы? Чем архитектор не человек, способный предложить адекватные, рациональные изменения?

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

+
у нас например в коллективе изменение процесса могут делать только лиды. Предложить может кто угодно - своему лиду.
Изменение доводится, планируется и далее внедряется. Либо намечается.

Но это возможно потому, что у нас не один арх, а три. И они больше не про идеологии, а про тех решения различного уровня.
Но в целом, я не исключаю коллективы, в которых все определяет арх. Тогда он прямо творец!

Хм... а как можно выпустить систему с SLA 99.9999 без внедрения в архитектуру решения процессов DRP? Или, модификацию процессов разработки, например с переходом к TDD? Это чья забота?

Я, подчеркиваю, что это мое субъектвное мнение, но система реализующая продукт, это аппаратно-программный комплекс, обеспеченный необходимыми процессами сопровождения и развития. Т.е. все это система. И все это про архитектора.

НО! Я и в голове не держу, что он всем этим хороводит. Он это учитывает и предлагает адекватные решения для достижения поставленных целей. При необходимости прилагает достаточные усилия для проведения своего взгляда в жизнь. И несет за эти решения ответсвенность.

С нашим продуктом так получилось, что на момент проектирования Системы Как Субстанции, было проведено исследование, высокоуровневое проектирование, выверены цели и задачи, включая план маркетинговых предприятий, без команды.
В частности, например, доступность на высоком уровне заложена на базе типовых решений, а такие вещи как DRP (очень редко такое приходится слышать, но лично от вас, видимо ожидаемо) - вообще в модели MDD. Сами процессы строились с направлением MDD, включая TDD и ALM на верху. Это все сделал наш лидер стартапа. Для этого конечно он привлекал разных специалистов и многое делал сам.

Так что да, если делать (правильнее сказать - начинать) всё когда команда есть, возможно ваш вариант и был бы основным и выбранным. Я прекрасно понимаю о чем вы.
Но коллеги смотрят больше с позиции устаканившихся процессов. Лично я тоже с ними (процессы вносят предсказуемость), но и с вами, потому что у нас в коллективе это могло бы быть и так, как вы изложили.

Почему у нас не так.
Все дело в том, что представьте ситуацию, когда все роли приглашаются с рынка. Представьте, когда роли появляются не в порядке направления проектирования, а в хаотичном порядке нормального закона.  Это как движущееся произвольно система координат, в которой прицеливание невозможно в общем случае. В таких условиях необходимо модУлирование в течении некоторого времени, чтобы все кольца поршней встали на свои места. Мы например находимся в этой фазе.

Например, многие спрашивают зачем нам архитектора (напомню, https://t.me/itarchitect_jobs/19360).
Ну во-первых, необходимы контролируемые решения, с ответственностью.
Во-вторых, необходима наработка экспертизы, что в перспективе сделает возможным ее передачу.
Так как слишком сложно технологически, то система все была разбита на три слоя. И то еще без включения ALM цикла. Это только само тех решение.

Георг, а вам не кажется, что то, что вы описали - корп. архитектура?:))

Просто, как ранее я писал, эта функция не обязательно выделяется. И видимо, вы ее выполняете.

Но разве ваши архитекторы не понимают ее устройство? Не учитывают? Не предлагают решения? Может эта функция распределена шире? И в них, и в лидах, и в вас?

Я правда, забыл о чем мы дискутируем :) Скорее это уже просто любопытство. Для меня сейчас остро стоит вопрос - а существует ли коллективная архитектура? И если да, то какие процессы ее развития ключевые?

Вот по полочкам разложить у меня хорошо получается :)

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

Далее, собрались несколько человек и начали обсуждать обязанности роли (функции) архитектор. Завязалась интересная полемика о границах роли. И тут конечно я, увлекшись и впитывая ваш опыт (всех кто высказывался в смысле), уже перелил на наш коллектив.

\\
Корп. архитектура... Боюсь я не знаю что это такое. Возможно этот термин может иметь слишком много значений.

Коллективная архитектруа...  предположим, мы возьмем за аксиому цитату из рекламы, где три перца из ларца по очереди говорят "Что-Новая хозяйка-Надо"? Получается основной процесс в коллективной архитектуре, если мы берем за основу все же, ИТ продуктовую сферу, именно пайплайн.

Т.е. основной процесс - это обеспечение потокаименно пайплайн.

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

На выбор модели жизненного цикла разработки влияет несколько ключевых факторов:

1. Стоимость обработки неопределенности в процессе проектирования.
2. Стоимость адаптации системного инкремента (по-сути, достижение Modifiability и производных от него атрибутов качества).
3. Способы устранения зависимостей декомпозируемых задач, иными словами, достижение автономности команд (решение проблемы Брукса), снижение коммуникативной и когнитивной нагрузки (по-сути, построение карты ограниченных контекстов и маппинг их на топологию команд).

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

С другой стороны, вот если мы прямо сейчас спросим у каждого архитектора хотя бы что такое "процесс жизненного цикла", то будет хорошо, если ответят хотя бы единицы. Для грамотного построения процессов нужно знать руководства PMI и INCOSE, PMBoK, SEBoK, стандарты жизненного цикла 12207 и 15288, знать модели разработки (DAD, SAFe, FDD, MSF, RAD, RUP, Spotify, Scrum of Scrums, LESS, Nexus, Crystal Clear, etc.), знать управленческую литературу (Мифический Человеко-месяц, Топология Команд и т.п.). А чтобы внедрить изменения и не вызвать сопротивления - знать еще и социальную психологию. Иначе попытки изменить процессы закончаться рассказами про "донкихотство".

Конечно, архитекторы с таким набором скиллов бывают, но это, скорее, исключение из правил.

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