Технический архитектор (ТА) — одна из ключевых фигур в разработке и реализации сложных ИТ-систем. Мы в КОРУСе подразумеваем, что это профессионал с глубокими техническими знаниями и развитыми soft-скилами, способный работать автономно и в то же время брать ответственность за общий результат команды. Также для него важны прокаченные коммуникативные навыки, умение делегировать задачи и работать в сжатые сроки.
В этой статье мы решили посмотреть на профессию через призму необычных вопросов, которые задали Николаю Кузьмину — техническому архитектору из департамента CRM и BPM из КОРУСа.
О профессии
Николай, как ты присоединился к команде КОРУСа и какой карьерный трек уже прошел в компании?
Это случилось 3 с небольшим года назад. Я собеседовался на один проект на позицию DevOps инженера в качестве подрядчика. Меня порекомендовала текущая коллега, с которой мы вместе работали на прошлой работе. На собеседовании со стороны КОРУСа был архитектор, который вместо вопросов по DevOps предложил мне поговорить про разработку. «Ого, ничего себе, внезапно!», — подумал я. В итоге собеседование я прошел успешно, но DevOps на проекте не потребовался. Но вот сам факт того, что собеседование оказалось успешным, подтолкнул меня к мысли, что можно сменить работу.
Так я оказался в компании на позиции ведущего разработчика и за 2 года смог вырасти до технического архитектора. В этом мне помог востребованный инструмент КОРУСа — беседы о развитии (БОР). В рамках процедуры нужно было порефлексировать о своей работе и заполнить специальную форму на корпоративном портале, состоящую из трех вопросов. Я достаточно ответственно и серьезно подошел к процессу: несколько дней думал, вспоминал, что я делал, что из этого получилось, а что нет. В итоге я написал очень большой и подробный документ, после анализа которого и непосредственно беседы мне предложили новую должность.
Необычно о профессии
Как бы ты объяснил бабушке, чем занимаешься сейчас на работе?
Моя бабушка раньше работала конструктором на заводе, поэтому мне «повезло», и я могу оперировать какими-то техническими терминами. В целом, я просто говорю, что у меня много проектов, большая команда, и то, что я отвечаю за техническую коммуникацию между организациями и подразделениями в них. В этот момент она кивает, делает паузу, а потом спрашивает «Работы достаточно?». И успокаивается только когда я подтверждаю, что работы у меня хватает, и все хорошо. Тем не менее, раньше, когда я работал с аппаратурой, объяснять было проще .
Есть ли что-то общее между техническим архитектором и обычным архитектором?
Вопрос из серии «Не в бровь, а в глаз», потому что у меня есть возможность сравнить вживую . Мой брат — архитектор по образованию и работает в строительстве. Сходство, конечно, есть. Это множество различных схем, добрая порция дотошности, развитая фантазия. И обязательно готовность к тому, что изначальный замысел будет отличаться от того, что получится в реальности. А еще щепотка недоверия и подозрительности по отношению к людям.
Нужно ли техническому архитектуру писать код?
Однозначно да, потому что новые знания, идеи и технологии должны пройти через твои руки. Ты должен сам «набить шишки»: столкнуться с проблемами и решить их самостоятельно. Если этого не делаешь, потом начинаешь не понимать разработчиков, аналитиков, лидов и т.д., потому что их затруднения тебе непонятны.
Можно ли скачивать готовые архитектуры из интернета или попросить их сделать ИИ?
Архитектура — это не какой-то документ, ее нельзя скачать, принести коллегам или заказчику на флешке. Поэтому ответ — нет. Но можно изучать архитектурные подходы, паттерны проектирования, знакомиться с историями успеха в крупных компаниях. Этот опыт даст тебе возможность применять полученные знания на практике уже на конкретных своих проектах. Но надо помнить, что все проекты уникальны, и даже если мы видим какие-то знакомые блоки, из которых собрана архитектура, они все равно доработаны под конкретные задачи.
Кто главнее — технический архитектор или руководитель проекта?
Не совсем корректное сравнение, так как обе роли имеют разный набор задач. Но при этом обе роли сильно влияют на проект. Наверное, архитекторы чаще выдают какие-то ограничения, под которые приходится подстраиваться всей команде, в том числе и руководителям проекта. И тут речь не про то, что архитектор — главный (как сказал, так и делаем), а про то, что технологии иногда менее гибкие и адаптивные, чем люди.
Если бы твоя архитектура была зданием, как бы оно выглядело?
Я все свои проекты представляю как заводы с цехами и станками, где протянуты конвейеры и прочие технические коммуникации. На этих же заводах есть большие пустующие корпуса, в которых когда-то планировалось что-то делать, но руки не дошли или не хватило ресурсов. Некоторые помещения выглядят старыми, как будто они уже стоят по 40 лет, но при этом активно используются. В некоторых помещениях сделан «ремонт под ключ», но, если приглядеться, под новыми обоями иногда можно увидеть следы недавно потушенных пожаров.
Как ты оцениваешь «красоту» своих архитектурных решений?
Для меня решение красивое, когда его можно мысленно разобрать на составные части, оценить простоту этих деталей, а потом собрать обратно. При этом оно должно выглядеть точно так же, как и до разбора. Повторить это 20 раз, и если все получается, то можно уже идти к команде. На стадии взаимодействия с командой решение является красивым, если тебя понимают практически с первых слов.
Разделяешь ли ты принцип «Работает — не трогай»?
Это мой любимый принцип, и я его разделяю. Но чаще всего именно я как архитектор говорю: «сейчас мы возьмем это все и будем изменять, переделывать, чтобы оно работало лучше, быстрее и оптимальнее». Именно технический архитектор часто так говорит, хотя очень любит ничего не трогать.
Есть ли в ИТ архитектурные стили и в каком работаешь ты?
Архитектурные стили в ИТ существуют, но нет возможности придерживаться какого-то конкретного, так как все проекты уникальны. Есть универсальный принцип, который я для себя вывел. Он состоит из трех слов: «Отсекай, разделяй и властвуй». И, как правило, его достаточно, чтобы решить большую часть задач.
Какую самую странную или нестандартную задачу тебе приходилось решать?
Сложно сказать, так как все задачи — нестандартные. Как правило, ты отсекаешь лишнее, разделяешь оставшееся на более понятные задачи, и уже с ними работаешь. В этом и удовольствие: взять что-то непонятное и распутать этот клубок.
Вместо заключения
Что тебе нравится, а что раздражает в профессии?
Нравится, что есть много возможностей влиять на систему и проект. И вариантов решения одной и той же задачи больше, чем, например, у разработчика. Проблему можно решить не только кодом, а подумать уже на уровне нескольких систем или вообще на уровне людей договориться. Еще нравится, что в целом все задачи — нетривиальные.
Касательно того, что не нравится. У меня есть даже личный триггер: ситуации, когда слово «архитектура» используется для обоснования проблемы, просто потому что оно сложно звучит. Пример: «У проекта сложная архитектура, поэтому надо долго разбираться…» или «Это проблема на уровне архитектуры…». А по сути просто не знают, как это назвать, в чем причина проблемы, поэтому для упрощения ссылаются на архитектуру.
Какой карьерный рост у технического архитектора?
В моем департаменте есть коллега, который говорит, что архитекторы находятся на вершине пищевой цепочки. Это дословная цитата. И отчасти это может быть правдой.
Понятие «архитектор» в ИТ очень широкое. Архитекторы бывают разные, и распределяются они вертикально и горизонтально в зависимости от масштаба задач. Например, есть архитекторы на уровне кода, есть архитекторы, которые работают на уровне систем, а есть бизнес-архитекторы, которые работают со стратегиями организаций. Поэтому твой путь может развиваться по-разному: можешь перейти в менеджмент или «наращивать плечи» в технической части или вообще углубиться в конкретную специфическую область.
Какой совет дашь начинающим техническим архитекторам?
Когда я перешел в должность технического архитектора, мои ошибки (без которых никто не обходится) стали более явными и заметными, чем на уровне разработчика.
Совет такой: надо признавать свои ошибки, уметь с ними работать, и это будет главным двигателем твоего прогресса.
А второй совет: записывать все, что ты делаешь. Есть даже специальный инструмент — реестр архитектурных решений, куда вносятся все решения, связанные с системой и проектом. Когда ты вернешься к задаче через длительное время (потому что все системы разрабатываются в долгую), эти записи помогут восстановить ход твоих мыслей и решения на уровне команды, что сэкономит сотни часов.
