Шлях від Junior Software Engineer до Solution Architect II. Досвід Зінура Мустафаєва

Поступово кількість завдань збільшувалась, а рівень відповідальності зростав. Я розвивав свій кругозір, прагнув чогось нового та більш цікавого.

Варто зауважити, що кожні два-три роки я переходив на новий проєкт. Для мене це трохи схоже на перехід до іншої компанії, коли довкола все нове: люди, технології, домен, завдання та виклики.

В моїй кар'єрі був етап, коли я виконував роль ресурсного менеджера, але зараз відчуваю, що менеджерські позиції мене не дуже ваблять. Натомість я вирішив сфокусуватись на архітектурі, стати тренером у SAS (Solution Architecture School) та брати участь у пресейлах, наскільки це можливо. Також мені подобається позапроєктна активність, наприклад, участь в інтерв'ю (внутрішніх та зовнішніх) або асесментах. До речі, це дуже допомагає, коли починаєш нудьгувати на проєкті.

Розподіл робочого часу може відрізнятись. На теперішньому проєкті я можу собі дозволити приділяти йому десь 30% всього часу, а 70% займають усі інші активності. Наприклад, зараз я виконую роль архітектора для трьох команд та допомагаю розвивати Java-напрям у Java Resource Pool.

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

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

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

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

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

Ментори допомагають знайти відповіді на певні питання, підготуватися до асесменту — оцінюванні при переході на вищу позицію. Наприклад, у свого останнього ментора я вчився правильному підходу до клієнта — коли спілкуватись, як це правильно робити тощо. Я звик спускатися на технічний рівень розробника, щоб краще розуміти контекст проблеми чи дізнатися деталі. Але тут важливо знайти баланс. Занурившись у код та рутину, іноді важко побачити проблему з усіх боків. Досвід ментора допомагає знайти нові шляхи її вирішення.

В EPAM є програма менторства, яка дає змогу обрати для себе ментора з фокусом на тому аспекті, який мене цікавив. 

Якщо говорити про мотивацію, то для одним із стимулів для мене є приклад мого старшого брата, який також займається архітектурою. Елемент змагання не дає розслабитись та спонукає завжди рухатись далі. 

Звичайно, все залежить від проєкту. Існує формальний список обов'язків, які мають виконувати архітектори. Але в реальному житті чимало факторів впливає на те, що ти робитимеш на проєкті. Не слід очікувати, що ти займатимешся лише пресейлами чи малюванням діаграм. Зі свого досвіду я знаю, що треба обов'язково торкнутись всього, зануритись, зрозуміти біль та вирішувати проблему в рамках своїх архітектурних завдань. Вивчення проблеми зсередини дає більше контексту для розуміння повної картини того, що взагалі відбувається.

Напрямок архітектури дуже змінився з моменту своєї появи. Спочатку не було чітких вимог до того, що має вміти фахівець та чим він взагалі повинен займатись. Раньше не існувало проміжної позиції при переході з позиції ліда до позиції архітектора. Також досить складно було пройти асесмент. Сьогодні вже є певні стандарти, яким чином це має відбуватись. В EPAM існує певна процедура та чітке розуміння того, що і на якому рівні повинен вміти архітектор. До речі, вимоги та стандарти роботи для позиції архітектора в EPAM дозволяють спеціалісту бути затребуваним на ринку. В цьому плані в компанії спираються на світовий досвід та не віддаляються від реальності. 

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

Якщо ви вже досягли позиції Lead Software Engineer, тобто вже маєте певний досвід, можу дати пораду, спираючись на свій кар'єрний досвід.

Якщо тобі комфортно працювати з людьми, розподіляти завдання  перевіряти їх виконання та налагоджувати процеси, раджу дивитись у бік проєктного або Delivery менеджмента.

Якщо більше до вподоби технології, можна розглянути ще позицію Chief Software Engineer, яка є в EPAM і передбачає експертну роботу з конкретною технологією.

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