Готуємось до майбутнього з Automotive: які навички будуть потрібні розробникам

Привіт! Меня звати Олександр Сивашенко, я Senior Project Manager. Ось уже понад 7 років я працюю у сфері розробки програмного забезпечення для напрямку автомотів, останні 2,5 роки роблю це в компанії GlobalLogic.

Я в дитинстві завжди мріяв отримати супер силу бачити майбутнє. Зараз мені майже 34 рочки — і нічого в цьому напрямі особливо не змінилось.

Знайдіть вільну хвилинку подумати: як це прикольно, мати можливість зазирнути в майбутнє. Коли переможе Україна? Хто виграє Лігу Чемпіонів у 2023 чи навіть у 2025 році?

Або які скіли качати зараз, щоб в майбутньому бути ТОП (цур-цур, не ТОП менеджерами, а мати найбільший попит на ринку і обирати, в який продукт інвестувати свій час).

В цій статті я спробую поділитись виключно своїми думками стосовно трендів, які я зараз бачу у світі розробки програмного забезпечення для Automotive SW development industry і що може змінитись в найближчі 2-5 років.

Що повинен знати Automotive SW developer

Ні для кого не буде новиною, що Автомотів — це частина Embedded світу, в якому розробка ПЗ вже років 20 тісно пов’язана з наступними мовами програмування: С, С++ та Python. Нікого не здивую, якщо скажу, що наступні 10 років воно і далі буде тісно пов’язано з цими мовами.

Варто додати що в останні 10 років з’явилась потреба в знаннях Android, Java і скоріш за все потреба в цих скілах буде зростати, але для Automotive applications (Infotainment) напрямків. Тож, дозволю собі узагальнити і створити універсальний профайл hard та soft skills для Automotive SW developer’a:

практичний досвід з мовами програмування С/С++/Python/Java;
практичний досвід з операційними системами Linux та/або Windows, Android AOSP (QNX — nice to have);
практичний досвід з системами керування версіями: GitHub, Gitlab, etc;
інструменти безперервної інтеграції: Jenkins, etc;
розуміння основ SDLC;
практичний досвід з Agile-методологіями;
English Upper-intermediate;
вміння ефективної комунікації.

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

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

Цей перелік завжди працював і буде працювати для всіх розробок, що пов’язані з hardware (є українські варіанти цього слова — обладнання або «залізо», але я дуже сильно люблю англіцизми).

Технології, потрібні для розвитку Automotive

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

Припустимо, в майбутньому, виробники чіпів та напівпровідників скоротили своє виробництво через брак компонентів в тисячі разів... Ні, давайте навіть реалістичніший кейс: ціна на hardware виросла в десятки або навіть сотні разів... Чи будете ви мати змогу розробляти embedded софт, як і раніше?

Я думаю один embedded device на команду з 30-40 розробників — це те, що може статись з індустрією, зі мною і вами, шановні учасники світу Automotive.

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

Digital twins. Новий аналог Google дає дуже прикольний опис цієї технології, але для тих, в кого «немає часу»: концепція цифрових двійників полягає в створенні віртуальної копії фізичного об’єкта (такого як машини, споруди, процеси або системи) з використанням симуляції даних з сенсорів, аналізу та алгоритмів машинного навчання. Ця віртуальна копія може використовуватися для тестування та оптимізації фізичного об’єкта, передбачення можливих проблем та моделювання різних сценаріїв ©.

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

Тепер розглянемо менший приклад Digital twin’a: у вас є компонент А, який залежить від роботи компонента Б, а саме від сигналів або інформації, яка надходить з компоненту Б в компонент А. І ось ми вже ведемо мову про створення цифрових копій для software та/ або hardware: де це можна було б зробити? Можна спробувати на Python і додати його в CI/CD... А чи можна його перенести в Cloud?

І дуже багато автовиробників вже поставили собі це питання, як результат — ми бачимо концепт під назвою Software Defined Vehicle (SDV).

Останні конференції AWS хостили дуже багато доповідей, які пояснювали ідею концепту і як він працюватиме в майбутньому. Описувати переваги SDV, в цій статті повністю не стану, лише ключові:

зміна архітектур з Доменних на Зональні;
створення СІ-пайплайнів, які будуть давати змогу тестувати патчі з найактуальнішою версію код бейзу залежних компонентів;
легша збірка референс-системи для тестування (все буде в клауді);
виявлення багів на ранніх етапах розробки;
зменшення циклу верифікації і валідації нового функціоналу.

Ще немає жодного реалізованого комерційного проєкту від Автовиробників, але за моїми відчуттями, цей концепт може скоротити час розробки програмного забезпечення для автомобілів десь на 30%. В «грошах» це буде залежати від розмірів проєктів, але це точно від десятків тисяч до сотень мільйонів доларів.

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

Ви скажете: ну, і як це на мене вплине? «Це буде знов „бум“ для DevOps’ів», але хочу нагадати, що всім подобається Agile (я і сам його дуже високо ціную, але він не «лікує всі хвороби»). В Agile є поняття cross functional teams і трактуватись воно може по різному:

наймати команду, яка може виконувати різні типи задач;
наймати людей в команду, які можуть виконувати різні типи задач.

І той, і другий варіант працює в реальному світі, але з’являється проблема, яку дуже не люблять РМ проектів — це bus factor.

Спочатку індустрія вимушена буде (через брак необхідних cross functional людей) керувати bus factor’ом. Але надалі я бачу, що компанії в яких є бюджети на навчання та необхідна експертиза, намагатимуться створювати буткемпи, які будуть поєднувати automotive embedded + cloud і створювати необхідних «універсальних» людей.

Знову ж, це лише суто мої думки, проте я бачу хоч і не велику, але суттєву зміну універсального профайлу Automotive SW developer’a, обов’язково додадуться навички — Сloud expertise: AWS / MS Azure/ GCP (code commit, code built + інші сервіси).

Але найбільша зміна повинна відбутись в нашому усвідомленні, що навіть Automotive SW development вже є можливою в клауді і буде туди «переходити», і що навички девопсів стануть частиною профілю розробника програмного забезпечення.

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

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

Soft skills для майбутнього

Я спробував описати зміни hard-скілів для інженерів, але є ще декілька важливих речей, яких ми повинні навчитись, — це вже з «м’яких» навичок співробітників.

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

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

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

З простих прикладів незрозумілих задач:

Як тестувати інфраструктуру клауда, щоб впевнитись, що ця інфраструктура має такі ж властивості, як локальний білд з підключеним до ноутбука пристроєм?

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

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

"We have learned that...the past will be a poor guide to the future and what we shall forever be dealing with unanticipated events. Given that scenario, organizations... will need individuals who delight in the unknown"© Charles Handy

Теми: кар’єра, прогноз, розробники

Ctrl + Enter

Oleg Yakovlev Embedded C developer в GlobalLogic 30.04.2023 19:13

Автомотів інженери з багатим досвідом на автівках не їздять ))

Відповісти

Підтримати

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 01.05.2023 11:49

Нууу, варто як мінімум почекати до перших оновлень софта і потім можна брати:)

Чи я не правильно зрозумів коментар?)

Oleg Yakovlev

Oleg Yakovlev Embedded C developer в GlobalLogic 01.05.2023 14:16

Те прислів’я я почув від аутомотів інженеріа з багатим досвідом. )) Увесь час цурався як чорт ладана цього напрямку, але так склалося що вимушено таки вступив у це бо, на жаль, не було виходу. Найліпше усе оте описуе оцей пост на редіт www.reddit.com/...s/leq366/comment/gmiq6d0

Oleksandr Syvashenko

Serhii Tyshchenko Embedded Software Engineer 25.04.2023 23:20

в цьому переліку все необхідне є

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

Yuri Zhuravlev Engineering release and integration manager в DXC Luxoft 25.04.2023 19:30

Я в дитинстві завжди мріяв отримати супер силу бачити майбутнє

«А сегодня в завтрашний день не все могут смотреть. Вернее смотреть могут не только лишь все, мало кто может это делать».

))))

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 25.04.2023 19:56

А цитата з того івенту, де ми разом були))

Yuri Zhuravlev

Сергей Слободенюк Senior embedded developer 24.04.2023 21:13

поток сознания...

Curi Ous 27.04.2023 11:41

На мою думку, системи викладання та міркування присутні. Але, з двох компонентів змісту (метод, результат) маємо два фейли. Ваш висновок цілком зрозумілий.

Результат: все теж саме, але більше, важче, різноманітніше — це такий самий фейл, на котрий вказував Форд: «споживачам потрібний кращій кінський возик». Через це пафос: "з дитинства мріяв бачити майбутнє«,- здається якимось зовсім мало вірогідним висловом.

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

Можна було використати простіші та більш результативні методики. Наприклад, проаналізувати чисельні обмеження, їх вплив, та прогнозовану дату події. Як приклад обмежень: кошторис умовної одиниці розробки. Як пише автор, SDV — буде великим трендом. Наслідком буде посилена конкуренція між автовиробниками саме у цій категорії. Кращий софт за ті самі гроші, або краще за менші гроші,- так буде виглядати формула перемоги у конкурентній боротьбі. Тобто, очікуємо підвищений тиск на підрядників та здешевлення розробки. Тобто, висновок автора: «готуйтеся бути універсальними бійцями», то є вологі уяви, чи результат запаморочення. Універсальні бійці дорожчі. Спеціалізовані бійці дешевші індивідуально та загалом. Чітке структурування праці багатьох спеціалізованих фахівців буде завданням ПМ-ів у Автомотів, як це раніше було у інших галузях. Звісно, це додаткове і відповідальне навантаження на ПМ роль. Мотивація автора топити за універсальність робітників та підвищену кількість новичков зрозуміла. Легше структурувати роботи, але платити буде так саме, як при вузькій спеціалізації. То прокате, допоки розробник в Україні обмежений у своїй мобільності. На підводному човні матроси їдять стільки, скільки дозволить капітан. Але автор дає прогноз на 10 років. Навряд війна та закриті кордони будуть триматися так довго.

Сергей Слободенюк

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 27.04.2023 12:19

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

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

Curi Ous

Curi Ous 27.04.2023 14:21

«існуючої експертизи буде не достатньо, потрібно розвиватись разом з трендами»
Згоден. Було б добре, щоб результатом Вашої статті був логично доведений перелік 1) нових знань, 2) перелік знецінених знань, 3) реалістичні варіанти сталих комбінацій різних знань, а не те, як зараз: «все загалом та разом».

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

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 27.04.2023 14:57

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

Стосовно невигідно закликати людей вчитись:
Зростання моїх колег є однією з причин чому я пішов в менеджемент.
В цій логіці може буте багато прогалин і щирої віри в карму))) але, я сподіваюсь що це мій внесок в майбутнє України (крім зборів і донатів на ЗСУ):
1. Створюючи якісний сервіс для Клієнтів, розширювати проект(и)
2. Через розширення проектів, створювати нові можливості для «зірочок» з існуючих проектів (наприклад гарний сіньор з потенціалом перевести на новий проект в новій ролі — тім лід або архітектор, є ризик що не вивезе, але це перевіриться на практиці, і я готовий ризикувати заради них).
3 Після того, як «зіроньки» розвиваються, вони дають приклад усім іншим. Є ті хто захочуть взяти приклад, є ті кого й так все влаштовує.
4. Коли в проектах з’являється можливість: створювати тренінг кемпи і брати трейні в проекти після них.
5. Коли трейні приходить в проект і за 1.5-2 роки стають мідлами, в Україні з’являться ще один представник середнього соціального класу.
Я дуже сподіваюсь, що людина з середнього соціального класу, не буде продавати свій голос на виборах за гречку. Буде розуміти, що Держава повинна контролюватись народом і буде вимагати від Держави руху в напрямку розвитку: зменшення корупції, фокусу на розвиток освіти, медицини і т.д.

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

Як на мене, чим більше буде в Україні класних розробників тим ймовірніше ринок ІТ зміниться з аутсорсу на продуктову розробку.

Ви звертаєтесь до мене, як до Компанї в якій я працюю. Будь ласка, сприймате цю статю не як від SPM GlobalLogic Ukraine, а як статю від людини, що встигла попрацювати в індустрії і поділилась своїми думками

Vitalii Kyrychenko 04.05.2023 15:42

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

Погана якість освіти і негативна демографія — це наступні негативні фактори після сильного відтоку громадян закордон, бо щорічно буде не тільки менше випускатися інженерів, а також якість їхньої освіти буде нижчою ...
Але ІТ-компанії присутні на українському ринку не сидять склавши руки, наприклад, в Intellias розвивається Centers of Excellence для Embedded-розробки (частиною якої є Automotive), тому, як для джуніор-розробника, так і вчорашнього випускника умовних Львівської Політехніки чи КПІ, буде програма професійного розвитку, а також налагоджені процеси менторства та обміну експертизою між спеціалістами компанії.

Vitalii Kyrychenko 04.05.2023 15:28

Як пише автор, SDV — буде великим трендом. Наслідком буде посилена конкуренція між автовиробниками саме у цій категорії. Кращий софт за ті самі гроші, або краще за менші гроші,- так буде виглядати формула перемоги у конкурентній боротьбі. Тобто, очікуємо підвищений тиск на підрядників та здешевлення розробки.

SDV, як частина Connected Vehicle Platform, буде величезним трендом, а не просто великим, і річ не просто в конкуренції між автовиробниками, бо буде рости не тільки технологічність Automotive-домену, а також кількість сервісів, тому 1 автомобіль наступної генерації = 1 акаунт, який буде споживачем підписки від автовиробника на певний функціонал Software Defined Vehicle, а також сервісів та застосунків від 3х сторін.
Можна префразувати слова автора, що Automotive-домен буде великим сегментом для росту компаній провайдерів Сloud-сервісів, а також додати, що в такому випадку виросте затребуваність знань баз даних в Automotive, тому в список узагальнених скілів варто було би включити зання умовного SQL.

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

Це не фантазії, а реальність, бо така тенденція була закладена ще задовго до пандемії COVID-19 і дефіциту чіпів, тобто => коли автоматизація повинна виконуватися меншою кількістю мікроконтролерів, але ці контролери повинні бути більш функціональні, бо різні системи та сервіси ділять ресурси та продуктивність таких мікроконтролерів. В зв’язку з такою архітектурою потрібні розробники із значно ширшою експертизою чим раніше, а для PM викликом є налагодження ефективної взаємодії, наприклад, 50 розробників розділених на N команд і працюючих згідно SAFe-фреймворку при цьому шейрячи ресурси єдиного хардвейр для їхнього софту.

Curi Ous 05.05.2023 19:48

Пане Віталію, у кожного своя реальність. Хтось шукає у минулому, коли дерева були малими, підтвердження своєї величі; хтось шукає, що у майбутньому буде об’єктивною метрикою; хтось запарює читачам локшину, хтось каже потім що я — не я, страва не моя; хтось хоче ширшу експертизу; хтось не хоче платити за зайве; комусь байдуже, бо основа збагачення — фішінг. У цьому ракурсі можна багато припускати, аналізувати, фантазувати. Але центральне питання, який з того сенс? Чого ви прагнете, підтримуючі тенденції до COVID-19 та водночас скаржачись на поганих учнів?

Vitalii Kyrychenko

Vitalii Kyrychenko 06.05.2023 15:28

Пане Віталію, у кожного своя реальність. Хтось шукає у минулому, коли дерева були малими, підтвердження своєї величі; хтось шукає, що у майбутньому буде об’єктивною метрикою; хтось запарює читачам локшину, хтось каже потім що я — не я, страва не моя; хтось хоче ширшу експертизу; хтось не хоче платити за зайве; комусь байдуже, бо основа збагачення — фішінг.

А хтось шукає скрізь зраду ...

У цьому ракурсі можна багато припускати, аналізувати, фантазувати. Але центральне питання, який з того сенс? Чого ви прагнете, підтримуючі тенденції до COVID-19 та водночас скаржачись на поганих учнів?

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

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

Також від вас було необгрунтоване заперечення стосовно майбутньої необхідності спеціалістів із широкою експертизою (як автор назвав їх — «універсальних людей»), будучи послідовним, ви також мали б критикувати поточну необхідність в fullstack-розробниках в веб/мобал доменах ...
Часи кріпацтва давно минули, спеціаліст сам обирає на яку позицію претендує і які скіли йому необхідно для цього розвивати, тому якщо будуть затребувані розробники з широкою експертизою, будуть і відповідні кандидати.

Стосовно незацікавленням аутсорсних компаній в навчанні спеціалістів ви також озвучили помилкове допущення порівнюючи із кредитуванням освіти в західних країнах, бо великі ІТ-компанії недарма мають інтернатуру та програми розвитку для спеціалістів, в багатьох випадках це відіграє навіть більшу роль чим наявна вища освіта у спеціаліста. Також, наприклад, компанія GlobalLogic зацікавлена зберігати своїх спеціалістів в Україні (і в іхній розвиток вона вже вклалася), перечекавши нинішні складні часи, за останній рік мали складнощі з новими контрактами для українських офісів, шукали спеціалістів в Польщі і Румунії на Ембедед/Автомотів проекти, але в Hitachi, як власники компанії, вирішили вантажити українських спеціалістів своїми проектами, тобто взяли ризик на певний відрізок часу на себе замість «викинути на мороз» із бенча, як зробили в деяких інших компанія.

Чітке структурування праці багатьох спеціалізованих фахівців буде завданням ПМ-ів у Автомотів, як це раніше було у інших галузях.
...
Але автор дає прогноз на 10 років. Навряд війна та закриті кордони будуть триматися так довго.

Важливо не узагальнювати, як зробив автор, але мислити містечково — це також помилково.
Структурування в Автомотів присутнє, і з подальшим розвитком буде збільшуватися технологічність цього домену, відповідно будуть з’являтися нові фреймворки та стандарти, але нині все на своєму місці => є проекти з необхідністю реалілізації згідно Waterfall фреймворку типу V-Model і дотримуватися вимог стандартів, а є проекти із простором для Agile фреймворків (адаптивної методології розробки).
На таку довгу перспективу можна загадувати скільки взагалі буде доступних спеціалістів для ІТ на території України, чи обрікати галузь, як ви зробили в своїх висновках, автора ж можна похвалити за агітацію => розпочинати свій трудовий шлях саме в Автомотів-домені, або світчитися в нього із інших, це дуже переспективний напрямок і важливо щоб українці могли себе проявити в ньому якомога краще.

Curi Ous 07.05.2023 22:45

Дяка. Виявлено ГЛ агітацію. Доречи, головна теза: "дуже перспективно розпочинати чи світчитися",- не доведена. Більше схоже на лозунги. Хапаємо з контексту ті данні, що засвідчують нашу точку зору, дискредитуємо все інше.

Наприклад, ви не збагнули, що так, як до ковіду, вже не буде. Ті тренди несумісні з сучасними трендами, які ви самі свідчите. Можна доковідні часи вже не згадувати. А от з погіршенням підготовки фахівців треба щось робити. Якби ви були системо мислячими співрозмовниками, що пишуть з позиції сталої інституції, то запропонували би сумісні з можливостями кар’єрні шляхи на кшталт: до дупи те навчання та набор фахових навичок, ми розуміємо, що нема ні часу, ні грошей; йдіть до нас, у корпоративному центрі навчання все навчимо. Але агітатори ГЛ пропонують/вимагають протилежне. Люди вам так прямо й пишуть, що окрім байдужості та відвертого несприйняття таке маніпулювання нічого не викликає.

Щодо зради, то так. На даний час ІТ фахівці можуть насолоджуватись ліпшим фінансовим відшкодуванням праці. Це здобуття попередніх поколінь. У галузь йшли розумніші. Розум у сполученні з техничною можливістю демонструвати порівняно вищу продуктивність праці створили церебральне решето. Вміння дотримуватися принципів раціональності є чіткою особливістю навиків пересічного айтівця. Недолугість, одновекторність поглядів та міркувань не втримується. Але примитивна агітація — то апелювання до аудиторії, що не відповідає таким вимогам. Фокусування та найм таких робітників — це шлях до знецінення праці кожного з нас. Так, це вас теж стосується, паре Головний Фахівець.

Vitalii Kyrychenko 08.05.2023 15:10

Виявлено ГЛ агітацію. Доречи, головна теза: "дуже перспективно розпочинати чи світчитися«,- не доведена.

ok, шлях в Автомотів можна розпочинати на меншій компенсації в продакті — Infineon Technologies в Львові чи Delfast в Києві, а потім за різноманітнішим досвідом і більшими фінансовими можливостями йти в GlobalLogic/Luxoft/Intellias; не подобається аутсорс, то прагнути влаштуватися в київський офіс Nvidia (де крім передових рішень для Автомотів також може бути привабливим ML та майнери); з українського PocketBook (передового світового виробника е-читалок) при інтересі можна світчнутися в Автомотів, ... і можете вважати всі перераховані компанії агітацією, я нічого жахливого в цьому не бачу :)) це чудові опції для ембедед-розробників працевлаштовуватися на українському ІТ-ринку, а у вас якісь ліві таргани завелися, наче такі компанії є жахливими капіталістичними експлуататорами.

Наприклад, ви не збагнули, що так, як до ковіду, вже не буде. Ті тренди несумісні з сучасними трендами, які ви самі свідчите. Можна доковідні часи вже не згадувати.

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

А от з погіршенням підготовки фахівців треба щось робити. Якби ви були системо мислячими співрозмовниками, що пишуть з позиції сталої інституції, то запропонували би сумісні з можливостями кар’єрні шляхи на кшталт: до дупи те навчання та набор фахових навичок, ми розуміємо, що нема ні часу, ні грошей; йдіть до нас, у корпоративному центрі навчання все навчимо. Але агітатори ГЛ пропонують/вимагають протилежне.

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

Щодо зради, то так. На даний час ІТ фахівці можуть насолоджуватись ліпшим фінансовим відшкодуванням праці. Це здобуття попередніх поколінь. У галузь йшли розумніші. Розум у сполученні з техничною можливістю демонструвати порівняно вищу продуктивність праці створили церебральне решето. Вміння дотримуватися принципів раціональності є чіткою особливістю навиків пересічного айтівця. Недолугість, одновекторність поглядів та міркувань не втримується. Але примитивна агітація — то апелювання до аудиторії, що не відповідає таким вимогам. Фокусування та найм таких робітників — це шлях до знецінення праці кожного з нас.

Напевно, ви були б добрим головою профспілки десь у Франції, володієте дуже потужними тирадами.
С/С++ розробники в Ембедед/Автомотів повинні мати більше фундаментальних знань чим розробники у Веб/Мобайл/Ентерпрайз доменах, також згідно останньої статистики djinni найбільше часу займає найм саме С/С++ розробників, але розмір їхньої компенсації значно нижчий, наприклад, чим в Java-розробників, такі реалії ринку, ... напевно, ці люди переважно обрали такий стек технологій із-за інтересу до певного домену, а не в гонитві за більшим доходом, вірно?

Так, це вас теж стосується, паре Головний Фахівець.

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

Serhii Tyshchenko Embedded Software Engineer 11.05.2023 14:27

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

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

Vitalii Kyrychenko 12.05.2023 16:09

Моє заперечення стосувалося коментарів Константина стосовно вимог широкої експертизи і розміру компенсації ...

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

Якщо в автора статті була цільова аудиторія — майбутні джуніори чи світчери для верхньорівневих систем в Автомотів, то річ повинна бути не просто про бекграунд, а також про інтерес до домену, ... наприклад, якщо дану ситуацію розглядати на ринку США, то в Тесла зарплати суттєво нижчі чим в інших ТОПових технологічних компаніях, але поріг входу вищий і працювати треба продуктивніше, тобто повинна бути певна ідейність щоб працювати в такому домені порівнюючи із відносно тепличними умовами десь у «формошльопанні».

Serhii Tyshchenko

Victor Kremin Senior Principal Engineer в Infineon Technologies 24.04.2023 20:36

Як на мене, не вказано в статті самого головного — розуміння процесів розробки, тестування та сертифікації SW для Automotive — ASPICE, AutoSAR, ISO 26262, IATF 16949, Function Safety

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 24.04.2023 20:49

Хм, ну не зовсім... Я писав, що важливими складовими є:

розуміння взаємозв’язків вимог-архітектури-коду-тест сценаріїв-тест кейсів

ASPICE — він поєднує не лише engineering аспекти. Наприклад MAN.3 або SUP.8 — девелоперам їх знати не обов’язково. Добре якщо знають, але відверто скажу — не всі РМи в автомотів знають, що це таке.

AutoSAR — специфічний стандарт, людям які розроблять applications, точно не потрібен.

ISO 26262 (він же Functional safety) — якшо ASIL D, то вимоги для виконання контролів повинні бути прописані в вимогах до функціоналу, що для розробника є керівництвом для дії під час розробки софта.

IATF 16949 : 2016 (до Вашого коментаря, не знайомий мені стандарт :)) - це для проведення аудитів, що теж для розробників не найкритичніша навичка.

Але знову ж, це лише моє субєктивне бачення. Скільки людей — стільки й думок.
Дякую.

Victor Kremin

Євген Лесько Competency manager в ELEKS 25.04.2023 11:59

Та да, Ви кажете шо не потрібен і не обов’язково, а замовник починає розмову не з С++ і Пайтона, а з того скільки людей мають досвід ASPICE, AutoSAR і сертифікати ISO 26262. Більше того, спостерігаю шо і девелопери з такими навичками далеко від Automotive йти не бажають.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 25.04.2023 12:33

В пресейлах в мене більше трьох років досвіду.

Клієнт зацікавлений в наявній експертизі і практичному досвіді для вирішення його конкретної задачі на певний момент часу. Основний ризик для клієнта, не отримати результат за витрачені грощі, і якщо у Вас з клієнтом ще нема успішного досвіду, вони будуть спиратись на сертифікати. ASPICE, ISO 26262 — можна реалізовувати з нуля, при наявності 1-2 експертів, які зможуть допомогти створити процеси і відповідно навчити людей.

Якщо у Вас клієнт вимагає, щоб 80% людей мали практичний досвід з ISO 26262, значить він не розуміє, як будувати процесс девелопменту і сподівається, що ви його «врятуєте». І тут залежить від пресейл команди, правильно пояснити оферінг Клієнту, щоб впевнити його, що: "ми можемо це зробити для Вас вчасно і з відповідним рівнем якості"...але зазвичай, це буде не дешево.

Якщо Вам погодять такий проект, то відсотків 99%, що ви не будете наймати людей з такими скілами (бо ви не встигните зробити проект або буде погана маржинальність), а ви будете наймати С++ розробників і вчити їх.
Я намагаюсь донести, що в подальшому нам і далі потрібні будуть базовий стек навичок:

практичний досвід з мовами програмування С/С++/Python/Java;
практичний досвід з операційними системами Linux та/або Windows, Android AOSP (QNX — nice to have);
практичний досвід з системами керування версіями: GitHub, Gitlab, etc;
інструменти безперервної інтеграції: Jenkins, etc;
розуміння основ SDLC;
практичний досвід з Agile-методологіями;
English Upper-intermediate;
вміння ефективної комунікації.

і в майбутньому до нього додасться:

Сloud expertise: AWS / MS Azure/ GCP (code commit, code built + інші сервіси)

Стосовно, AutoSAR. Я керую програмою з більше ніж 100+ людей. 30% людей в моїх командах знають AutoSAR, тому що перед ними стоїть задача створити функціонал, який спирається на AutoSAR стандарт, 70% створюють інші компоненти і для цього їм немає необхідності знати цей стандарт.
Тому, я його і не вніс в мінімальний базовий перелік навичок.

Євген Лесько

Denis Suprunenko Працює в CHIPSOFT 25.04.2023 13:39

Свого часу подавав своє резюме на аутомотів вакансії у декілька німецьких компаній які займаються виключно цією тематикою. Сам я маю великий досвід у embedded розробці у тому числі і около аутомотів, але без знання AutoSAR, ISO 26262. Ситуація така, що якщо рекрутер на телефонному інтерв’ю не почує ключеві слова AutoSAR, ISO 26262 то далі телефонного інтерв’ю діло не піде.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 25.04.2023 13:52

Дякую за кейс.
Денисе, дивіться, якщо шукають в вакансії людину для роботи з AutoSAR, то без такого досвіду не будуть навіть дивитись.
ISO 26262: навіть проходження сертифікації, не дасть Вам чіткого розуміння, які контролі потрібно додавати в функціонал продукту, що забезпечити відповідність вимог. Ці знання можна набути лише маючи практичний досвід з Functional Safety.

Automotive зараз сильно змінився і продовжує змінюватись, відповідно і необхідні навички будуть змінюватись. Раніше AutoSAR був обов’язковим, зараз вже ні.

Denis Suprunenko

Прамамбукан Шричинмой 25.04.2023 14:44

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

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 25.04.2023 15:16

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

Ви зачепили набагто складнішу проблему, яку не приємно визнавати, але це так: Україна — ресурсна база. Нещодавно, на ДОУ була стаття про кризу ІТ аутсорсу в Україні — сподіваюсь, що в Україні з’явиться більше продуктових компаній, які прозвучать на весь Світ, як Ajax наприклад.

Прамамбукан Шричинмой

Victor Kremin Senior Principal Engineer в Infineon Technologies 25.04.2023 13:49

А продукти які розробляються в межах вашої програми сертифікуються в кінцевому випадку згідно з якими стандартами?

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 25.04.2023 14:01

В мене різні, від QM до ASIL D
Відповідно, деякі можна буде закрити ISO 9001, а для деяких потрібен буде незалежний аудиту по ISO26262.

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

Євген Лесько Competency manager в ELEKS 25.04.2023 17:29

Ви все правильно доносите, за невеликим ньюансом...

Я керую програмою з більше ніж 100+ людей. 30% людей в моїх командах знають AutoSAR, тому що перед ними стоїть задача створити функціонал, який спирається на AutoSAR стандарт, 70% створюють інші компоненти

Дурне питання — а перед ними не стоїть і ніколи не буде стояти задача замінити когось з тих 30%, які захворіли, пішли у відпустку, звільнились і т.ін.? Прямим текстом — ви не стимулюєте їх до засвоєння відповідних стандартів якщо вони вже працюють в Automotive ? Но це мале пИво...

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

Ну да, саме так! В тімі, який три роки працює, ви маєте 30% «експертів по сертифікатам»; в тімі який щойно формується, замовник хоче 65-80% сіньорів, і жеби всі вони володіли сертифікатами... з тим, аби пізніше піднятись (чи у відсотках — спуститись :) ) до Вашого рівня. Ви статтю написали вродє як з т.з. входження в Automotive (принаймні я так зрозумів), але зараз мова йде про усталений проект якому декілька років :(

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 25.04.2023 17:39

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

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

Можливо зміна фін моделі проектів з T&M на Fixed price, але обов’язково з discovery stage на основі T&M контракту, якщо це абсолютно не знайомий Клієнт.

Vitalii Kyrychenko 26.04.2023 15:39

У вас були проекти із високим класом наслідків, коли потрібен ваш підпис, а також підписи представників комад розробки та тестування, коли при певних критичних помилках на проекті можлива кримінальна відповідальність?

Клієнта і успішної історії

Як було з успішними історіями і довірою до «ефективних рішень» менеджерів VW у випадку дизельгейту? Чи наскільки надійними виявилися аутсорсери в Boeing, коли із-за неякісного тестування запороли Boeing 737 MAX, а з ним колосальні збитки і удар по репутації компанії?

П.С. пардоньте за провокативність таких запитань, але прочитавши ваші каменти, в мене склалося враження про ваше досить зневажливе ставлення до вимог норм та стандартів в Automotive.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 26.04.2023 17:44

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

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

Віталій, дуже прикольно маніпулюєте інформацією: «клієнт і успішної історії» — це стосувалось відносин для пресейлу. Як це пов’язано з кейсам VW та Boeing?

До стандартів, я ставлюсь з повагою, але не через лейбочки ISO, а через реальні процеси сфокусовані на якість продукту. ASPICE та ISO 26262, з явним фокусом на саме якість, але прочитані стандарти або пройдені сертифікації — не дадуть стільки розуміння, скільки прожитий проект по цих стандартах.
Якщо що, в мене є досвід з асесментом по ASPICE на lvl 2 — і в цьому проекті було багато про якість софта.
Але для прикладу, я ще сертифіковував проекти по ISO9001 та організації по ISO 27001 — і в цих стандартах дуже багато маркетингу.

Vitalii Kyrychenko 26.04.2023 21:51

Як це пов’язано з кейсам VW та Boeing?

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

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

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 26.04.2023 22:45

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

І все ж таки це маніпуляція, бо вирване зовсім з контексту пресейлів.

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

Я вражений, що ви не маючи повного розуміння про мій досвід намагаєтесь його оцінити :)

Якщо зараз додати в вимоги до людей в існуючих автомотів проектах, обов’язково мати розумінням (читайте практичний досвід або сертифікація) стандартів ISO 26262 або ASPICE — 50-60% людей працюючих в цій сфері будуть не викноувати мінімальні вимоги. Подобається ця реальність чи не подобається — це реальність. Тому, я і не вважаю за доцільне, додання цих знань, як необхідні.
Моя мета — зацікавити в Автомотіві, а не відлякати від нього:)

Чим більше людей буде працювати в цій сфері, тим краще буде позиціонування експертизи України на Світовому ринку. As simple as that ©

Vitalii Kyrychenko 26.04.2023 23:43

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

Так, я не маю повного розуміння про ваш досвід, але ж і ви не будете стверджувати про вашу абсолютну експертизу в Automotive SW девелопменті, правильно?

А процитоване вище, аж дивно читати, бо з таким ставленням — це скоріше у веб/мобайл домени, де практикують «*уяк-*уяк, і в продакшн», ... хоча, якщо таке практикувати в Automotive, а потім проблеми будуть у верхньорівневих рішень типу роботи мультимедійної системи, виводу навігації та ін. — це ще якось, але для розробки нижньорівневого ПЗ таке ставлення недопустиме.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 27.04.2023 00:22

Віталій, бізнес ніколи не буде мати ідеального змісту та форми.
Це, доречі, був найболючіший момент переходу від РМа до SPMа.

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

І більшість проектів Автомотів високої якості, але забезпечується якість не через людей, а через процеси.
Як я зрозумів увесь цей діалог з Вами: обов’язково в проектах щоб усі люди були з сертифікатами:)

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

Мій перелік навичок сформований, не для команд які вже з досвідом і можуть енейблити нові проекти, а для тих хто хочуть ввійти в Automotive SW development. Ми можемо продовжувати з Вами обмінюватись думками, але це вже не ДОУ, а якісь фейсбучні срачі :)
Якщо зручно, в мене є пост для цього в ФБ, можемо там продовжити.

Vitalii Kyrychenko 27.04.2023 17:28

Будучи перфекціоністом, я не претендую, що в моїх проектах завжди все було ідеально з технічної сторони, але були обгрунтовані компроміси та червоні лінії, які не можна було перетинати. Аргументуючи, ви робите акцент на вашому досвіді в пресейлі, так от, за мої 12 років в пресейлі на Embedded та ICS проектах вимоги стандартів тільки збільшувалися, і хоча маючи досить обмежене розуміння перспектив Automotive, я не згоден з «рожевим» Agile узагальненям для цього домену.

гарні процеси

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

П.С. за запрошення в ФБ дякую, але воно нерелевантне, активність на жодній із платформ компанії Meta мені нецікава.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 27.04.2023 17:32

гарні процеси будують команди разом з експертними людьми (тут і process engineers і люди з команди, в кого був досвід з «правильними» процесами)

знайдіть ключе слово в цій цитаті)

Vitalii Kyrychenko 28.04.2023 13:29

ніякого «ключе слово», просто словоблудство із «гарні процеси», ... і Senior Project Manager не личить бла-бла, потрібно бути конкретним і компетентним у своїх визнанченнях

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 28.04.2023 15:12

Ключове слово «команда». :)

Vitalii Kyrychenko 28.04.2023 15:50

ок, 5/5 вам по флуду

Vitalii Kyrychenko 24.04.2023 19:07

Якесь занадто вузьке і нечітке майбутнє описане для Automotive.
В універсальний профайл SW developer потрібно було включити знання цифрової схемотехніки, бо базові скіли в Automotive-домені стосуються Embedded-розробки ПЗ нижнього рівня.
Стосовно верхнього рівня і Сloud-сервісів, то коректніше було розглядати не Software Defined Vehicle, а Connected Vehicle Platform.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 24.04.2023 19:20

«Менеджерський» опис)))
Я додав скіли людей, яких я наймав в свої проєкти і вони ставали «зіроньками». В багатьох з них не було скілів з схемотехніки, але це назавадило їм ставати гарними розробниками.

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

Стосовно, Connected Vehicle — це велика частина Automotive SW, в одній статті її не покрити. Але в цілому з Вами важко не погодитись, майбутнє автомотіва не достатньо чітке і все ж таки дуже цікаве.

Vitalii Kyrychenko 25.04.2023 23:51

«Менеджерський» опис)))

Це ставить все на свої місця, треба тоді ще списки від архітекта, ліда чи Senior Embedded Software Engineer :)

Стосовно «зіроньок», то річ же про роки ринку кандидатів, правильно? Але коли брали «кандидата на виріст», то спрацював комплекс причин успіху => від початкових старань рекрутера та кваліфікованої оцінки від трастед інтерв’ювера на технічному інтерв’ю ... до добре поставленого менторства в конкретній команді.

Крім знання схемотехніки, в список також можна було би ще додати: 1) базове розуміння Automotive virtualization; 2) знання C# (Windows не дарма у вас в списку, багато прикладного ПЗ в Automotive пишеться під дану ОС саме на цій мові).

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 26.04.2023 09:41

«Зіроньки» — це люли, які після онбоардінгу ставали основними драйверами результатів команди)
Про віртуалізацію — погоджуюсь, про С# - десь воно дуже дуже потрібно, а десь і не зовсім. В цілому я намагався створити узагальнюючий перелік навичок на основі вакансій, що я створював за час роботи.

Стосовно переліків скілів від архітектора і сіньойра... це потім потрібно ще змапити з ринком))

Vitalii Kyrychenko 26.04.2023 15:27

«Зіроньки»

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

ok, а як змагаєтеся з ринком, коли пишете вимоги для PM, наприклад, коли дуже довго не можете знайти PM з machine learning experience? Або коли у вимозі вакансії => розуміння/досвід CI/CD, Gitflow та ін., кандидат налаштований на обговрення даних тем і розуміє, що це практично базові вимоги для PM в даному домені, але Senior PM з Embedded департаменту GL на інтерв’ю каже, що він таким не зоморочується, бо для своєї зручності з обліком виконавців, версій та статусів просто навантажує девелоперів заповнювати Exel-таблички?

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 26.04.2023 17:53

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

розуміння/досвід CI/CD, Gitflow

Але Senior PM, питав по операційному менеджменту, тому що SPM не фокусуєтсья на технічних складонстях проекту. Я правильно зрозумів Ваш коментарій?

Vitalii Kyrychenko 26.04.2023 21:47

Зрозуміли неправильно. Я навів 2 різні випадки: 1) перший, коли до високодосвідченого РМ є високі вимоги до технічних скілів, таких релевантних кандидатів одиниці на ринку, тому обгрунтовано шукати такого «рокстар РМ» чи може фінансово доцільніше по іншому розподілити повноваження тімліда та РМ? 2) другий, коли по суті вимоги завищенні і вилка зп для вакансії також висока із-за таких вимог, хоча якщо SPM самостійно не може повноцінно провести інтерв’ю, то повинен був мати напарника з фокусом на інжиніринг, правильно? також це приклад необгрунтовано «щедрого ринку» від працедавця?

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 26.04.2023 22:29

Пробачте, щось я не розумію.
Починали з навичок для інженерів, потім РМів, зараз SPM які неможуть провести інтервью.
Можете детальніше розтлумачити «необгрунтовано „щедрий ринок“ від працедавця».

Сорі, реально важко відслідкувати про що ми зараз ведем мову.

Vitalii Kyrychenko 26.04.2023 23:28

Нуу, пояснюю, якщо аж так ...
Почали з інженерів, тому, що я пропонував додаткові пункти до «універсальний профайл hard та soft skills для Automotive SW developer», ... але скоріше помилково про такий профайл говорити загалом для Automotive SW девелопменту, наприклад, ситуація різна в львівського офісу Infineon Technologies та київського GlobalLogic, починаючи від специфіки проектів і стеку технологій, закінчуючи відсутності в продуктової компанії наведених вами нюансів відносин із клієнтом.
На ПМів перевів, як приклад погано обгрунтованих вимог і в підсумку більшою складністю пошуку кандидатів, а також роздутих оверхед витрат на проекті, хоча ви намагаєтеся максимально мінімізувати розлядаючи вимоги до ресурсів.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 26.04.2023 23:39

Дякую, тепер зрозуміло.

Створити складне (детальний опис вакансії під ваші потреби) легше, ніж зробити просте (перелік мінімальних вимог для входу в індустрію).
Я намагався створити останє, то що з запропонованих мною навичок немає в працівників львівського офісу Infineon Technologies.
Ось перелік:

Зроблю припущення, що Ваші вимоги до кандидатів вищі ніж наведений мною перелік, але я чомусь впевнений, що коли ви знайдете 90% матч скілів кандидата з моїм переліком, відчуєте що в кандидата гарний потенціал, ви його будете наймати навіть без знань стандартів, бо «правилам» розробки в Вашому проекті ви його навчите за період випробувального терміну.

Але, я в Києві, можу мати інше бачення в порівнянні з тим, як наймають у Львові. Відрізнятись — це нормально :)

Vitalii Kyrychenko 27.04.2023 17:12

Соррі, але в статті ви давали узагальнений список вимог, тому від коментаторів пішли пропозиції додаткових скілів, які є базовими для домену, інша річ, якщо б ви початково позиціонували список як «перелік мінімальних вимог для входу в індустрію».
І навіть не додаючи чогось додаткового, можна також сперечатися з озвученим вами, наприклад, в мене нерозуміння, чому ви об’єднали «Android AOSP (QNX — nice to have)», хоча це різні типи OS і RTOS QNX має базове значення в Automotive в порівнянні із верхньорівневими рішеннями на AOSP, ... також «практичний досвід з Agile-методологіями» є спірним, бо по-перше — девелопер може швидко адаптуватися до конкретного фреймворка, що викоритовується у вас на проекті, по друге — велика частина проектів в Automotive розробляються по Waterfall методології.
І, так, в моєму випадку була інша ситуація з вимогами до кандидатів, тому був кращий електронщик за освітою, що навчився програмувати чим просто програміст за освітою, але «на ти» із системним дизайном і може розібратися із інформацію в datasheet, ... наприклад, порівнюючи з базовими вимогами в компанія Infineon, Squad і Ajax, то моя ситауція досить релевантна.
Стосовно «будете наймати навіть без знань стандартів», згоден у випадку з джуном, але це річ про особливості подальшого менторінгу, код рев’ю та тестування на проекті, бо як мінімум в одній із програм такому розробнику потрібно стартувати на проектах із високим класом наслідків, коли після критичного інциденту згідно логу буде як випадку «чорної скриньки», тобто => хто (чи що) винуватий і кому може світити кримінальна відповідальність.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 27.04.2023 17:26

Погоджуйюсь, більш корректно було б написати:
required: Linux та/або Windows
nice to have: Android AOSP, QNX, etc.

Розуміння Agile: бо це про майндсет більше) сподіваюсь зрозумієте

Vitalii Kyrychenko 28.04.2023 13:34

Якщо ви цінуєте «гарні процеси» на ваших проектах, то «Agile-майндсет» наступний згідно п.1 маніфесту => «Individuals and interactions over processes and tools», як думаєте, наскільки це підходить до пересічного Automotive-проекту?

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 28.04.2023 15:14

Якщо ви не вмієте це поєднати) рекомендую SAFE Agilist курси) вчитись, потрібно постійно)

Vitalii Kyrychenko 28.04.2023 15:49

Я вам завдав чітке запитання, відповідати на яке ви уникнули.

Але, що це було і нахіба такі допущення?
Що з чим я не вмію поєднувати? З чого ви взяли, що порада SAFE Agilist курсів мені потрібна?

П.С. ведіть себе коректно, а не як в ФБ чи на «базарі»

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 28.04.2023 15:51

Бо може, це допоможе змінит статус «Open to work» :)

Я гарно вчуся) у Вас я навчився перекручувати інформацію.

Vitalii Kyrychenko 28.04.2023 16:11

Я вас не просив давати нерелевантні поради для мого працевлаштування. Тримайте себе в руках, або на ФБ з подібними коментарями.

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 28.04.2023 16:29

Отримати нові знання, щоб збільшити свою цінність на ринку — це нерелевантна порада. Пробачте, більше не буду.

Vitalii Kyrychenko 28.04.2023 16:49

Отримати нові знання, щоб збільшити свою цінність на ринку

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

Oleksandr Syvashenko Senior Project Manager в GlobalLogic 28.04.2023 16:57

Ось ми і прийшли, до того що не кожному потрібні сертифікати :) Дякую, отримав задоволення від спілкування))

Vitalii Kyrychenko 28.04.2023 17:14

Соррі, але у вас не було зі мною дискусії стосовно необхідності сертифікату для кожного чи якомусь відсотку спеціалістів, ви щось наплутали.
Смачного!🤦🏻‍♂️

Готуємось до майбутнього з Automotive: які навички будуть потрібні розробникам

Що повинен знати Automotive SW developer

Технології, потрібні для розвитку Automotive

Soft skills для майбутнього

63 коментарі

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