Перш ніж розпочинати навчання, варто зрозуміти, чого саме хочеш досягти. Якщо робота в ІТ, то що саме це має бути: тут можна нарахувати десятки, якщо не сотні напрямків. Часто новачок боїться озвучити ціль, бо коли вона стає конкретною, є ризик, що не дійдеш до неї.
Один зі знайомих, який думає про перехід із бренд-менеджменту, досі не може зрозуміти, що йому цікавіше: маркетинг чи аналітика. Розвиватися в обох сферах важко, оскільки кожна вимагає багато часу для освоєння і має свої інструменти.
Ставлячи мету перед звільненням з попередньої роботи, я ставив чотири питання:
Одне з того, що допомагало протягом світчингу, — трекер часу. Цей інструмент поки що мої знайомі ігнорують, але я впевнений у його ефективності. Не вимірюючи навчальний час, не бачиш скільки вклався у нього за день, тиждень, місяць. Для мене ідеальним варіантом став Toggle Tracker, його безкоштовної версії вистачає для усіх потреб.
«1000 годин для навчання» для мене звучить гарно й амбітно. Хоч це й нагадує «правило 10 000 годин Градуела», але ідеться трішки про інше. За 1000 годин ти здобудеш навички, необхідні для початкового рівня. Але це повинна бути цілеспрямована робота над собою.
До війни я розглядав два підходи світчингу: поступовий і радикальний. Ці форми актуальні і нині.
Якщо нині все ж є змога обирати, то радив би почати з поступового шляху: щодня приділяти хоча б годинку, щоб вчити основи в обраній тобою сфері. Якщо захопить, то можна і довше.
Я обрав напрямком роботу з даними, вивчав ази Python, читав Kaggle та дивився влоги людей, які вже працювали в аналітиці та Data Science. І готував себе до радикального шляху.
Декого з моїх знайомих стримує той факт, що нинішня робота все ще приносить більше, ніж посада новачка. Тут немає правильних рішень: або погоджуєшся на менше і з часом компенсуєш втрачене зростанням оплати, або ж лишаєшся на стабільній (поки що) попередній роботі. Але як побачили за останні три місяці — ця стабільність може бути дуже хиткою.
Після розуміння цілей та часу на навчання, визнач, що саме збираєшся вчити. І для себе, і для знайомих я використовую такий алгоритм:
Особисто моїм топом в аналізі даних став курс з Python на 4 місяці від Beetroot Academy, який розбавляв SQL, Power BI, Tableau, статистикою, практичною роботою з даними, англійською та активністю з пошуку роботи.
Це питання залежить від того шляху, який обираєш. Якщо світчитися поступово, то варіантів три: ранок, вечір, ранок + вечір. Все залежить від біоритмів та хобі. Мені складно вчитися зранку у будні, але набагато легше ввечері після пробіжки. Комусь — навпаки.
У випадку радикального шляху, можна вчитися, коли завгодно. Але все ж раджу використовувати час з 9 до 18, щоб все-таки був певний режим. Під час свого «добровільного безробіття» практикував спільні виходи з дружиною з дому: вона йшла на роботу, а я повертався додому за 10-15 хвилин, ніби на власний офіс.
Раджу пам’ятати про так званий снек-час. Тобто проміжки у 10-15 хвилин, які можна використати, щоб засвоїти щось нове. Наприклад, у черзі чи в транспорті. Якщо повітряна тривога зустрічає мене не вдома, то маю з собою додаток Udemy, й у сховищі дивлюся актуальний курс.
Звісно, код на телефоні писати складно, але послухати тему зі статистики чи теорії ймовірності цілком можливо.
У перші тижні війни мені, як і багатьом знайомим, було складно сконцентруватися на роботі, не кажучи про навчання. Але поступово цей ресурс вдалося відвоювати у ресурсів з новинами.
Останні кілька років мені допомагає система Pomodoro: розподіляєш роботу у відрізки по 25 хв і потім 5 хв відпочиваєш. Це зручно у роботі з digital, коли маєш багато коротких задач.
Але у випадку дата-аналітики, особливо там, де йде робота з кодом, цей підхід не працював: пів години — надто мало для того, щоб в’їхати у задачу і придумати хороше рішення. Тому підхід, який працює для мене останній рік — 50/10: 50 хвилин сконцентрованого навчання чи роботи та 10 хвилин відпочинку. Разом це — година, щоб допомагає зручно моніторити, якщо починати цикл на початку години.
У ці 10 хвилин варто розвантажити голову і попрацювати руками: застелити ліжко, помити посуд, прибрати за котом. Соцмережі та новини теж стараюся дивитися тільки у цей проміжок. Хоча і розумію, що розфокусуватися це не дуже допомагає.
Друк наосліп — навичка, яка дуже допомагає, незалежно від майбутньої спеціалізації в ІТ. Це стосується і української, а особливо англійської, на якій писатимете код.
Як би важко це не було на початку, згодом зекономить час, коли повторюватимете код за лектором. До того ж це може бути маленькою перемогою під час довгої дороги до світчингу.
Чим краще ти залучиш себе до навчання — тим більше шансів, що все закінчиться позитивно. Мої підходи:
Журналіст Малкольм Гладуел у книзі «Неординарні» розповів про «правило 10 000 годин». Якщо коротко: потрібно витратити стільки часу, щоб стати експертом міжнародного класу.
Та тут є хитрість. Потрібно вдосконалювати себе саме там, де є складнощі, а не просто постійно робити одне й те ж в надії, що це покращує навички. Наприклад, вивчивши базу SQL, варто розбиратися зі складнішими темами, типу процедур та віконних функцій, а не перепроходити цю базу на іншому курсі.
Варто пам’ятати про криву складності: матеріал треба підбирати так, щоб він був на межі поточних можливостей. Якщо освоюватимеш табличку множення у 31 рік — буде нудно. Якщо ж перемножуватимете матриці вперше за 10 років — занадто складно. Шукай середину.
Найкраща можливість перевірити знання — співбесіди. Оскільки може бути пастка нескінченності курсів, як це трапилося з моїм знайомим фронт-ендером. Йому здається, що він ще недостатньо знає для пошуку роботи. Цій неготовності уже більш як десять місяців.
Співбесіди — це стресова перевірка, але вона потрібна, щоб побачити слабкі сторони. Розумію, зараз дійти до співбесіди початківцю стало складніше, але все ж треба пробувати.
Після кожного технічного інтерв’ю раджу виписувати те, на чому були складнощі і детальніше це пропрацьовувати. Після кількох таких ітерацій набагато впевненіше себе почуватимеш.
Якщо все ж не можеш потрапити на справжню співбесіду, почни з легших варіантів. Перший — Pramp — безкоштовний сервіс, де двоє кандидатів англійською проводять співбесіди один з одним. Моїми партнерами стали дослідник з Единбурзького університету і колишня розробниця з Apple.
Другий — Interview Warmup від Google, який аналізує відповіді англійською і показує семантичний аналіз, допомагаючи побачити інсайти, типу використовування робочої термінології, найчастіше вживані слова тощо.
У школі та університеті розклад переважно нам подавали від керівництва. При світчингу ти сам собі формуєш його.
Я прихильник чергування дисциплін, щоб мозок перемикався між активностями. Наприклад, Python з математикою, SQL з Power BI, пошук роботи з англійською. Натомість один з моїх знайомих бере певну дисципліну і приділяє їй тиждень з ранку до вечора.
Твій розклад має підходити під можливості. Наприклад, якщо я навчаюся у вихідний, то мені простіше на початку дня писати код, а у другій половині — працювати з рутинними задачами.
Якщо все ж хочеш перейти в іншу сферу, то оточення повинно максимально цьому допомагати. Навіть якщо це не напряму навчає хард-навичкам.
Те, що довкола нас, не менш важливе за інформаційний простір. І його потрібно адаптувати під свої навчальні потреби.
Я вірю, що навіть війна не зможе зупинити людину, яка вирішила відкрити для себе нову сферу. Так, це буде складніше, ніж раніше, але все ж можливо. Успіхів вам і оферів!
Оригінал статті тут.
Якщо ви починаєте розбиратися в розробці дронів, чотири назви трапляються постійно: Betaflight, INAV, PX4 і ArduPilot. Усі чотири – прошивки для польотних контролерів, і всі керують апаратом у польоті. Але архітектура в них різна, бо створювали їх під різні задачі й різне залізо.
Польотний контролер — це плата з мікроконтролером і сенсорами (гіроскоп, акселерометр, барометр, іноді GPS і компас), яка керує дроном у польоті. Прошивка - це програма на цій платі: вона зчитує дані сенсорів і команди пілота, стабілізує апарат і керує моторами. Від прошивки залежить, що вміє дрон: різко маневрувати у FPV, утримувати позицію за GPS чи самостійно виконувати місію за точками.
Звідки ця різниця? Найпростіше пояснити через історію, бо ці прошивки походять із двох окремих гілок розробки.
Перші аматорські польотні контролери працювали на Arduino з 8-бітними мікроконтролерами ATmega. На такому залізі почалися обидві гілки.
Перша гілка – ArduPilot (в українському сегменті його часто пишуть як «ардупілот»). Він з'явився наприкінці 2000-х на платах APM на базі Arduino і від початку задумувався як автопілот із місіями за точками й автономною навігацією. Коли ETH Zurich разом із 3D Robotics випустили 32-бітну плату Pixhawk, ArduPilot перейшов на неї. Навколо Pixhawk згодом виріс і PX4.
Друга гілка почалася з MultiWii, і задача там була скромніша. Прошивка працювала на Arduino з гіроскопом, який діставали з контролера Nintendo Wii (звідси назва), і мала просто стабілізувати мультиротор на дешевому слабкому процесорі. Тому ця лінія з самого початку трималася простої математики і спрощеного PID-контролера.
8-бітного Arduino швидко стало замало: не вистачало ні швидкодії, ні пам'яті. MultiWii переписали під 32-бітні мікроконтролери STM32F1, і так з'явився Baseflight разом із першими STM32-контролерами на кшталт Naze32.
CleanFlight відгалузився від Baseflight. Зробив це розробник Домінік Кліфтон, відомий як Hydra, і причини в нього були цілком практичні. Код Baseflight було важко підтримувати, прошивка працювала лише на кількох платах, а нові функції додавалися повільно. У CleanFlight код переписали чистіше, додали підтримку інших контролерів, нові PID-контролери і blackbox-логування польотів.
Спільнота навколо CleanFlight росла, і з часом розробники захотіли різного. Одним потрібна була максимальна продуктивність 5-дюймових мультироторів, іншим – GPS і навігація. Так з'явилися два окремі проєкти, Betaflight та INAV, а сам CleanFlight поступово втратив користувачів і перестав розвиватися як окрема прошивка.
Тож CleanFlight є предком Betaflight та INAV, а ArduPilot і PX4 до нього стосунку не мають.
Betaflight виріс із запиту на продуктивність мультироторів. Розробники вкладаються у швидкий цикл стабілізації, фільтри й тонке налаштування PID, і серед FPV-пілотів ця прошивка стала фактичним стандартом.
Список підтримуваних апаратів у Betaflight довший, ніж можна подумати. Крім квадрокоптерів у X- і +-конфігурації, там є трикоптери, гекса- й октокоптери, літаюче крило і літак із сервоприводами. Проте розвивається прошивка передусім навколо мультироторів, і найсильніша вона саме там.
Налаштовують Betaflight через Betaflight Configurator. Там прошивають плату, налаштовують PID, фільтри, режими польоту та OSD.
INAV – друга гілка CleanFlight. Її розробники зробили ставку на GPS і навігацію, тому основні режими тут – утримання позиції й висоти, повернення додому і польоти за маршрутом.
INAV добре працює з літаками й крилами, але на ній можна зібрати і мультиротор, ровер чи човен, бо мікшер налаштовується гнучко. Апарат програмують через графічний інтерфейс за допомогою логічних умов і глобальних змінних. Так, наприклад, налаштовують перемикання відеопередавача (VTX) за певних умов.
PID-контролер і фільтри в INAV влаштовані інакше, ніж у Betaflight, хоча загальний принцип той самий.
ArduPilot – найстаріша з чотирьох платформ і класична база для автопілотів. Під кожен тип апарата в цьому сімействі є своя прошивка:
ArduPilot цінують за перевірену стабілізацію, розвинену навігацію, велику документацію і спільноту. Його ставлять там, де апарат має виконувати місію передбачувано. Для зв'язку з апаратом ArduPilot використовує протокол MAVLink, а місії планують у наземних станціях Mission Planner або QGroundControl.
PX4 – автопілот того ж класу, що й ArduPilot. Він розвивається разом з екосистемою Pixhawk, тож під нього є найсучасніше залізо.
Архітектура PX4 модульна: компоненти обмінюються даними через внутрішню систему повідомлень, і з прошивки можна прибрати все, що не потрібно у вашому проєкті. Є інтеграція з ROS 2 і розвинені інструменти симуляції. Основні типи апаратів – мультиротори, літаки, VTOL і ровери. Гелікоптери, дирижаблі, човни й підводні апарати теж підтримуються, але на базовому рівні.
Універсальної найкращої прошивки немає. Вибір залежить від того, що саме ви будуєте.
Для FPV-збірки логічно почати з Betaflight, а для маршрутних місій на крилі з легким контролером підійде INAV. Якщо потрібен повноцінний автопілот, вибирати доведеться між ArduPilot і PX4. Перший дає перевірену базу, другий дає модульну архітектуру та інтеграцію із сучасним робототехнічним стеком.
Коли з прошивкою визначилися, починається практика: прошити політник, налаштувати PID, зібрати апарат, який справді літає. Цьому присвячена освітня програма Drones Firmware в Beetroot Academy, де стек дронів розбирають на реальному залізі.
Матеріал підготовлено спільно з інженером із багаторічним досвідом розробки БпЛА, якого ми не можемо назвати через безпекові причини. Також радимо прочитати, чому інженери у Defence Tech “стирають” себе з інтернету.
У другому кварталі 2026 року оборонні компанії опублікували на DOU 3518 вакансій, на 17,1% більше, ніж кварталом раніше. Deftech зайняв 17% усього ринку вакансій в українському IT і став одним з найбільших сегментів ринку праці серед технічних напрямів.
За перше півріччя 2026 року в оборонному секторі опублікували 6523 нові вакансії — більше, ніж за весь 2025 рік, коли їх було 5915. Найпродуктивнішим місяцем став червень: 1285 нових позицій за 30 днів.
Дані по кварталах показують стабільне зростання протягом усього року, без різких провалів.
Разом із кількістю вакансій зросла і кількість відгуків: у травні 2026 їх було 9303, тоді як роком раніше — лише 3534. Ринок і росте, і одночасно привертає більше уваги кандидатів.
Найбільше зростання у II кварталі показав напрям Hardware — 646 вакансій, майже стільки ж, скільки за все друге півріччя 2025 року. Поруч тримаються QA, Embedded і Project Manager: ці чотири категорії стабільно очолюють список найпопулярніших спеціалізацій.
Серед розробницьких стеків найбільш затребувані C++ та Python — саме ці мови зазвичай вимагають у вакансіях embedded-інженерів і фахівців з firmware для БПЛА.
Конкуренція за вакансії Hardware та Embedded найнижча серед усіх технічних категорій у deftech, і саме тут роботодавці найчастіше скаржаться на брак кандидатів. Кількість відгуків на embedded-вакансію практично не змінилася за квартал (−0,2), тоді як у Project Manager чи QA вона зростає.
Для порівняння: в категорії QA в deftech у середньому 25 відгуків на вакансію, а в IT загалом — 77. Різниця в три рази пояснюється просто: код фронтенду вміють писати тисячі людей, а працювати з UART, I2C, SPI, читати документацію на STM32 чи налаштовувати PID-регулятор у Betaflight чи ArduPilot — набагато менше.
Найбільшу кількість відгуків традиційно отримують вакансії Project Manager — у середньому 31,6 відгуків. QA на другому місці з 24,9, а DevOps показав найбільший приріст конкуренції за квартал (+10,5).
Водночас середня кількість відгуків на deftech-вакансію загалом — 10,2. Це помітно менше, ніж на аналогічні позиції у звичайному IT, де конкуренція за той самий досвід і той самий стек часто вища в кілька разів.
Серед нетехнічних вакансій найбільша конкуренція у II кварталі була на позиції Copywriter (18,8 відгуків на вакансію) і Sales (16,4), а найменша — на Support: кандидатів на ці вакансії відгукується мало навіть на тлі загального зростання інтересу до сектору. З-поміж усіх нетехнічних напрямів найчастіше шукають людей у категоріях HR, Support, Sales і Marketing — саме тут відкривається найбільше позицій для тих, хто йде в defence не через інженерію, а через свою наявну експертизу.
Роботодавці дедалі частіше шукають фахівців із досвідом, а не новачків. У II кварталі найбільше вакансій відкрили для кандидатів з 1–3 роками досвіду — 1210 позицій. Попит на спеціалістів із 3–5 роками зріс на 138 вакансій за квартал, а на фахівців з 5+ роками — на 67.
Водночас кількість вакансій для junior-рівня скоротилася з 287 до 227. Вхід у сектор лишається відкритим: вакансій без вимог до досвіду стало навіть більше, 54 проти 26 кварталом раніше. Просто шлях частіше лежить через базову технічну підготовку, ніж через співбесіду з чистого аркуша.
Київ традиційно лідирує і продовжує зростати — 2922 вакансії у II кварталі, майже на 500 більше, ніж у попередньому. Але цікавіша динаміка в інших містах: в Одесі кількість вакансій зросла з 24 до 83 за пів року, у Дніпрі — з майже нуля наприкінці 2024 року до 46 у II кварталі 2026-го. Віддалених вакансій — 273, і цей показник тримається стабільно після різкого стрибка на початку року.
Медіанна зарплата фахівців у deftech у червні 2026 року становить $2500, в IT загалом $2700. Розробникам платять більше: їхня медіана в deftech зросла за пів року на $350 і дійшла до $3200. dou
Цифри залежать від ролі. Ось медіани з зарплатного опитування DOU:
Найвищі медіани в deftech мають DevOps, Hardware-інженери та продакт-менеджери, а зарплати інженерів БпЛА одні з найнижчих. Тому для embedded-інженера цікаво дивитися не лише на власну роль, а й на суміжний hardware-напрям, де медіана вища. dou
Найбільша різниця з IT видна на краях шкали:
Початківцям deftech платить більше, ніж ринок IT загалом, а на сеньйорських рівнях виплати поки нижчі. Розрив із IT на рівні Senior скорочується: пів року тому сеньйори в deftech заробляли $3800. Це добре поєднується з даними про вакансії: порогом входу є базова hardware-підготовка, а не стаж. dou
Це медіани з опитування, а не вилки з вакансій. Вибірка в DOU невелика: 542 відповіді з deftech, з них 127 від розробників. DOU попереджає, що за окремими спеціалізаціями анкет небагато, тому результати можуть відчутно коливатися. Для Hardware-інженерів вибірка найменша, тож $4000 варто сприймати як орієнтир. dou
Джерело: DOU, «Зарплати фахівців у DefTech — літо 2026», опитування червня 2026.
Цифри показують закономірність: ринку потрібні фахівці з конкретною hardware-базою (embedded, firmware, hardware-дизайн), а не універсальні джуніори. Тому попит на курси з оборонних технологій і освітні програми з embedded зростає швидше, ніж встигає з'являтися пропозиція готових кадрів.
Освітня програма Embedded Development на Beetroot Academy розрахована саме на цей перехід: 5 місяців, тричі на тиждень, від основ електроніки та мікроконтролерів STM32 і ESP32 до протоколів UART, I2C, SPI, PCB-дизайну в KiCad і багатозадачних систем на FreeRTOS. Практика — на реальному залізі зі стартовим набором з 45 компонентів.
Для тих, хто вже має embedded-базу і хоче спеціалізуватися вужче, є курс Drones Firmware — 2 місяці, робота з Betaflight, ArduPilot, PX4 та MAVLink, фінальний проєкт у SITL-симуляторі.
Ринок deftech у 2026 році росте швидше, ніж встигає готувати кадри, і саме тому технічна база в embedded і hardware зараз цінується більше, ніж диплом чи вхідний рівень англійської.
Дані галузевих оглядів, липень 2026 (DOU, аналітика ринку праці в оборонці).
Project management у defence tech виглядає як звичайний PM в ІТ, поки не доходить до першого hardware-релізу. Тоді з'ясовується: спринт не рятує, коли партія плат застрягла на кордоні, а Jira-борд нічого не каже про те, що зміна ревізії плати зсуває весь дедлайн на два місяці.
За останні два роки кількість PM-вакансій у секторі зросла у 20 разів. Медіанна зарплата — $2 500 на місяць, вище, ніж у класичному ІТ. А PM, який розуміє embedded, FPGA чи hardware-цикли, отримує на $500–1 000 більше за колегу без цього досвіду. Ринок росте швидше, ніж встигає готувати людей. Розберімось, у чому саме різниця.
Класичний ІТ PM веде продукт від беклогу до релізу, і релізів у нього десятки на рік. У defence tech проєкт рухається по іншому маршруту: вимоги → R&D → testing → production → deployment. Кожен з цих етапів має свою логіку, свої gate'и і свою команду.
Софт можна відкотити патчем. Партію друкованих плат — ні. Якщо помилку в вимогах знайшли після того, як пішла серія, це не баг-репорт, це — втрачені гроші, час і часто компоненти, яких більше нема на складі. PM, який веде такий проєкт, відповідає не за спринт, а за весь ланцюжок: від першого начерку ТЗ до техпідтримки в полі.
Розрив між ІТ-логікою і defence-реальністю виглядає не абстрактно, а дуже предметно:
Після переходу картина інша: PM веде повний цикл – від вимог і R&D до testing, production readiness і deployment, планує R&D через WBS, milestones, dependency map і critical path, і бачить integration між hardware, firmware, software і production, а не лише свою частину процесу.
В ІТ-проєкті якість — це code review і QA-цикл. У defence tech додається ще один шар: ISO, AQAP, MIL-STD, ДСТУ. PM не мусить бути інженером-стандартизатором, але має розуміти, які readiness gates існують і хто ухвалює рішення «go» чи «no-go» на кожному з них.
Це governance іншого рівня. Пропущений gate — це ризик, що продукт не пройде приймання чи не отримає потрібний сертифікат уже після того, як у нього вкладені місяці роботи.
«FPGA не встигне до SOP» — фраза, яку класичний PM просто не розшифрує. У defence tech PM має розуміти архітектуру продукту на рівні hardware, embedded, firmware і software настільки, щоб читати технічну документацію, розбиратись у BOM і бачити, де саме виникає integration risk.
Йдеться про здатність розмовляти з інженерами їхньою мовою і самостійно оцінювати стан проєкту без «перекладача», який пояснює технічний фідбек звичайними словами.
Agile-мислення класичного PM ламається на перших же R&D-ітераціях. У hardware-проєкті частину задач неможливо оцінити наперед і чистий Scrum тут не працює.
Замість спринтів — WBS, milestones, dependency map і critical path. Замість point estimation — three-point estimation, яка враховує невизначеність. Замість фіксованого плану на квартал — rolling-wave planning, що уточнюється в міру надходження даних. Це ближче до Waterfall і Stage-Gate, ніж до звичного Agile, і саме тому підхід комерційного ІТ тут не масштабується напряму.
Компонент, який завтра має прийти зі складу, може виявитись під санкціями або з lead time у пів року. Project manager у miltech працює з long-lead items, будує dual-sourcing стратегії і тримає в голові логістику як постійний фактор ризику, а не форс-мажор.
Класичний ІТ PM рідко стикається з ситуацією, коли рішення про постачальника ухвалюється на місяці наперед і впливає на весь виробничий план. Тут це щоденна робота.
Jira і MS Project нікуди не діваються, але додається RAID-лог, decision log та ескалація до рівня, якого класичний ІТ-проєкт зазвичай не потребує. RACI прописується детальніше, бо команда multidisciplinary: інженери, виробництво, testing, логістика.
Переговори теж інші за складом учасників. Defence project manager веде діалог не тільки з розробниками і продактом, а й з leadership та military чи government-стейкхолдерами. Це люди, які ухвалюють рішення за іншою логікою і з іншими пріоритетами, ніж продуктова команда. Рішення тут часто доводиться приймати за неповних даних, зважуючи trade-offs і ризик-апетит, а не чекаючи, поки з'явиться повна картина.
Failed test у полі, зміна вимоги в останній момент, incident після deployment — усе це нормальний хід проєкту, а не аварійна ситуація. PM у defence веде діагностику, ескалацію, rebaseline і кризову комунікацію так само системно, як звичайний PM веде ретро після спринту.
Різниця в тому, що ціна помилки тут вища. І в тому, що after-action review не формальність для галочки, а джерело даних для наступного циклу.
Найчастіше PM або технічний менеджер з класичного ІТ, який хоче вести проєкт повністю, а не тільки координувати спринти. Інколи інженер, що виріс в управлінську роль, уже розуміє hardware, але потребує системи для вимог, ризиків і звітності.
В обох випадках бракує одного й того самого: структурованого мосту між менеджерськими навичками і технічною глибиною. ІТ-бекграунд дає процеси. Інженерний — розуміння заліза. Але без обох одразу PM губиться саме там, де класичний ІТ-досвід закінчується — на межі hardware, firmware і production.
Ми проаналізували 61 реальну вакансію Project / Technical / R&D-менеджменту в українському Defence Tech і побудували на цьому програму Project Management у Defence Tech: 22 заняття, 11 тижнів, наскрізний фінальний проєкт — Defence Project Execution Pack, який захищається під живою кризовою ввідною.
Якщо хочеш зрозуміти, чи підійде тобі формат — залиш заявку на сторінці програми, і ми розкажемо деталі.
Одна з перших речей, яка дивує людину при переході в український Defence Tech, – це не складність технологій і не темп роботи. Це вимога зникнути з інтернету. У цій сфері таку практику називають OPSEC (операційна безпека) і для багатьох ролей це базове правило роботи, а не забаганка інтроверта чи корпоративна параноя.
Спеціаліст, який ще у 2023 році давав інтерв'ю Forbes і мав відкритий профіль у соцмережах, після переходу в закритий оборонний проєкт повністю зник з інфопростору. Нуль фотографій, нуль статей, почищений кеш у пошукових системах. По його імені сьогодні не знайти навіть уривка старого тексту.
Розберемо, навіщо це роблять, як це виглядає на практиці і чому не всім у defence взагалі потрібно ховатися.
OPSEC (operational security, операційна безпека) – це набір практик, які зменшують кількість інформації про людину й компанію, доступної ворогові. У класичному IT про це майже не думають: розробник відкрито вказує стек у LinkedIn, ділиться пет-проєктами, дає інтерв'ю профільним медіа.
У Defence Tech логіка інша. Тут цифровий слід спеціаліста – це вразливість не лише для нього, а й для всього виробництва. Тому процесом очищення часто керує служба безпеки компанії, а не сам працівник.
Для людини з цивільного сектору це різкий контраст. Ще вчора публічність працювала на кар'єру. Тепер вона стає ризиком і це одна з головних культурних відмінностей defence tech в Україні від звичайного IT.
Люди, які розробляють дрони, системи РЕБ (радіоелектронної боротьби) або пишуть софт для військових, – пріоритетні цілі для ворожих спецслужб. Розкриття особи може обернутися фізичною загрозою і для самого інженера, і для виробництва, на якому він працює.
Ворог діє підступно. Якщо дістати самого розробника складно, мішенню для шантажу, погроз або ІПСО (інформаційно-психологічних операцій) стають його родичі. Коли в мережі немає даних про сімейні зв'язки, цей важіль тиску зникає.
Щоб зламати систему компанії, найпростіше зламати її співробітника. Старі пости, список друзів, інформація про хобі чи улюблені заклади – готовий матеріал для точкового фішингу (spear-phishing). Немає цифрового сліду – немає за що зачепитися.
Якщо ворожа розвідка знає, хто відповідає за закупівлі у стартапі з виробництва дронів, вона може відстежити, у яких іноземних компаній ця людина замовляє мікросхеми чи двигуни – і спробувати заблокувати поставки на міжнародному рівні. Анонімність менеджера захищає весь supply chain.
Очищення цифрового сліду зазвичай проходить у кілька рівнів.
Тут є важливий нюанс, який знімає частину тривоги. Рівень секретності залежить від ролі.
Якщо ви інженер-конструктор або керівник R&D на закритому заводі – вас справді не повинно існувати в публічному просторі. Саме такі технічні ролі — наприклад, у embedded-розробці для оборонних систем — найчастіше підпадають під найсуворіший OPSEC. Але якщо ваша робота – залучати донати у благодійний фонд на кшталт «Повернись живим» чи презентувати українські технології іноземним інвесторам на виставках, то публічність стає вашим головним робочим інструментом. Це один із нетехнічних напрямів у Defence Tech, де відкритість — навпаки, перевага.
Тобто питання не в тому, «ховатися чи ні». Питання в тому, яку роль ви займаєте і які правила діють саме для неї.
Культура безпеки – лише одна з відмінностей Defence Tech від звичайного IT. Поряд із нею йдуть висока ціна помилки, ненормований темп і робота під NDA в оборонних компаніях, коли неможливо відкрито ділитися успіхами навіть з друзями. Саме ці умови роботи в оборонній компанії варто розуміти ще до того, як ви шукаєте, як потрапити в miltech.
Це не привід відмовлятися від переходу. Це привід заходити в сферу з реалістичними очікуваннями. Люди, які розуміють ці правила заздалегідь, адаптуються швидше й спокійніше – бо для них закритість не стає несподіванкою.
Саме розуміння того, як влаштована індустрія зсередини – її ролі, культура, вимоги, – ми даємо в освітніх програмах Defence Tech напряму Beetroot Academy. Спокійно, без романтизації й пафосу, з фокусом на те, як тут реально працюють.
