Кар’єра senior-спеціаліста: куди розвиватися далі, що для цього потрібно знати та вміти

Привіт, мене звуть Андрій, я Competence Manager у SoftServe. В ІТ я понад 20 років, останні 5 з яких я працюю в напрямку, пов’язаному з кар’єрним розвитком наших інженерів. Також я займаюся дизайном і розвитком Technology Leadrship позицій. Багато залучений до створення дорожніх карт (roadmaps) для розвитку спеціалістів і допомоги їм зростати на їхньому професійному шляху.

Кожна компанія будує власний кар’єрний шлях software-інженера, вводить свою термінологію та поділ на рівні. Якщо не вдаватися в деталі, в більшості випадків senior — це найвищий щабель для індивідуального виконавця (англ. individual contributor — фахівець, який глибоко розбирається в певній області і самостійно відповідає за реалізацію конкретної функції чи виконання певної задачі).

Але куди розвиватися далі? Які є шляхи розвитку для senior від індивідуального виконавця (individual contributor) до лідера, який має технологічний, інжиніринговий чи бізнесовий вплив і відповідальність на проєкті? Свідомо опустимо зміну кар’єри у сферу менеджменту, продажів і так далі, адже перехід у ці напрямки часто передбачає зовсім інший набір компетенцій, навичок і знань.

У цій статті я спробую окреслити кар’єрний шлях тим, хто прагне розвиватись і розширяти свою технічну експертизу та фокусується не на глибині, а на ширині знань.

Чому senior — це найвища сходинка

ІТ-компанії розуміють, що інженерам хочеться розвиватися, інженери у відповідь очікують якогось формального закріплення отриманих нових навичок і знань. І як наслідок, компанії створюють нові посади чи рівні, які «подовжують» кар’єрних шлях senior-ів.

На американському ринку це переважно реалізовано як додаткові рівні/ підрівні в senior-а: Senior Level 2, 3, і так далі. Senior нерідко зберігає свою посаду упродовж багатьох років, разом з тим його кваліфікація, знання, продуктивність, а також зарплатня зростає. Такий спеціаліст тривалий час якісно виконує свою роботу, розвивається, поглиблює знання, набуває нових навичок, опановує нові технології, але водночас залишається individual contributor-ом.

Українські ж компанії для такої диференціації часто використовують специфічні назви: Lead Engineer, Expert Engineer, Advanced Engineer і так далі. В різних компаніях вони називаються по-різному, але насправді це все варіації на тему individual contributor. А різниця між рівнями встановлюється завдяки технологічній глибині, продуктивності в імплементації і технічній складності задач. Кожна компанія самостійно вирішує, чи створювати такі додаткові щаблі, чи ні, але вакансій на такі позиції мало.

А чи є альтернативи технологічній глибині? Якщо не індивідуальний виконавець, то хто? Розгляньмо шляхи розвитку кар’єри senior-а, які йдуть скоріше в ширину та в бік лідерства. Хоча вони і базуються на наявному досвіді і знанні технології, але, крім того, вимагають інших важливих навичок і компетенцій. Кожен із запропонованих напрямків дасть змогу продовжувати розвиватися, але з новим фокусом.

Шляхи розвитку senior

Technical Leader

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

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

Людина на цій позиції бере на себе відповідальність за роботу інжинірингової команди та імплементацію тих чи інших практик на проєкті: code review, CI/CD, автоматичний аналіз коду, security checks, роботу з third party library, стандарти кодингу, політики деплойменту, формалізацію інфраструктури і т.д. Також в переліку його активностей робота з вимогами (requirements) та оцінками (estimates), що в кінцевому результаті позитивно впливає на швидкість імплементації функціонала командою. Комунікація зі стейкхолдерами зі сторони клієнта переважно обмежується своїм проєктом. Хоча нерідко в результаті up-sale активностей, що мають на меті розширити кооперацію, залучаються представники клієнта з суміжних проєктів. В комунікації Technical Leader виступає медіатором між різними стейкхолдерами: як з боку менеджерських функцій (PM-и, Engineering Managers, Product Owners з боку клієнта) так і технічних (техліди, архітектори, команда інженерів та QA).

Активності Technical Leader:

• Написання коду та імплементація функціонала (залежно від проєкту, це може займати від 10% до 60% часу).
• Code review, перевірка на стандарти коду, якість делівері.
• Вибір, документування та дотримання branching, testing, deployment та інших стратегій і процесів.
• Технічний дизайн (ухвалення рішень щодо бібліотек, патернів, структури проєкту і тд.).
• Відповідальність за вирішення термінових або комплексних проблем з продуктом.
• Валідація поточного стану до очікуваної архітектури.
• Просування технічного росту команди.
• Міжкомандна взаємодія.

Technical Architect

Також зустрічаються альтернативні назви: Application Architect, Software Architect чи навіть просто Architect.

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

Одна з основних задач Technical Architect — це допомагати у pre-sales, розробляти та оцінювати технічні рішення для клієнта. Він також зустрічається з потенційними клієнтами, проводить так звані quality attribute workshops, метою яких є прокомунікувати з різними бізнес-стейкхолдерами і зібрати очікування кожного щодо критичних атрибутів рішення. А це, окрім технологічних навичок, потребує також специфічних soft skills і умінь, адже результати таких воркшопів впливають на створення продукту, його ціну, закриття бізнес-задач і, як наслідок, повернення інвестицій замовником.

Треба, однак, зважати на те, що Technical Architect — це перший рівень в архітектурному шляху, і тому такий фахівець відповідає лише за часткове рішення (наприклад, яке стосується конкретного продукту або його підсистеми з використанням певної технології).

А вже далі, з ростом експертизи, отриманням досвіду, заглибленням в якийсь бізнес-домен технічний архітектор виростає в Solutions Architect і займається комплексним рішенням в цілому; а у великих компаніях — навіть до Enterprise Architect, який відповідає за набір рішень для величезної компанії чи якогось її підрозділу.

Активності Technical Architect:

• Брати участь у зборі та аналізі вимог під час pre-sales активностей чи на початкових стадіях співпраці з клієнтом (фаза discovery).
• Визначення не функційних вимог (quality attributes).
• Побудова високорівневої структури рішення, ухвалення trade-off рішень.
• Підбір і рекомендація релевантного стеку технологій.
• Допомога dev-команді на початкових етапах проєкту та консультації в ході розробки.
• Залученість в імплементацію різного роду PoC.

Technical Consultant

Це спеціаліст, який має дуже ґрунтовні і глибокі знання певної технології, які покривають також і всю її ширину. Тобто, цей досвід не обмежується якоюсь однією бібліотекою чи підходом, а включає весь горизонт наявних в технічному стеку бібліотек, інструментів і процесів. Додатково, такий фахівець повинен мати ґрунтовні знання в суміжних чи альтернативних технологіях (в основному, в хмарних).

Technical Consultant є свого роду «продавцем технології». Такий фахівець закриває всі питання щодо використання конкретної технології, а також її поєднання з хмарною інфраструктурою, завжди має відповідь на питання «ціни» реалізації того чи іншого завдання. Володіючи глибокими технологічними знаннями, він може презентувати всі особливості технології до найменших дрібниць, надати пораду клієнту чи допомогти у вирішенні (troubleshoot) найскладнішого рівня проблем.

Активності Technical Consultant:

• Комунікація з бізнес і технічними стейкхолдерами.
• Досконале знання технології.
• Hands-on досвід в роботі з лендскейпом технології.
• Дослідження і вирішення performance і production issues.

Інша технологія як альтернативний кар’єрних шлях

У попередньому блоці ми розглянули три варіанти розвитку senior-інженерів у нових професіях, однак дуже часто фахівці, які достатньо заглибилися в одну технологію, починають паралельно опановувати іншу. Знання і досвід застосування допоміжного технологічного стеку також може вплинути на ріст авторитету інженера.

Майже у всіх аутсорс-компаніях так чи інакше присутній процес зміни кар’єрного напрямку. У невеликих — це зазвичай відбувається здебільшого неформально, що пов’язано з малою кількістю кадрів, які повинні по максимуму закривати всю ширину потреб клієнта.

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

З досвіду, я часто зустрічаю перехід не лише з конкретного фреймворку, наприклад, з Angular на React, а й між технічними стеками — з Java на Go, чи навіть зміну спеціалізації з Web-розробки на Mobile.

Дуже затребуваним є перехід досвідчених інженерів у Big Data чи Data Science. Також має попит перехід в рідкісні технології, де досить мала кількість спеціалістів (наприклад, Scala чи Elixir). Саме наявність практичного досвіду є вирішальним при русі в ці напрямки. Без попереднього досвіду розробки на реальних проєктах набагато складніше зайти у ці напрямки.

Перехід у напрямок платформ

У великих компаніях клієнтам часто надають не тільки сервіси, що стосуються generic code application development, а й розвивають напрямок платформ. Серед них популярними на сьогодні є:

• CRM/ERP-платформи (Salesforce, SAP, NetSuite),
• інтеграційні платформи (MuleSoft, Apigee, Boomi),
• DXP-платформи (Sitecore, AEM),
• а також різні low-code/no-code платформи (Pega, ServiceNow, Power Platform).

Звичайно, для такого переходу потрібно буде дещо довчити, дещо попрактикувати, адже все-таки є різниця між просто роботою з кодом і роботою з кодом у якійсь платформі. Скажімо, якщо ви пишете на Java, то для платформ використовуватимете плюс-мінус ті ж самі патерни в коді, але там додатково з’являються свої специфічні патерни, методології і підходи. Додатково треба знайомитись з так званим built-in функціоналом. Потрібно набивати свої «ґулі», пов’язані з обмеженнями конкретної платформи.

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

Для роботи з платформами потрібні й додаткові компетенції. Скажімо, для Salesforce окрім вміння писати код, треба ще й мати розуміння бізнес-домену та проблематики клієнта. Важливо розуміти, як запропоновані рішення будуть імплементуватись і чи взагалі їх можна реалізувати на конкретній платформі. Адже, якщо в application development можна написати будь-що, то у роботі з платформами з’являються обмеження, як-от ліміт на доступ до бази даних чи розмір даних. Це можуть бути обмеження на час виконання певного шматка коду чи ліміт пам’яті, на який розробник не може вплинути.

Наостанок

Сеньйорність слід розглядати не з точки зору набору певних технічних знань, а з точки зору вмінь та досвіду. Senior-інженер — це все ще individual contributor, який може самостійно забезпечити імплементацію частини функціонала для забезпечення бізнес-потреб клієнта.

Для цього спеціалісту варто розуміти бізнес-домен клієнта, його фокуси, на чому він отримує прибуток, аби не просто сліпо виконувати задачі, а мати змогу запропонувати покращення або альтернативні шляхи вирішення. Senior повинен мати достатньо глибоке розуміння технології, її слабких і сильних сторін, бачити різні варіанти розв’язання задач, вміти ухвалювати рішення, працювати як самостійно, так і разом у команді.

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

Головне — це не спинятися у розвитку. Запитуйте себе, що ви можете зробити, аби бути ефективнішими, вирішувати потреби клієнтів, допомагати бізнесу зростати та досягати поставлених цілей.