АКТ 4 Кем архитектор НЕ является

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

Архитекторы – это высококвалифицированные специалисты, знающие много различных аспектов и умеют работать в сложных ситуациях. Вследствие чего архитекторов часто используют как пожарных.
Она закрывают все горящие проблемы: здесь разработка не справляется, тут бизнес-анализ недоработал, здесь вообще и проектом поуправлять нужно, а тут бюджет не сверстан... поможешь?
В результате происходит то, что происходит с тем самым пожаром - человек выгорает, устает от переключения задач, устает бегать за всеми и решать те проблемы, которые есть в проекте. В итоге архитектор в зависимости от свойств личности или уходит в другое место, или переходит в режим итальянской забастовки.

Архитекторы вырастают из бизнес-анализа или разработки, отсюда и второй - наиболее частный случай - использовать архитектора, имеющего опыт разработки, в качестве тимлида разработки.
Вместо того, чтобы заняться кадровыми перестановками в команде разработки, которая не справляется со своими задачами, это перекладывается на архитектора.
Архитектор начинает делать ревью кода, учавствует в планировании спринта, разбирает спецификации API и так далее. И таким образом глубоко залипает в каком-то проекте и его проблемах, вместо того, чтобы заниматься глобальным видением архитектуры в целом.
В итоге проблемы не решаются, а наоборот множатся, бюджет проекта начинает трещать по швам из-за высокой стоимости использования архитектора. В итоге, недовольны остаются все: архитектор, команда разработки, заказчики.

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

Если предыдущие два случая хоть и кажутся странными, но вполне допустимыми, то использование архитектора в качестве руководителя проекта кажется совсем фантастикой.
Однако, такое происходит достаточно часто, особенно в ИТ, где РП пришёл не из сферы ИТ или хотя бы любой инженерной сферы. Такой РП, чувствуя свою некомпетентность, начинает использовать архитектора как своего заместителя, а потом и вовсе скатывается в администратора проекта, который ставит встречи и собирает статус выполнения задач.
Мне лично приходилось писать положение о проектном управлении, докладывать статус проекта заказчику и проверять выполнение задач разработки. А моим коллегам и того больше, приходилось формировать бюджет, готовить отчётную документацию по проекту и даже защищать проектную калькуляцию перед спонсором.
Конечно, ситуации бывают разные, и порой команде нужно помочь с разными задачами, и почти любой адекватный архитектор, которого я знаю (впрочем как и я сам), помогает команде с закрытием разовых активностей, с которыми не справилась система.
Главные правила тут не превращать это в системное закрытие дыр, чётко обозначать, что помощь эта временная и системно заниматься устранением корневых причин.