Кар’єра 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 повинен мати достатньо глибоке розуміння технології, її слабких і сильних сторін, бачити різні варіанти розв’язання задач, вміти ухвалювати рішення, працювати як самостійно, так і разом у команді.

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

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

👍ПодобаєтьсяСподобалось19
До обраногоВ обраному11
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Technical Architect
Також зустрічаються альтернативні назви: Application Architect, Software Architect чи навіть просто Architect.

солюшен аркітек

Technical Consultant

тю, в аутсорсі всі є консультантами,
в мене тайтл в бодішопі «сенйор консультант»

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

ніт,
вище є принципал

Головне
вирішувати потреби клієнтів

Вся стаття за 4 слова. Більше тут нічого нема

Зо робити з рекрутерами що вимірюють досвід в технологіях роками?

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

0–2 джун

2–5 мідл

5++ сініор

Наче завжди так було

до $1000 джун
до $4500 мідл
від $4500 сенйор

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

Якщо не брати до уваги інтернів, то є лікарі другої категорії, першої і вищої. Підвищувати категорію або підтверджувати наявну можна десь раз на 5 років. Тобто людина після медвузу та інтернатури десь у 25 років може стати лікарем другої категорії (стронг джун), у 30 років здобути першу (стронг мідл) і в 35 стати лікарем вищої категорії (стронг сеніор з 10 роками досвіду).

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

Я б хотів, щоб таке ж відношення було й до інженерів. Щоб хороших розробників, які не хочуть рухатися далі — не змушували рухатися далі. І щоб сеніор з 20-30+ роками досвіду, який ніколи не був лідом, архітектором, СТО чи ще кимось — не вважався «безамбітним другосортним недоспеціалістом».

Є нюанс. Сіньорів тре то більше, то менше. Відповідно мати спеціалізацію, чи доп обов’язки, які роблять тебе особливим для проекту чи на ринку в загалі вигідно. А от лікарів багато не буває

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

За зарплату лікарів вам таке радо влаштують :)

Проблема в тому, що у лікарів, щоб отримувати норм ЗП треба якщо не рвати, то хоча б докладати зусиль, але як неприємний бонус там ще часто зустрічається свинське відношення менеджменту.

Є нюанс... якщо не рухатись далі, то це є рух назад. І для лікарів в тому числі.

Тому, з свого невеликого досвіду, скажу, що ті лікарі які постаріше (30 і більше років досвіду) не факт, що запропонують адекватне лікування. Вони хоч і мають величезний досвід, але він може виявитись дууже вузьким і не знати контексту того, що винайшли останнім часом.

Це як 30 років досвіду роботи з fortran. Добре, але трохи «таке».

а що, людина за 30 років стала іншою?

Світ став іншим. Методи 30річної давності станом на сьогодні є варварством (подивіться хоч на стоматологію)

антиковвакцинація жижами однозначно не варварство

Справді цікаво було б так порівняти медицину та ІТ.
По-перше у медицині є протоколи лікування, є страхові компанії, є аудит, регулятори, перевірки. Жоден доктор не лікує пацієнта як він сам забажає. Якщо і існують деякі експериментальні методи лікування — то вони у медичних інститутах та під контролем.
Отже пацієнт у більшості випадків може буде впевнений що його будуть лікувати як треба і не відріжуть нічого «зайвого».
Також медицина не потребує зайвого маркетингу: коли людині болить — у неї є величезний стимул іти до доктора. Навіть якщо людина відмовляється — це вже робота для спеціальних лікарів (психологів).
Тобто медицина це НАУКА, яка практикує науковий підхід із мінімумом ризиків.
ІТ — повна протилежність. Починаючи з того, що більшість знань девелопери отримують самотужки. Немає ніякої «обов’язкової програми», нема ніяких екзаменів та підтвердження категорії. Десь можна стати синьором за 10 років — а десь за 3. І це нічого не доводить: бо кожен девелопер — це не доктор, а «шаман», який лікує своїми методами. Хтось усюди ліпить функції — інший класи. Особливо коли у них у руці такий універсальний інструмент, як JavaScript. Це як хірург із сокирою замість скальпеля: профі і сокирою зробить файно, але не-профі просто по-відрубає усе, що болить.
Але найгірше — то «пацієнти». Уявить пацієнта, якого ще треба довго переконувати що йому потрібне саме це лікування, і який каже що не хоче платити за «зайві» ліки. І при цьому пацієнт правий — бо кожен ІТ проект це «експериментальна медицина» і чим він закінчиться — ніхто не гарантує!
Отже бачимо що, на відміну від медицини, ІТ поки що РЕМЕСЛО, де кожен «майстер» та кожна «майстерня» робить як хоче. Якість — поняття «відносне». Нема контролю та нема страховки — отже клієнту нема куди скаржитися.
І якщо хороший доктор не потребує зайвої реклами (його контакти і так передадуть врятовані пацієнти) — то ІТ синьору ще треба себе «продати». Тому ІТ компанії тиснуть на синьорів аби ті виступали на конференціях, спілкувалися з клієнтами, менторили команду.
Бо, нажаль, на відміну від докторів чи інженерів, ІТ синьори в аутсорсі — не професіонали, а «народні цілителі», «екстрасенси» та інші шарлатани, які не можуть пишатися вилікуваними пацієнтами чи успішними рішеннями. «Хуяк-хуяк і в продакшин!»

Хм, медицина то наука значить, а айтішечка значить нє...

Тьюринг і Дейкстра зараз мабуть зробили би фейспалм.
(То що більшість айтівців того тьюринга навіть не читали то якби не робить його менш науковим)

І щоб ви знали — ніякі регулятори і протоколи не врятують вас від дуууже поганого лікування
(Бо вони насправді трохи не про те)
Маю досвід мед проекту, там трохи краще видно

медицина то наука значить, а айтішечка значить нє...

наука працює з теоріями, які доказуються експерементом (або не доказуються)

Де той старий ДОУ, коли після 35 років рекомендували сплавлятися по Дніпру

Певно, доріс до 35 і сплавився

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

нічого не міняти завжди комфортніше за зміни.
ІМХО, якщо є можливість попробувати бути лідом то треба пробувати. Вернутись в сіньори можна завжди.

нічого не міняти завжди комфортніше за зміни.
якщо є можливість попробувати ... то треба пробувати

Лежиш собі на дивані — комфортно. Але є можливість спробувати зробити сальтуху ... треба пробувати!
Далі лежиш у гіпсі — вже некомфортно. Але нічого — колись заживе, знову стане комфортно і можна буде ще раз спробувати сальтуху!

Архітектори-продажники — то реалії аутсорса. В продуктах вони інакші ithare.com/...​ive-to-coding-architects

В аутсорс компаніях є замовники продукти, там щось посередині

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

Це так. Я з самого початку кар’єри мріяв бути архітектом. Читав багато книг про архітектуру ентерпрайз систем, як задовольнити різні вимоги, як робити декомпозицію, як закластися на ріст, як роками розвивати і підтримувати усе це.
Коли мені запропонували спробували бути архітектом — виявилось що це взагалі не про код! Робота архітекта то продати клієнту якийсь технічний солюшен на пре-селі. Тобто маючи мінімум інформації що клієнт хоче — вже пропонувати йому якісь рішення!
І уся робота архітекта — це зробити хай-левел презентацію технічного рішення. Якщо клієнт погодиться — на цьому робота архітекта над цим проєктом скінчиться! Архітектурне рішення віддадуть команді проекту — і далі хай пишуть як знають.
Архітекти, як я їх собі уявляв, існують — наприклад у компаніях як MS. Там вони справді вирішують як розбити систему на компоненти, роздати компоненти командам, розтлумачити їм архітектуру і контролювати аби вони її дотримувалися (метрики, статичний код аналіз, періодичні ревью). Але, звичайно, роботу архітекта такі компанії не віддадуть на аутсорс! Аутсорс — мавпочки то нижча ланка, яка підчищає за своїми девелоперами.

Не обязательно MS, в любом продукте или стартапе где есть такая должность архитеетор будет делать именно то что вы ожидаете.

Спасибо за статью.
Но хотел бы добавить, что вилка представленных в статье вариантов ограничена аутсорсом. В реальности выбор шире от СТО и основании своей компании до блогерства и развития личного бренда.

Підписатись на коментарі