Почему летающие такси до сих пор не появились в городах? Закулисье индустрии 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) только недавно впервые за почти 80 лет официально определило отдельную категорию для аппаратов, сочетающих черты самолета и вертолета. Окончательные правила, как указано в Federal Register, вступили в силу в ноябре 2024 года. Со стороны это порой выглядит как медлительность, но на самом деле это необходимая архитектура для укрепления доверия.

Регулятор не спрашивает, может ли аппарат летать, он спрашивает, может ли эта система стабильно обеспечивать безопасный полет в определенных условиях? Существуют ли для этого надлежащие процедуры, подготовленный персонал, контролируемое программное обеспечение, отслеживаемые требования, доказательства верификации и производственные процессы, гарантирующие воспроизводимость?

Для проектного менеджера это многое меняет. В обычной среде график строится вокруг внутренних команд и их способности выполнить работу. В сертификационной программе он строится вокруг взаимодействия внутренней готовности и внешнего доверия: команда может выполнять работу, но право двигаться дальше зависит от того, достаточно ли зрелы доказательства, процессы и артефакты. Давить на скорость без понимания системных ограничений – быстрый способ получить больше хаоса, чем прогресса.

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

Именно здесь проектный менеджмент перестает быть административной функцией – он становится системой раннего прогнозирования, и именно это создает тот пульс, по которому организация понимает, где она находится и что меняется.

В контексте сертификационной программы это приобретает очень конкретное содержание. Карта зависимостей между тысячами задач и предиктивная модель на ее основе позволяют быстро увидеть, влияет ли задержка в выполнении конкретной задачи спринта на дату следующего программного этапа и в какой степени. Это превращает "мы немного отстаем" в конкретный вопрос: в каком направлении, на сколько дней и есть ли еще время для корректирующих действий до того, как это станет критическим.

Военный сегмент живет по другим правилам

Чтобы понять, почему гражданская eVTOL-индустрия развивается медленнее, чем ожидает рынок, полезно взглянуть на смежную сферу – военное применение беспилотных летательных аппаратов. Это важный контраст: скорость внедрения зависит не только от инженерной сложности, но и от того, кто принимает на себя риск и в каких условиях.

Украина – один из самых ярких примеров. По оценке CSIS, украинская модель позволяет протестировать и подписать контракт на новую технологию в течение одной недели. В боевых условиях командование сознательно принимает повышенный риск ради миссии – это иная логика приемлемости риска.

В гражданской авиации риск несут третьи лица, не участвовавшие в принятии решения, и именно поэтому этот опыт нельзя автоматически перенести.

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

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

Куда движется отрасль сейчас

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

Почему это важно понять сейчас

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

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

Нормативно-правовая база формируется, инфраструктура только проектируется, рынок кадров созревает, операционные модели проверяются, а компании одновременно должны продвигать вперед инжиниринг, испытания, производство, подготовку к будущей эксплуатации и сертификацию.

Именно в этом разрыве – между техническим прогрессом и управленческой прозрачностью – и заключается значительная часть работы проектного менеджера. Для меня хороший проектный менеджер в сложной аэрокосмической программе – это человек, который строит систему, в которой правильные вопросы задаются вовремя. В случае с eVTOL эта роль особенно важна, поскольку сама отрасль находится в переходном состоянии. Полностью устранить неопределенность в такой среде невозможно. Но ее можно сделать управляемой.

Поэтому eVTOL – это на самом деле не о такси. Это о том, как новая категория авиации проходит путь от инженерной возможности до общественного доверия. И этот путь определяется не только тем, насколько хорошо летает аппарат. Он определяется тем, насколько хорошо вся система вокруг него умеет координироваться, учиться, проверять себя, принимать решения и нести ответственность за риск. Именно там, между технологией и доверием, сегодня и происходит самая важная работа.