Вакансия на позицию “Архитектор”
Если заглянуть на сайты вакансий, то можно увидеть огромное количество позиций, именованных “Архитектор”. Каждая компания или подразделение может иметь в виду совсем не то, что коллеги из соседнего отдела. Объединяет же их то, что они видят архитектора как отдельную позицию, а не роль в команде. Это, на мой взгляд, критическая ошибка.
Архитектура ПО – довольно эфемерное понятие. Для меня оно включает дизайн системы, её отличительные особенности, позволяющие эффективно выразить модель предметной области, для которой ПО призвано решить проблемы. Самое явное отражение архитектуры можно найти только в коде системы. Архитектор, в таком случае, только одна из ролей разработчика, который выражает особенности программного решения в виде кода.
Для коллег, которые размещают вакантную позицию, “Архитектор” – нечто другое. В большинстве случаев я понимаю, что подразумевается кто-то ответственный за высокоуровневые технические решения и их документацию.
Сами решения могут относиться к чему угодно, но наиболее упоминаемые, за последние пару лет, включают вопросы масштабирования и проблемы со временем отклика системы.
Важное замечание. “Архитектор” для решения таких задач, по мнению нанимающей стороны, не работает с кодом продукта на каждодневной основе и явно выделен из структуры команды разработки. Иногда такие задачи возлагаются на одного человека в отделе/кластере/etc. Иногда под эти задачи придумывают выделить “комитет” на всю компанию.
Я не верю, что в современной продуктовой разработке есть место таким техническим специалистам по диаграммам. Иногда мне объясняют, что на самом деле нужен кто-то, кто решит проблему только спектра нефункциональных задач. Это вызывает у меня реакцию в виде смеха (а в душе слёз).
По каким-то причинам, специалистам из существующей команды отдавать такой особый класс задач не хотят. Но это же самые подходящие специалисты для решения нефункциональных задач!
Некоторые коллеги мне возражают в этот момент, объясняя, что это не бизнес-задачи, а только технические и команду не нужно отвлекать для их решения, ведь загрузка бизнес-задачами и так большая, да и вообще там нужны какие-то особые “технические” компетенции.
Уважаемые коллеги! Чисто технических задач (имеющих нулевое значение для бизнеса) не может быть в нормальной продуктовой разработке. Всё должно иметь смысл для бизнеса, иначе то, что Вы делаете – пустая трата денег.
Если вопрос оптимизации времени отклика или проблем масштабирования встал так остро, что Вы хотите нанять отдельного человека для их решения, у Вас точно есть реальная бизнес-задача. Под неё даже кто-то готов выделить бюджет на вакансию!
Тем более, будем реалистами, в конечном счёте имплементацией нарисованных “Архитектором” диаграмм всё равно будет заниматься команда продуктовой разработки. Т.е. Вы всё равно потратите их время. Просто отдайте эту задачу команде сразу. Ведь команда уже в курсе как работает система сейчас и сможет куда лучше понять где в коде есть проблемы для пресловутого масштабирования или бутылочные горлышки производительности.
Если Вы всё равно хотите выделить какого-то человека для этой задачи, выделите, сначала, только роль архитектора внутри команды. Если в команде появится заинтересованный человек, он сможет заместить её эффективнее человека “из вне”, поскольку будет больше знаком с бизнес-задачами и существующей системой.
Если Вы всё ещё думаете, что Вам нужен отдельный специалист, поищите сначала разработчика на позицию архитектора и включите его в команду разработки. Это позволит ему быть таким же разработчиком ПО и решит целый пласт проблем, связанных с “отрывом” от реального кода придумываемых “Архитектором” решений.
Иногда слышу, что сейчас нет специалистов с такими компетенциями в компании… А как же Вы существующей команде отдали продукт на разработку? Вы думаете, они не принимали никаких архитектурных решений? Архитектурные решения принимаются практически каждый день, вопрос только в масштабе дозволенного.
В заключении скажу только, что я никогда не видел вовлечённости “Архитекторов” в проекты, на которых я занимался разработкой. Они принимали решения по тому, что должен использовать проект или нет на основе своего прошлого опыта, каких-то понятных им лично идей и любых других мыслей из их “башен из слоновой кости”.
Другими словами, они работали с техническими проблемами без оглядки на реальные бизнес-задачи проекта. А проблемы, которые они видели, находились совсем в другой реальности, нежели то, что мы видели на уровне кода.
И чем больше времени проходит, тем чаще я вижу ситуации, когда продуктовые команды сами инициируют отказ от “Архитектора”, мотивируя это тем, что принятие критически важных решений растягивается на месяцы, когда проблема уже понятна и решение, на самом деле, уже придумано.
Самые опытные мои коллеги, которые эффективно решали архитектурные задачи, включая времени отклика или масштабирования, были простыми разработчиками, также работавшими с продуктом, как и я сам. И работали они с этим продуктом не в прошлом, а прямо сейчас. Но работали не с техническими, а бизнес-проблемами.