«Меня собеседовали 6 директоров и вице-президент». Архитектор 4-го уровня EPAM про то, как разработчику вырасти до архитектора решений (+список книг)

Позиция Solution Architect до сих пор не слишком распространена в белорусских ИT-компаниях. dev.by пообщался с Дмитрием Гурским, архитектором решений EPAM, чтобы узнать, чем занимаются архитекторы в белорусском ИT-гиганте. 

«Долгое время не было до конца понятно, чем архитектор отличается от разработчика»

Я начинал с позиции разработчика. В своё время писал на C++, потом на Java, на C#. Прошёл, наверное, все основные ступеньки: был и тимлидом, и проектным менеджером. В паре небольших компаний в Минске занимал должность регионального CTO.

В EPAM попал странным и интересным образом. Меня собеседовали шесть разных директоров и решали, на какую позицию я подхожу. Седьмым был вице-президент, который после полуторачасового интервью сказал, что я архитектор 1-го уровня, и меня надо взять. Я тогда не понимал, что такое «1-го уровня», но все говорили, что ты архитектор, и это круто. Тогда позиция архитектора только начинала появляться.

Это был 2011 год. До десятых годов роль архитектора выполнялась командами коллегиально или тимлидом. Но чаще — группой разработчиков. Как отдельная должность она появилась лет 8-9 назад. Долгое время не было до конца понятно, чем архитектор отличается от разработчика. У нас в компании матрица с детальным описанием компетенций и навыков выкристаллизовались где-то к 2014 году.

Что такое архитектура решений на примере аэропорта «Берлин-Бранденбург»

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

Приведу пример. Существует история с аэропортом «Берлин-Бранденбург». Его должны были сдать в эксплуатацию в 2011 году, потом в 2017, теперь уже собираются сдавать в 20-м. Стоимость возросла с 2 миллиардов евро до 6 с половиной. В этой истории много всего: и коррупция, и неэффективные процессы «разработки». Но, как писали в Deutsche Welle, одна из основных причин неудачи проекта — ошибки архитекторов при проектировании системы вытяжной вентиляции, что могло бы повлечь за собой большие жертвы в случае пожара в терминалах. То есть архитектурно система была сделана так, что повлекла за собой переделку огромного количества вещей. Так же и в ИT.

Решение — это что? Например, есть организация, в которой мы хотим открыть новую ветку бизнеса. В этой организации люди выполняют определённые роли, определённые рабочие процессы: бухгалтер, продавец и т. д. В современном бизнесе любые процессы нуждаются в программном обеспечении. Решение — это тот набор ПО, который помогает организации решать конкретную бизнес-задачу. Архитектор, может предложить заказчику готовый продукт «из коробки», а возможно, будет делать всё с нуля. Например, для небольшого бизнеса по продаже цветов Ехсel может решить все проблемы. Но это другая история. У нас сейчас есть интересный проект для крупной автомобильной компании. Он связан с «интернетом машин». Очень интересная тема, где с нуля делается все кроме облачных сервисов. В обоих случаях решаются задачи для каждого конкретного бизнеса.

С какими заказчиками приходится общаться архитектору?

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

О 5 уровнях компетенций в EPAM и том, какими навыками должен обладать архитектор

Вторая моя роль в компании — это развитие дисциплины «Solution Architecture» в EPAM глобально. Пять лет назад наша команда начинала с того, что понятно описывала, кто такие архитекторы. Сейчас у нас несколько сотен людей, занимающих эту позицию. В компании есть 5 уровней для каждой компетенции: для архитекторов, разработчиков, аналитиков и т. д. 1-й уровень — стартовый. Критерии прописаны для каждого: чего ожидают от сотрудников в этой роли? В итоге была разработана целая платформа для профессионального роста. То есть ты можешь быть разработчиком 4-го уровня и претендовать на позицию архитектора 1-го уровня. Тебе выдаётся рекомендация, какие книги читать, какие тренинги пройти и навыки подтянуть.

Какой уровень занимаете вы в этой системе?

4-й.

Сколько в EPAM архитекторов 5-го уровня?

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

Какие навыки важны для архитектора стартовых уровней?

Во-первых, широта технического опыта и знаний. Чем шире ты, будучи разработчиком, «трогал» технологии, тем лучше. От архитектора 1-го уровня мы ожидаем, что у него будет пару технологических стеков: например, опыт работы на C#, опыт работы c front-end. На 2-м уровне специалист будет знать Microsoft Azure — первый облачный стек. На третьем — Amazon WS. Уже два облачных стека. Потом, возможно, Е-commerce. У архитектора в этом плане та же ситуация, как и у разработчика. По мере накопления опыта, разработчику в какой-то момент становится всё равно, на каком языке писать, с каким стеком работать. Есть предпочтения, конечно, но всё же. Так же и у архитектора — в какой-то момент тебе уже не так важно, в каком стеке делать дизайн. Потому что общие принципы схожи. Ты изучаешь основное в новом стеке и с помощью разработчика, который в нём специализируется, можешь построить архитектуру. Поэтому широта технического опыта — это очень важно.

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

И в нашем понимании, архитектор должен свободно перемещаться между всеми этими уровнями вверх-вниз. Поработав с enterprise-архитектором, построить архитектуру решения, потом поработать с кодом, контролируя, что реализация идет туда, куда надо, потом опять что-то построить на уровне архитектуры, и т. д. Можно использовать следующую метафору. Когда ты работаешь с кодом — ты работаешь на поверхности планеты и видишь код в рамках тех приложений, в разработку которых ты вовлечён. Поднявшись на вертолёте над поверхностью, ты видишь не только 2-3 приложения, ты видишь все решение целиком — это архитектура решения. Если сесть в ракету и подняться ещё выше, то увидишь много квадратиков, из которых состоит ландшафт приложений всей организации, и одно решение — лишь один из квадратиков. Это — уровень enterprise-архитектуры.

Вот пример из моего опыта. Я консультировал ведущего архитектора на стороне заказчика. Это была одна из американских финансовых компаний. Они хотели сделать платформу, которая должна была стать основой для существующих продуктов этой компании: все новые продукты строились бы на ней, а все текущие должны были бы на нее мигрировать. Технически и концептуально это было очень интересно. Каждый день в течение месяца мы созванивались с архитектором по скайпу. По два часа спорили, договаривались. По сути, мы обсуждали и enterprise-архитектуру, и то, как её будет поддерживать архитектура этой самой платформы. Т.е. нам надо было в обсуждении постоянно переходить между этими двумя уровнями и согласовывать их.

Третий пункт — это навыки коммуникации. Архитектор общается с командой на стэндапах, рисует диаграммы, пишет solution architecture document с описанием решения. Он должен делать то же самое и на стороне заказчика, общаться не только с техническим специалистами (например, в рамках pre sales — активности при подготовке контракта). Начиная с уровня 4+, мы ожидаем, что наши коллеги будут играть роль CTO в компании заказчика, и у нас есть такие кейсы. Здесь уже важно, насколько эффективна твоя неформальная коммуникация с людьми, потому что CTO — это очень чувствительная позиция в любой компании. Если на эту позицию берётся человек со стороны партнёра, то ему важно выстроить доверительные отношения с владельцами бизнеса и топ-менеджерами на стороне заказчика, учитывать массу нюансов, которые существуют в этом бизнесе и т. д.

Очень важны лидерские качества. Например, я уже третий месяц выступаю в роли архитектора на одном проекте. Процентов 70 от всех активностей — это то, что я предлагаю заказчику, а не он просит сделать. Я вижу, что некоторые решения неэффективны, и предлагаю архитектору на стороне партнёра сделать какие-то вещи иначе. Здесь тоже очень важны навыки коммуникации: как донести свои идеи до коллеги так, чтобы он воспринял это конструктивно, не обиделся. Например, мы переделали подход к созданию диаграмм, перешли на подход, связанный с различными взглядами (views and view points) на архитектуру. Пересмотрели подход к enterprise-архитектуре, её развитию и документированию. То есть действия архитектора напрямую влияют на бизнес заказчика.

О свободе в выборе проектов

Одновременно архитектор может работать над разными проектами или достаточно динамично менять их. В этом плане мне работа в EPAM очень нравится. Я могу поработать на проекте полгода, перейти на три месяца в другой, потом попасть в какую-то дискавери активность на две недели, потом на pre sales и так далее. В течение года архитектор может «потрогать» очень много разных технологий, поработать с разными клиентами. Это очень обогащает мой опыт как инженера.

Нет такого, чтобы архитектор был включён в некую жёсткую структуру. Просто существуют требования, которые регулируют твое поведение, как сотрудника. Например, определённый процент времени я работаю с заказчиком. SA 4-го уровня и выше может занимать какие-то роли, связанные с менеджментом, работать на позиции технического директора или его заместителя и так далее. Но он всё равно остаётся инженером и сочетает две эти специальности, инженера и менеджера. В моём случае, на проекте я занят как архитектор, а в CTO — офисе вместе с коллегами развиваю Solution Architecture дисциплину. Это такое организационное творчество, организационная инженерия. В компании большое и очень активное комьюнити архитекторов, в которое входят специалисты из более чем 20 стран — это очень мощный ресурс, возможность поделиться опытом или спросить совет.  

Вообще, у архитекторов в EPAM возможностей для выбора очень много, просто потому что много проектов. Эта такая система, которая сама себя раскручивает. Чем больше архитекторов становится, тем больше возникает в них потребность. Ведь каждый проект пытается иметь по крайней мере одного архитектора, иногда даже нескольких. Если кому-то интересно подольше поработать над сложным проектом, здесь нет препятствий. Если кому-то хочется интенсивно набраться опыта в разных активностях, то и такой вариант возможен. Кому-то же интересен конкретный стек, и он пытается попасть на проект, где этот стек будет. Если архитектор хочет реализовать собственную идею, которая кажется ему клёвой, то это стартует как внутренний проект. У нас есть специальная площадка, где такие вещи можно предлагать.

Когда нужно делегировать решение технических задач команде, а когда самому «становиться за станок»?

Это зависит от конкретной ситуации и от стиля работы человека. Вещи спорные мне удобней проверять «руками», глядя в код или, например, сделав PoC. Мне больше нравится стиль коллегиальной работы. Если ребята предлагают какое-то решение, и оно работает, это круто. Почему нет? У меня в команде есть коллега- разработчик, которому интересно стать архитектором. И мы с ним договорились, что я буду его ментором. Он делает какие-то архитектурные задачи на проекте, вместе их разбираем, комментируем, о чем-то спорим — это помогает попробовать новую активность, когда рядом с тобой есть кто-то, кто подскажет, подстрахует, поможет найти ошибку до того, как она приведёт к проблемам.

Крупным ИT-компаниям нельзя обойтись без архитектора решений?

Старая поговорка «У семи нянек дитя без глаза» здесь, мне кажется, работает. Должен быть человек, который отвечает за техническую сторону дела от начала и до конца. Архитектурой продукта, если он крупный и развивается, нужно постоянно управлять и делать это с командой в рамках цикла разработки. Продукт эволюционирует, появляются новые функции, и нужно уметь гармонично встроить их в архитектуру. Без выделенной должности здесь никуда. Мне кажется, что это правильно.

О дефиците архитекторов и программах их обучения

В EPAM дефицит архитекторов совершенно точно существует. Это при том, что за последние четыре с половиной года мы построили пошаговую систему обучения и развития инженеров , чтобы помогать им становиться архитекторами. У нас существует «Solution Architecture School» — программа для разработчиков, которым интересна архитектура. Это действительно уникальная школа, которая в компании создавалась с нуля, основываясь на нашем опыте и возможностях. Тренерами в ней выступают действующие архитекторы. Программа обучения постоянно обновляется, на протяжении трёх месяцев вычитываются определённые модули. Будущие архитекторы делают практические работы, связанные с профессиональными задачами, разрабатывают дизайн, пишут solution architecture document в качестве домашнего задания, защищают свою работу перед окончанием школы. Потом тренер всё проверяет и комментирует. В Минске конкурс в рамках программы — 4-5 человека на место.  

Ещё у нас есть «Университет». Это трёхуровневая программа, которая рассчитана на уже практикующих архитекторов, мы даём им возможность расти дальше, как экспертам.

То есть мы создали целую систему для людей, которые хотят развиваться в сторону архитектуры. Она даёт свои плоды: довольно большое количество инженеров переходят на должности архитекторов. Тем не менее, как говорит один из наших менеджеров, «нам надо ещё больше».

Также в EPAM есть программа менторинга. Она стартовала два-три года назад, очень классно работает, затрагивает такие дисциплины, как архитектура, менеджмент и другие. Твоим ментором может быть любой более опытный коллега: и старший разработчик, и технический директор, и даже CEO. Если ментор правильный, ты можешь узнать от него много такого, чего не найти в книжках.

Как разработчику не из EPAM вырасти до уровня архитектора?

Один из путей — прийти в EPAM (Смеётся). Я могу посоветовать ресурсы, которые могут помочь в обучении. Но путь, который я рекомендую — это обязательно «трогать» как можно больше технологических стеков. Например, американский научно-исследовательский институт — Software Engineering Institute — их тренинги мы активно используем для нашего университета. Есть глобальная ассоциация архитекторов IASA, с которой мы сотрудничаем, у них можно пройти полезные сертификации.

Об уровне белорусских разработчиков

Мне очень комфортно работать с нашими ребятами. Был опыт сотрудничества с разработчиками из Витебска, Бреста, Гомеля — никогда не было никаких проблем. Приятно, что в сравнении с архитекторами на стороне заказчика, наши специалисты, как мне кажется, часто более подготовлены.

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

Я вижу, что из наших вузов выходят неплохие инженеры. Понятно, что люди бывают разные, но в целом уровень их готовности работать, интереса к технологиям и способности разбираться в них — хороший. Конечно, есть разрыв между знаниями, получаемыми в вузе, и технической реальностью. Но это существует везде в мире. Этот разрыв отчасти нивелируется, благодаря тому, что существуют лаборатории, которые открывает в том числе и EPAM в вузах, есть спецкурсы, которые читают наши инженеры и рассказывают вещи, которые происходят в индустрии прямо сейчас.

О любви к Минску 

Покатавшись по множеству стран (за последние пять лет я побывал много где) я не считаю, что в Беларуси плохо живётся. Мне много раз предлагали работу в других странах, у архитекторов в компании есть возможности для релокации, но мне не хочется уезжать. Уже нет такого контраста между Беларусью и заграницей, как это было, например, в 2001 году, когда я впервые попал в Штаты. Во-первых, я люблю Минск. Я в нем родился, и мне он искренне нравится. Во-вторых, культура, люди, друзья, дети — все это вместе для меня очень важно. Мне нравится кататься в командировки, но я стараюсь не путать туризм с эмиграцией.

О том, как всё успевать

Я фанат тайм-менеджмента. Это помогает. У меня в телефоне два календаря, личный и рабочий, которые я расписываю на неделю вперёд. Есть такой товарищ — Глеб Архангельский. У него есть целая серия книг на тему учёта времени. Когда-то я набрал оттуда какие-то полезные для себя штуки, которые мне помогают.

Что можно посоветовать из хороших практик? Каждый выстраивает свою жизнь исходя из личных предпочтений, топ-3 того, что подходит мне:

1. Календарь для того, чтобы видеть все личные и рабочие дела — это очень удобно, потому что визуализирует свободное и занятое время, а если дел много — то ты ничего не забудешь.
2. Я следую практике «пустого почтового ящика» — все пришедшие письма или превращаются в задачи в календаре, или их содержимое сохраняется для использования позже (полезная презентация, например), или ты на них отвечаешь. После чего все они удаляются или перемещаются в папки для разных категорий писем. Это приводит к тому, что коммуникация с тобой есть всегда и она «живая» — коллеги оперативно получают ответы на свои вопросы. Плюс, ты реально планируешь и делаешь что-то на основе писем. И не тонешь в них.
3. Если есть проблема — всегда важно найти её настоящие причины и запланировать дела, которые эти причины будут устранять. Тогда жить становится гораздо проще — ведь проблем будет меньше.

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

Наверное, самая запоминающаяся командировка была в Штаты. Просто там собралась очень хорошая компания. Там был архитектор из Харькова, архитектор из Бреста, бизнес-аналитик из Киева. Мы замечательно проводили вечера на диване в лобби отеля в городе Сент-Клауд в Миннесоте.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.