5 міфів про роботу архітектора рішень. Думка експерта

Коли в дитинстві ми мріємо стати, скажімо, лікарем або слідчим, то навряд чи достеменно знаємо специфіку цих професії. Подібні ситуації трапляються і з дорослими: уявлення про роботу мрії насправді, як правило, має небагато спільного з реальністю. Але як з'ясувати напевне, де причаїлися підводні камені? Один із способів - поговорити з практиком начистоту! Ми запропонували Андрію Трубіцину, який співпрацює з 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-технологіями. Але -ні. Основна частина роботи архітектора – це документування того дизайну і архітектурних рішень, які застосовуються на проєкті. Деяким може здатися, що це нудно. Тому архітекторами стають люди, які знаходять в цьому щось захоплююче для себе.

Особисто мені приносить масу задоволення малювання діаграм та перетворення їх із заплутаних та складних на красиві, зрозумілі, з рівними і чіткими зв'язками. Найбільша нагорода – почути від ліда, що на цій діаграмі все просто і дуже наочно продемонстровано.

Періодично архітектор бере участь в «нудних» розмовах, де треба донести якусь деталь імплементації клієнту і показати, чому треба робити так, а не інакше. Це може перетворитися на довге листування, але мені цікава і ця активність. Коли я розумію, що спромігся довести оптимальність вибору нашого рішення і це принесло профіт клієнтові, то я почуваюся задоволеним.

Як би там не було, архітектор рішень - це цікава робота. Навіть покликання. Вона дозволяє занурюватися в технології, але не йти при цьому в ізоляцію; їздити у відрядження та спілкуватися з клієнтами; розвивати спільноти талановитих інженерів і прокачувати власні компетенції.

Запитайте знайомого архітектора, чи шкодує він про свій кар'єрний вибір. Закладаюся, він скаже «ні»? ;)