(В оригинале Architects must be hands on)

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

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

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

Архитектор должен быть добавлен в команду в самом начале проекта. Он не должен сидеть на академических высотах, диктуя направления, а вместо этого должен приземленно работать вместе с командой. Вопросы вроде «В каком направлении двигаться» или «Какую технологию выбрать» не должны выливаться в новые исследования или проекты, вместо этого ответы должны выбираться исходя из практического опыта или при помощи совета от других архитекторов-коллег (ведь у хорошего архитектора всегда будут связи с другими хорошими архитекторами!).

Хороший архитектор должен быть экспертом в использовании хотя бы одного инструмента, например, IDE. Логично ожидать, что проектировщик ПО должен знать IDE, проектировщик баз данных – средства моделирования баз данных, а информационный проектировщик – инструменты XML. Однако технический архитектор должен знать хотя бы минимально все инструменты от мониторинга сети (Wireshark) до моделирования сложных финансовых сообщений (XMLSpy) – ни один уровень тут не будет ни слишком высоким, ни слишком низким.

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

Автор оригинала - John Davies