Когда в детстве мы хотим стать, скажем, врачом или следователем, то едва ли знаем специфику профессии. Похожие ситуации случаются и со взрослыми: представления о работе мечты на поверку имеют мало общего с реальностью. Но как выяснить наверняка, где скрыты подводные камни? Один из способов – поговорить с практиком начистоту! Мы предложили Андрею Трубицыну, который сотрудничает с EPAM в качестве Solution Architect из Java Competency Center, развенчать распространенные мифы о работе архитектора.
Реальность – особенно на новых проектах или стримах – чаще всего другая. На старте проекта, на котором я сейчас работаю, мне надо было отправиться в Штаты, в офис клиента, чтобы принять участие в discovery-фазе и сессии планирования. После этого я приехал в Харьков, где были собраны две команды, которые никогда до этого не работали вместе. В этой ситуации потребовалось совмещение роли архитектора и бизнес-аналитика: я не только подсказывал технологические решения, обучал работе с микросервисами и делал ревью кода, но также выяснял и обсуждал с командой разные use cases и детали функционала. Вместе с коллегой, Евгением Ефремовым, PM-ом и Scrum-мастером на этом проекте, мы налаживали процесс работы по SAFе-фреймворку.
Кроме того, в силу опыта и непосредственного знакомства с клиентом, мне было легче предугадать развитие ситуации наперед, подсказать команде, как лучше коммуницировать с клиентом, как реагировать на сложные ситуации, какой уровень детализации в описаниях будет достаточным (инженеры порой грешат тем, что злоупотребляют технологическими тонкостями. На самом деле, тирада о том, что «...JSON-формат, который приходит от стороннего сервиса, начинается не с того символа, который ожидается, и по этой причине происходит какой-то сбой...», для человека, который всю жизнь работает в другой сфере, будет излишней).
Кроме того, надо поддерживать команду. На моем проекте – в силу микросервисной архитектуры – очень частые релизы и динамичный ритм работы. Мы всегда в тонусе и многим ребятам такой интенсив по душе. Тем важнее благодарить инженеров за их инициативность, поддерживать в работе, вселять уверенность в начинаниях. Если командный дух и ориентированность на результат сильны, то через несколько итераций выделяются люди, которые показывают высокие результаты. Думаю, некоторые из них смогут стать архитекторами через год-два.
Особняком стоят проекты, на которых ситуация в менеджмент-команде настолько сложная, что за весь процесс деливери продукта де-факто отвечает SA.
Это неправда. Архитектор знает не всё. Но ему действительно необходимо стремиться изучать больше технологий и их особенностей, чем любому другому техническому человеку на проекте. А еще – SA должен смотреть вперед, думать о перспективах. Не зря говорят, что инженеры – это скоростные поезда, а архитекторы – это те, кто прокладывает пути, чтобы они не застряли в каком-то болоте.
В целом, архитектору необходимо постоянно заниматься самообучением. Моя норма – тратить не меньше 10 часов в неделю на изучение не связанных со своим проектом технологий. В этом, в частности, помогают профессиональные сообщества архитекторов в компании. Там постоянно проходят обсуждения разных кейсов и сессии обмена знаниями.
Как правило, когда ты приходишь в роли архитектора к клиенту, то уровень доверия к тебе чуть выше нуля (и то только потому, что они ожидают увидеть улыбающегося человека в рубашке :) ). Основная задача SA – а в последствие и команд – доказать клиенту, что он может доверять нам. И если сначала ощущается, как заказчик придирчиво проверяет все шаги и все действия, которые ты предпринимаешь, то со временем у тебя появляется возможность советовать клиенту, что и как делать. Именно наработанный уровень доверия позволил аккаунту моего проекта вырасти до 200 человек (70 из которых работают в Харькове). И мы продолжаем расти!
Через несколько месяцев наша команда планирует использовать Kubernetes и Istio как платформу для микросервисов, потому уже сейчас мне надо углубляться в тему, изучать все связанные технологии, чтобы во время непосредственного перехода обеспечить техническую поддержку команд и передать им знания быстро и качественно. Это намного эффективнее, чем всем вместе погружаться в тему с нуля.
При этом архитектор имеет право на ошибку и должен уметь ее признать, исправить и двигаться дальше. Избежать их помогает непосредственное общение с лидами проектов. Надо устраивать командные брейштормы и рассматривать решение со всех сторон, чтобы найти потенциальные сложности с внедрением тех или иных технологий на проекте. Без команды архитектор не сможет привести проект к успеху.
Понятие “architect in an ivory tower” – то есть SA, который сидит где-то высоко, занимается чем-то своим, а инженеры в это время находятся в реальном деливери – возникло не на пустом месте. Архитектор такого типа не помогает проекту, его помощь не нужна команде.
Чтобы SA не воспринимали как еще одно человека, который пришел командовать, важно не бытьвсезнайкой, а наблюдать, чем занимаются коллеги на проекте, и помогать. Помогать не только советами, но и «руками»: писать код, когда необходимо, делиться опытом, выяснять детали и подробности, чтобы быть максимально в контексте непосредственной разработки. Постепенно, когда команды увидят, что действия архитектора идут на пользу, ему начинают по-настоящему доверять. Тогда взаимодействие становится максимально гладким и позволяет со временем переходить на более высокий уровень абстракциии, делегировать архитектурные задачи техническим лидам.
Вообще, архитектор и не должен принимать абсолютно все решения в одиночку. Ведь на большом проекте он не погружен в абсолютно все аспекты применения той или иной технологии. Только после детального обсуждения с ключевыми людьми на проекте можно делать решительный шаг.
Бытует мнение, что архитекторы всегда занимаются чем-то новым, вовлечены в бесконечные R&D активности, работают с cutting edge-технологиями. Но нет. Основная часть работы архитектора – документирование того дизайна и архитектурных решений, которые применяются на проекте. Некоторым может показаться, что это скучно. Потому архитекторами становятся люди, которые находят в этом что-то увлекательное для себя.
Например, мне доставляет массу удовольствия рисовать диаграммки и превращать их из запутанных и сложных в очень красивые, простые, с ровными и четкими связями. Самая большая награда – когда эту диаграмму видит лид и говорит, что в ней все просто и очень понятно продемонстрировано.
Периодически архитектор участвует в «скучных» разговорах, где надо донести какую-то деталь имплементации клиенту и показать, почему надо делать так, а не иначе. Это может превратиться в длинные треды переписки, но мне интересна и эта активность. Когда я понимаю, что смог доказать оптимальность выбора нашего решения и это привело к профиту для клиента, то получаю удовольствие.
Как бы там ни было, архитектор решений – это интересная работа. Даже призвание. Она позволяет погружаться в технологии и не уходить при этом в изоляцию; ездить в командировки и общаться с клиентами; развивать сообщества талантливых инженеров и прокачивать собственные компетенции.
Спросите у знакомого архитектора, жалеет ли он о своем карьерном выборе. Спорим, он скажет «нет»? ;)
Интервью и текст подготовила Ксения Бай, эксперт по коммуникациям EPAM Ukraine.
Миф №1. Архитектор решений не занимается менеджерскими задачами на своем проекте. Его дело – технологии!
Реальность – особенно на новых проектах или стримах – чаще всего другая. На старте проекта, на котором я сейчас работаю, мне надо было отправиться в Штаты, в офис клиента, чтобы принять участие в discovery-фазе и сессии планирования. После этого я приехал в Харьков, где были собраны две команды, которые никогда до этого не работали вместе. В этой ситуации потребовалось совмещение роли архитектора и бизнес-аналитика: я не только подсказывал технологические решения, обучал работе с микросервисами и делал ревью кода, но также выяснял и обсуждал с командой разные use cases и детали функционала. Вместе с коллегой, Евгением Ефремовым, PM-ом и Scrum-мастером на этом проекте, мы налаживали процесс работы по SAFе-фреймворку.
Кроме того, в силу опыта и непосредственного знакомства с клиентом, мне было легче предугадать развитие ситуации наперед, подсказать команде, как лучше коммуницировать с клиентом, как реагировать на сложные ситуации, какой уровень детализации в описаниях будет достаточным (инженеры порой грешат тем, что злоупотребляют технологическими тонкостями. На самом деле, тирада о том, что «...JSON-формат, который приходит от стороннего сервиса, начинается не с того символа, который ожидается, и по этой причине происходит какой-то сбой...», для человека, который всю жизнь работает в другой сфере, будет излишней).
Кроме того, надо поддерживать команду. На моем проекте – в силу микросервисной архитектуры – очень частые релизы и динамичный ритм работы. Мы всегда в тонусе и многим ребятам такой интенсив по душе. Тем важнее благодарить инженеров за их инициативность, поддерживать в работе, вселять уверенность в начинаниях. Если командный дух и ориентированность на результат сильны, то через несколько итераций выделяются люди, которые показывают высокие результаты. Думаю, некоторые из них смогут стать архитекторами через год-два.
Особняком стоят проекты, на которых ситуация в менеджмент-команде настолько сложная, что за весь процесс деливери продукта де-факто отвечает SA.
Миф №2. Архитектор знает все о технологиях
Это неправда. Архитектор знает не всё. Но ему действительно необходимо стремиться изучать больше технологий и их особенностей, чем любому другому техническому человеку на проекте. А еще – SA должен смотреть вперед, думать о перспективах. Не зря говорят, что инженеры – это скоростные поезда, а архитекторы – это те, кто прокладывает пути, чтобы они не застряли в каком-то болоте.
В целом, архитектору необходимо постоянно заниматься самообучением. Моя норма – тратить не меньше 10 часов в неделю на изучение не связанных со своим проектом технологий. В этом, в частности, помогают профессиональные сообщества архитекторов в компании. Там постоянно проходят обсуждения разных кейсов и сессии обмена знаниями.
Миф №3. Должность SA делает тебя по умолчанию экспертом
Как правило, когда ты приходишь в роли архитектора к клиенту, то уровень доверия к тебе чуть выше нуля (и то только потому, что они ожидают увидеть улыбающегося человека в рубашке :) ). Основная задача SA – а в последствие и команд – доказать клиенту, что он может доверять нам. И если сначала ощущается, как заказчик придирчиво проверяет все шаги и все действия, которые ты предпринимаешь, то со временем у тебя появляется возможность советовать клиенту, что и как делать. Именно наработанный уровень доверия позволил аккаунту моего проекта вырасти до 200 человек (70 из которых работают в Харькове). И мы продолжаем расти!
Через несколько месяцев наша команда планирует использовать Kubernetes и Istio как платформу для микросервисов, потому уже сейчас мне надо углубляться в тему, изучать все связанные технологии, чтобы во время непосредственного перехода обеспечить техническую поддержку команд и передать им знания быстро и качественно. Это намного эффективнее, чем всем вместе погружаться в тему с нуля.
При этом архитектор имеет право на ошибку и должен уметь ее признать, исправить и двигаться дальше. Избежать их помогает непосредственное общение с лидами проектов. Надо устраивать командные брейштормы и рассматривать решение со всех сторон, чтобы найти потенциальные сложности с внедрением тех или иных технологий на проекте. Без команды архитектор не сможет привести проект к успеху.
Миф №4. Проектная команда всегда слушает архитектора
Понятие “architect in an ivory tower” – то есть SA, который сидит где-то высоко, занимается чем-то своим, а инженеры в это время находятся в реальном деливери – возникло не на пустом месте. Архитектор такого типа не помогает проекту, его помощь не нужна команде.
Чтобы SA не воспринимали как еще одно человека, который пришел командовать, важно не бытьвсезнайкой, а наблюдать, чем занимаются коллеги на проекте, и помогать. Помогать не только советами, но и «руками»: писать код, когда необходимо, делиться опытом, выяснять детали и подробности, чтобы быть максимально в контексте непосредственной разработки. Постепенно, когда команды увидят, что действия архитектора идут на пользу, ему начинают по-настоящему доверять. Тогда взаимодействие становится максимально гладким и позволяет со временем переходить на более высокий уровень абстракциии, делегировать архитектурные задачи техническим лидам.
Вообще, архитектор и не должен принимать абсолютно все решения в одиночку. Ведь на большом проекте он не погружен в абсолютно все аспекты применения той или иной технологии. Только после детального обсуждения с ключевыми людьми на проекте можно делать решительный шаг.
Миф №5. У архитектора не бывает скучной, рутинной работы
Бытует мнение, что архитекторы всегда занимаются чем-то новым, вовлечены в бесконечные R&D активности, работают с cutting edge-технологиями. Но нет. Основная часть работы архитектора – документирование того дизайна и архитектурных решений, которые применяются на проекте. Некоторым может показаться, что это скучно. Потому архитекторами становятся люди, которые находят в этом что-то увлекательное для себя.
Например, мне доставляет массу удовольствия рисовать диаграммки и превращать их из запутанных и сложных в очень красивые, простые, с ровными и четкими связями. Самая большая награда – когда эту диаграмму видит лид и говорит, что в ней все просто и очень понятно продемонстрировано.
Периодически архитектор участвует в «скучных» разговорах, где надо донести какую-то деталь имплементации клиенту и показать, почему надо делать так, а не иначе. Это может превратиться в длинные треды переписки, но мне интересна и эта активность. Когда я понимаю, что смог доказать оптимальность выбора нашего решения и это привело к профиту для клиента, то получаю удовольствие.
Как бы там ни было, архитектор решений – это интересная работа. Даже призвание. Она позволяет погружаться в технологии и не уходить при этом в изоляцию; ездить в командировки и общаться с клиентами; развивать сообщества талантливых инженеров и прокачивать собственные компетенции.
Спросите у знакомого архитектора, жалеет ли он о своем карьерном выборе. Спорим, он скажет «нет»? ;)
Интервью и текст подготовила Ксения Бай, эксперт по коммуникациям EPAM Ukraine.