Чому літаючі таксі досі не з'явилися в містах? Залаштунки індустрії eVTOL

Останні сім років я працюю на стику енергетики, авіації та управління складними технологічними системами. Коли я кажу друзям, що працюю над "літаючими таксі", зазвичай чую жарт про "П'ятий елемент". Детальніше читайте в ексклюзивній колонці для 24 Каналу.

Координувати задачі й стежити за графіком – звична частина роботи, але в таких програмах вона далеко не головна. Чим довше я в цій сфері, тим більше переконуюсь: сам факт польоту – це далеко не найскладніша частина. Складніше побудувати навколо нової технології інженерну, організаційну, регуляторну й суспільну довіру. І тут робота проєктного менеджера стає значно глибшою за класичне "контролювати дедлайни". У високорегульованій авіації хороший менеджер не керує кожним кроком команди й не зобов'язаний мати відповіді на всі технічні питання. 

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

Що таке eVTOL насправді

eVTOL (electric Vertical Take-Off and Landing) – електричний літальний апарат, що злітає й сідає вертикально, як вертоліт, але в польоті працює ближче до літака – летить горизонтально. У масовій уяві його часто називають air taxi – назва зручна, але оманлива. 

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

Галузевий трекер eVTOL.Travel зафіксував понад 20 компаній у 10 країнах, що одночасно розробляють такі апарати. Технологія летить швидше, ніж дозріває система навколо неї – і саме в цьому розриві відбувається найцікавіша робота.

Складність, якої не видно ззовні

З вулиці здається, що головне питання – чи зможе апарат безпечно злетіти, перелетіти з точки А в точку Б і сісти. Але за кожним польотом стоять вимоги, моделі, плани верифікації, симуляції, релізи програмного забезпечення, тестові кампанії, оцінки безпеки, рішення регулятора та багато іншого. І все це має бути синхронізоване, а не просто існувати поруч.

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

Як виглядає розробка безпеково-критичного ПЗ зсередини

Розробка програмного забезпечення для eVTOL підпорядковується міжнародному стандарту сертифікації авіаційного ПЗ – DO-178C. Рівень його вимог залежить від критичності системи: найвищий – для ПЗ, відмова якого може призвести до катастрофи. 

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

Ключова методологія тут – V-модель. На відміну від звичного циклу "написали код – протестували", V-модель вибудовує суворий симетричний зв'язок між розробкою і верифікацією. Ліва гілка V – декомпозиція вимог: від системного рівня через підсистеми до рівня програмного забезпечення. Права гілка – дзеркальна верифікація: кожен рівень вимог має відповідний рівень тестів із задокументованими доказами їх виконання. Пропустити ланку неможливо – безпека та регулятор вимагають доказів на кожному щаблі.

Команди, з якими працюю я, розробляють системи керування польотом і перебувають на перетині двох світів: системної інженерії та розробки ПЗ. З одного боку, вони створюють системні вимоги, з іншого – пишуть алгоритми, які безпосередньо керують польотом. Це означає: зміна системної вимоги – навіть одного параметра – може потягнути за собою ланцюжок перегляду алгоритмів, повторних аналізів і нових верифікаційних тестів. А може обійтися виправленням однієї константи. Різниця залежить від того, наскільки глибоко ця вимога вкорінена в архітектуру системи – і саме тому оцінка впливу будь-якої зміни є окремою і серйозною роботою. 

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

Перш ніж оновлений код опиниться на борту реального літака, він проходить кілька рівнів тестування: 

• спочатку симулятори, де моделюється поведінка системи в різних умовах;
• потім реальне апаратне забезпечення, де ПЗ взаємодіє з фізичними компонентами;
• далі перевірки на землі з літаком;
• лише після цього – польотні випробування. 

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

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

Люди

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

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

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

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

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

Характерний приклад такої адаптації – адаптований гнучкий підхід (Scrum чи Kanban) в авіаційній програмі. Scrum як інструмент ітераційного планування тут цілком можливий – але він має інший вигляд, ніж у звичайному продуктовому розвитку. Наприкінці спринту рідко буде класичне демо готової функції для кінцевого користувача. Частіше результат – новий алгоритм, набір верифікаційних артефактів, оновлена документація або завершена тестова кампанія. Зафіксувати незмінний обсяг робіт теж часто неможливо: пріоритети зміщуються залежно від прогресу суміжних команд і зовнішніх залежностей. 

Але з цим можна працювати, зокрема через Scrum of Scrums: регулярну синхронізацію між командами, яка дозволяє виявляти міжкомандні блокери до того, як вони впливають на критичний шлях. Те, що залишається вимірюваним у будь-якому випадку, – ефективність самого процесу доставки: темп виконання і де виникають затримки, як змінюється прогнозована дата завершення критичного напрямку. Саме ці сигнали дозволяють приймати рішення на основі даних, а не відчуттів.

Інфраструктура

Обладнання авіадиспетчерів у США десятиліттями не оновлювалося. Звіт GAO за 2024 рік фіксує, що деякі диспетчерські пункти досі використовують обладнання на основі дискет. FAA оголосила про модернізацію на 12,5 мільярда доларів, визнаючи, що ця інфраструктура не розрахована на нові типи повітряних апаратів.

Вертипорти – спеціальні майданчики для вертикального зльоту й посадки у містах – фізично майже ніде ще не побудовані як повноцінна мережа. За даними Altitudes Magazine, станом на початок 2026 року в США немає жодного спеціально побудованого комерційного вертипорту. Для виробника eVTOL це ще один рівень зовнішньої залежності. Управління цими залежностями без єдиного центру прийняття рішень – де кожна зі сторін має власні цикли планування і жодна не підпорядкована іншій – є одним із найскладніших типів координаційного середовища. 

Подібну логіку я бачила раніше в авіаперевезеннях: синхронізація між авіакомпаніями, Amadeus, Galileo, Sabre і IATA як галузевим стандартизатором, але тут масштаб і ставки принципово інші.

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

Сертифікація

Станом на середину 2026 року демонстраційні польоти вже виконали:

• EHang у Китаї,
• Archer Aviation в Абу-Дабі,
• Eve Air Mobility у Бразилії,
• SkyDrive над Токіо,
• Joby Aviation за маршрутом JFK – Мангеттен.

Але демонстраційний політ і сертифікована пасажирська експлуатація – це різні світи. І плутати їх – поширена помилка. У США FAA тільки нещодавно офіційно визначила окрему категорію для апаратів, що поєднують риси літака й вертольота (FAA), вперше за майже 80 років. Фінальні правила, як вказано в Federal Register, набули чинності у листопаді 2024 року. Збоку це часом виглядає як повільність, але насправді це необхідна архітектура для побудови довіри.

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

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

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

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

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

Військовий сегмент живе за іншими правилами

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

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

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

Доречна тут аналогія з розробкою нового лікарського препарату: перш ніж він потрапить до аптек, проходять кілька фаз клінічних випробувань, бо ціна помилки – здоров'я й життя людей. eVTOL проходить схожий за серйозністю шлях: кожен етап має бути підтверджений. За даними FlightGlobal, апарат такого класу може коштувати кілька мільйонів доларів, тому кожен невдалий тест серйозний і фінансово, і з погляду безпеки.

Сертифікація, нові професії, застаріла аеронавігаційна інфраструктура, відсутність міської мережі вертипортів і логіка прийняття ризику – жодна з цих складових не вирішується лише кращою інженерією літака. Кожна вимагає готовності цілої системи навколо технології: регулятора, інфраструктури, кадрів і навіть того, хто і на яких умовах погоджується нести ризик.

Куди рухається індустрія зараз

У 2026 році FAA запустила eVTOL Integration Pilot Program (eIPP) – вісім демонстраційних проєктів у 26 штатах (DOT). Аналітики Low Altitude Economy оцінюють, що навіть найбільш просунуті компанії можуть отримати фінальний дозвіл не раніше середини 2027 року. Це не ознака провалу, а нормальна траєкторія для категорії авіації, де сертифікація є частиною самої програми, а не фінальним кроком після неї.

Чому це важливо зрозуміти зараз

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

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

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

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

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