Як стати Application Architect і які навички розвивати. Поради з власного досвіду
Усім привіт! Мене звати Влад, працюю в IT понад 10 років і наразі обіймаю посаду Application Architect у компанії SoftServe.
У статті розповім про свій шлях від студента факультету програмного забезпечення автоматизованих систем Запорізької державної інженерної академії (ЗДІА) до посади архітектора. Цей матеріал буде корисним як програмістам-початківцям, так і спеціалістам з досвідом, які думають, як розвивати далі свою кар’єру.
Коротке інтро
Народився і вчився я у Запоріжжі. У школі цікавився історією України та комп’ютерами, тож вступав і пройшов на історичний факультет ЗНУ і на факультет програмного забезпечення ЗДІА. Та все ж навчатись пішов на програмування.
Із четвертого курсу почав працювати за спеціальністю у Запоріжжі — індустріальному місті, в якому вибір ІТ-фірм не дуже широкий, а великих компаній на кшталт SoftServe, EPAM взагалі немає. На цьому етапі мені доводилось верстати, проєктувати бази даних, писати серверну частину на Zend Framework (PHP) і встановлювати це все на сервери. Це були як прості сайти-візитівки, так і написаний з нуля інтернет-магазин. Зазначу, що саме той досвід був дуже важливий і допоміг мені зрозуміти повний цикл побудови вебзастосунків.
Попрацювавши так певний час, я почав відчувати, що розвиваюсь не так швидко, як би хотілося. Пощастило, що друг закінчив курси в SoftServe IT Academy і порекомендував їх мені. Тоді я пройшов відбір і потрапив на курс Web UI, зібрав речі та переїхав у Львів вчитись.
Після успішного закінчення курсів я розпочав роботу у SoftServe з посади Trainee Web UI (HTML/CSS/JavaScript). Мені пощастило потрапити в команду, де був архітектор, який допоміг мені зорієнтуватися далі. Ми довго працювали разом на різних проєктах, і я бачив, чим саме займається архітектор. І одразу поставив собі за мету розвиватись у цьому напрямі.
Хто такий архітектор
У нашій компанії є кілька варіантів кар’єрного розвитку до позиції архітектора, але, на мою думку, найоптимальнішим є такий:
Сама посада архітектора має ще кілька рівнів:
Детально кар’єрний шлях можна роздивитись тут.
Наразі я Application Architect, тож у мене попереду довгий шлях по кар’єрній драбині. Але в цій статті поділюся досвідом, як дорости від Trainee-інженера до архітектора.
Спершу пропоную розглянути, що це за посада «архітектор», які обов’язки вона передбачає.
Архітектор — це технічний експерт, який ухвалює високорівневі рішення стосовно продукту і стежить, щоб команда правильно втілила їх у життя. Самі рішення архітектор ухвалює, керуючись бізнес-вимогами, нефункціональними вимогами та обмеженнями. З бізнес-вимогами, думаю, все зрозуміло. Нефункціональні вимоги — це, наприклад, можливість застосунку витримувати навантаження, коли багато користувачів одночасно заходять на нього, безпека (захист від атак) тощо. Вищенаведені вимоги та обмеження архітектор має витягти із замовників. Це означає, що він безпосередньо спілкується з клієнтами й має знайти ключ до спілкування з різними людьми, часто складними за характером.
Як дорости до архітектора
Тепер ми можемо сконцентруватися на ключових моментах, які допоможуть на шляху до бажаної посади.
Різносторонній розвиток hard skills та pet-project
Як Web UI інженер я одразу ставив собі за мету стати експертом свого напряму і водночас цікавився серверною розробкою. На мою думку, важливий саме різносторонній розвиток інженера. Якщо на проєкті немає нагоди опанувати нову мову програмування або новий напрям (наприклад, ви пишете на JavaScript для браузера, а хочете писати JavaScript для сервера), рекомендую придумати цікавий домашній проєкт (pet project) і працювати над ним у вільний від роботи час.
Проєкт має бути повноцінним: якщо це сайт, то він має мати домен і бути в публічному інтернеті, якщо мобільна програма, то викладена в App Store або Play Market. Це дасть змогу зрозуміти повний цикл розробки і закрити потрібну сферу. Мені подобаються pet projects, тому я сам вивів у продакшн один благодійний проєкт, вивчивши завдяки цьому цікавий набір технологій. Потім ця робота дала мені матеріал для публічних доповідей — такий от бонус :) Про важливість доповідей ми поговоримо далі.
Наразі у вільний час працюю над новим і цікавим проєктом, що пов’язаний з мобільною розробкою. Вдається виділяти на це
Постійне навчання та самовдосконалення
Головна порада: ніколи не зупинятись і продовжувати постійний розвиток і навчання. Підійдуть будь-які методи: книги, тренінги, конференції. Особливо відзначу конференції. Я почав їх відвідувати 2013 року і продовжую донині. Конференції дають змогу відчути трендові речі, познайомитись з експертами у галузі. Рекомендую не зациклюватись на профільних заходах (наприклад, тільки події JavaScript чи тільки C#), а відвідувати різноманітні форуми.
Я продовжую активно вчитись, адже є ще багато напрямів, де хотілося б отримати досвід і посилити свою компетенцію. Архітектор має тримати руку на пульсі технологій і постійно аналізувати, що нове доцільно використовувати у проєктах, а що ні.
Від себе пораджу те, що мало б допомогти інженеру-програмісту на шляху до позиції архітектора незалежно від спеціалізації.
Книги:
- Object-Oriented Analysis and Design with Applications by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen, Kelli A. Houston
- Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch
- Functional Programming In Javascript by Luis Atencio
- Refactoring by Martin Fowler
- xUnit Test Patterns: Refactoring Test Code 1st Edition by Gerard Meszaros
- Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin
- Software Architecture in Practice (SEI Series in Software Engineering) 3rd Edition by Len Bass, Paul Clements, Rick Kazman
Хмарні сертифікації від AWS, GCP або Azure (класно отримати сертифікат хоча б з однієї «хмари»):
Також для архітектора важливо розуміти, як автоматизується життєвий цикл програмного рішення, починаючи від розробки і закінчуючи розгортанням, підтримкою і моніторингом — те, чим займаються DevOps-інженери. Можу порекомендувати чудовий канал для цього.
Вміння говорити й доносити свою думку
Я вважаю, що найкраще ці навички розвивають публічні виступи. Свої перші презентації я почав готувати ще у 2013 році, розбираючи цікаві теми й розказуючи про це на окремих мітингах членам своєї команди. Потім були виступи на внутрішніх заходах всередині компанії. А згодом і зовнішні презентації.
Найбільшим моїм досягненням є виступ англійською мовою у Вроцлаві 2019 року. Завдяки попередньому досвіду в Україні я мав чудову підготовку: не боявся аудиторії та складних запитань. Це дуже допомогло у Польщі, адже перспектива доповідати англійською мовою додавала переживань. Але все минуло гарно: виступ вийшов цікавий, адже я отримав багато питань від аудиторії.
Навички, які я здобув під час презентацій, дають мені більше впевненості як у перемовинах з клієнтами, так і у спілкуванні з командами.
Виступ на IT Weekend у Рівному, 2018
Вміння брати нові виклики й гідно долати їх
Не боятись випробувань — важливе вміння для архітектора. У своїй кар’єрі я завжди намагаюсь братись за проєкти будь-якої складності, адже саме так найшвидше вчишся і вдосконалюєшся. Якщо вам пропонують стати лідером проєкту — треба погоджуватись. Навіть якщо проєкт здається складним або ви чули відгуки, що там багато проблем. Це буде важко, але потрібно навчитись долати перешкоди.
Найчастіше мене залучають до складних проєктів і я завжди проходжу ці випробування. Для мене найскладнішим викликом було почати керувати людьми. Спочатку запропонували бути технічним лідером команди, яка розробляла клієнтську частину застосунку, а потім і технічним лідером всього проєкту.
Це неймовірно складно — зрозуміти, що твоє завдання тепер не тільки писати якісно код, а й організовувати роботу колективу, говорити з людьми, чути їх. Не все виходило, я припускався помилок. Інколи був занадто вимогливий до колег. Зараз бачу, що це було причиною додаткової напруги на проєкті, та намагаюсь з більшим розумінням ставитись до проблем спеціалістів, адже у житті буває різне і всі ми помиляємось.
Здолати це випробування мені допомогли м’які навички, про які ми поговоримо далі і які є, на мою думку, надзвичайно важливими для архітектора.
Розвиток soft skills і лідерських якостей
М’які навички (англ. soft skills) — комплекс неспеціалізованих, надпрофесійних навичок, які відповідають за успішну участь у робочому процесі, високу продуктивність і, на відміну від спеціалізованих навичок, не пов’язані з конкретною сферою. Детальніше можна почитати тут або на DOU.
Університет Східного Кентуккі склав список м’яких навичок для керівників підприємств. Це зв’язок, люб’язність, гнучкість, цілісність, міжособистісні навички, позитивне ставлення, професіоналізм, відповідальність, командна робота, робоча етика.
Пропоную розглянути деякі приклади:
- Люб’язність. Попри різноманітні обставини треба намагатись бути максимально люб’язними, навіть якщо вам людина не подобається. У кожного трапляються важкі дні, з деким просто складно спілкуватися, але треба вчитись працювати з різними людьми, бо всі ми маємо як плюси, так і мінуси.
- Зв’язок. Працюючи у великій компанії, варто налагоджувати зв’язок з людьми, інвестувати в них свій час. Потім це повертається назад і добре допомагає в роботі.
- Гнучкість. Треба вміти змінювати пріоритети за потреби, перемикатися, швидко пристосовуватись до нових умов. Наприклад: часто архітектора просять допомоги в завданнях, пов’язаних з бізнес-аналізом або з керуванням людьми — варто приставати на це, хоча й міра теж має бути.
Програмісти нерідко нехтують розвитком цих навичок. І даремно — саме проблеми з м’якими навичками часто стають перешкодою на шляху від лінійного інженера до лідера. Тож моя порада така: якщо хочете дорости до лідера, звертайте увагу на софт скіли на старті кар’єри: з вами в команді має бути приємно працювати (і колегам, і клієнтам), а керівник проєкту має спокійно покладатись на вас.
Недарма рекомендують мати лідерський досвід для отримання посади архітектора. Тобто інженер повинен попрацювати певний час технічним лідером і тільки після того може рухатись в архітектуру. Нерідко люди не розуміють, для чого це треба. Насправді архітектор має бути лідером для лідерів, вибачте за тавтологію. Архітектор працює в лідерській команді з менеджерами, лідером інженерів з контролю якості, з бізнес-аналітиками, дизайнерами й технічними лідами. Тут важливо навчитись знаходити спільну мову зі всіма лідерами команди, особливо з технічними, адже саме вони мають втілити у життя те, що запроєктував архітектор.
Без лідерського досвіду і м’яких навичок зробити все вищенаведене буде важко. Колись я працював у команді, де керував усім головний архітектор. Людина мала колосальний технічний досвід і знання, але зовсім не володіла софт скілами. Це призводило до того, що головний архітектор фактично не міг пояснити ані своїм архітекторам, ані менеджерам команд, в яких ті архітектори працювали, для чого потрібно впроваджувати ті чи інші технічні рішення. У результаті технічні рішення або втілювались неправильно, або саботувались через нерозуміння.
Крім того, архітектор має знаходити спільну мову з топменеджерами замовників. Це переважно люди, які багато чого досягли у житті й мають своє чітке бачення на багато технічних питань. Саме тут архітектору знадобляться м’які навички, щоб вдало побудувати стосунки. А від того, наскільки добре це вдасться, залежить доля проєкту.
Висновок
Отже, хороший архітектор — це лідер із сильними технічними знаннями, багатим досвідом і чудовими м’якими навичками. Від успішної роботи архітектора залежить майбутнє проєкту/компанії, адже він має витягнути із замовників/власників потрібну інформацію для побудови системи та довести їм, що ухвалені рішення є правильними. А також простежити, щоб команда розробників належним чином втілила ці рішення у життя.
Саме це й надихає мене в роботі: можливість реалізувати себе у складних умовах і допомогти зробити бізнес замовників успішним або ж посилити успіх.
