Первый рейс самолета, собранного командой разработчиков, начался бы с сообщения на табло: «Вылет задерживается — выкатываем хотфикс на двигатель №2, сборка упала на проде». Эта шутка, известная в IT-среде в десятках вариаций, точнее любого учебника показывает разницу между инженерной культурой авиации и культурой разработки ПО. Там, где авиастроитель думает категориями отказоустойчивости и сертификации, программист думает категориями итераций, MVP и «потом допилим».
В этой статье мы серьезно разберем несерьезную гипотезу: какие привычки из мира разработки перенесли бы программисты на конструирование самолетов, чем это закончилось бы для пассажиров и почему эта метафора — отличный инструмент для разговора о качестве кода, тестировании и техническом долге. Материал будет полезен и разработчикам, и тем, кто хочет понять IT-кухню изнутри.
Требования: ТЗ на самолет, написанное за один созвон
Любой проект у программистов начинается с требований, и самолет не стал бы исключением. Заказчик сказал бы что-то вроде «нужна летающая штука, желательно быстрая, бюджет обсудим», а аналитик зафиксировал бы это как user story: «Как пассажир, я хочу перемещаться по воздуху, чтобы экономить время». Детали вроде дальности полета и количества двигателей уточнили бы уже после того, как прототип улетел в тестовый контур.
Характерные признаки «авиационного ТЗ от программистов» выглядели бы так:
- 📋 Формулировка «самолет должен летать» без критериев приемки — что считать полетом, решает тестировщик;
- 🔄 Изменение требований посреди сборки: «а давайте он еще и плавать будет, это же фича на один спринт»;
- 🗑️ Отказ от документации с аргументацией «код — лучшая документация, чертежи потом нарисуем»;
- 🎯 Фиксация дедлайна до оценки задач: презентация инвесторам назначена, значит, самолет должен быть готов.
Ирония в том, что в реальной авиации подобный подход невозможен физически: крыло нельзя «допилить в следующем релизе». А вот в разработке ПО гибкость требований — норма, и именно эта норма формирует специфическое мышление, которое мы и переносим в шутку про самолеты.
MVP: минимально жизнеспособный самолет
Концепция MVP — минимально жизнеспособного продукта — священна для IT-мира. Применительно к авиации она породила бы конструкцию, которую сложно назвать лайнером: один двигатель вместо двух, кресла появятся во второй версии, а шасси пока не убирается, потому что «это не блокер для запуска».
Логика здесь безупречна с точки зрения стартаперской методологии: сначала проверяем гипотезу, что самолет вообще взлетит, и только потом инвестируем в комфорт. Проблема очевидна — в авиации «проверить гипотезу на пользователях» означает рисковать живыми людьми, поэтому MVP-подход останавливается у дверей испытательного полигона.
Тем не менее у подхода есть и рациональное зерно. Прототипирование, быстрые итерации и ранняя обратная связь действительно используются в современном авиастроении — просто в виде цифровых моделей, симуляторов и продувок в аэротрубе, а не живых рейсов. Программисты, по сути, изобрели то же самое, только для софта.
Релизный цикл: обновления прямо в полете
Обновление ПО «на лету» — обычное дело для веб-сервисов. Перенесенная в небо, эта практика выглядела бы примерно так: пассажирам на крейсерской высоте показывают уведомление «Устанавливается обновление системы управления 2.4.1, не выключайте двигатели». Звучит как анекдот, но именно так устроена культура непрерывной доставки (continuous delivery) в разработке.
Типичный релизный календарь «авиакомпании программистов» включал бы:
- 🚀 Мажорные релизы два раза в год — с новыми крыльями и ломающими изменениями интерфейса кабины;
- 🩹 Патчи безопасности — внепланово, всякий раз, когда кто-то находит способ открыть дверь снаружи;
- 🧪 Бета-программу — добровольцы летают на версии с новым автопилотом и присылают отчеты о падениях;
- 📉 Откат на предыдущую версию — если новый двигатель оказался хуже, возвращаем старый прямо в ангаре.
В реальной разработке принцип «сначала откат, потом разбор причин» — признак зрелой команды. Продуманная стратегия rollback важнее героических ночных починок.
Здесь уместно вспомнить, что в современных авиалайнерах бортовое ПО действительно обновляется — но по строгим процедурам, на земле, с верификацией. Разница не в технологиях, а в цене ошибки: в вебе упавший сервис перезапускают за минуты, а упавший самолет — нет.
Тестирование: QA-отдел против здравого смысла
Тестировщик в анекдотах про программистов — персонаж, который заказывает в баре ноль пива, минус одно пиво и qwerty пива, после чего бар взрывается. В авиации такой специалист был бы незаменим: именно он догадался бы проверить, что произойдет, если пилот нажмет все кнопки одновременно, введет в бортовой компьютер SQL-инъекцию или попытается взлететь задом наперед.
Сравним подходы к проверке качества в двух мирах:
| Критерий | Авиастроение | Разработка ПО |
|---|---|---|
| Цена ошибки | Катастрофа, жизни людей | Обычно — откат и извинения в блоге |
| Подход к тестам | Исчерпывающая сертификация до запуска | Покрытие критичных сценариев, остальное — по остаточному принципу |
| Тестовая среда | Симуляторы, стенды, испытательные полеты | Staging, похожий на прод «примерно» |
| Отношение к багам | Недопустимы в критических системах | Классифицируются: критичные чиним, мелкие — в бэклог |
| Кто находит баги | Испытатели и регуляторы | Иногда — пользователи в проде |
⚠️ Внимание: переносить привычку «пользователи сами найдут баги» на любые системы, где ошибка причиняет вред — медицинские устройства, транспорт, энергетику, — недопустимо. Для таких систем существуют отдельные стандарты разработки и верификации, и они обязательны, а не декоративны.
Полезный вывод из сравнения простой: уровень строгости тестирования должен соответствовать цене ошибки. Для лендинга достаточно ручной проверки, для платежного сервиса нужны автотесты и код-ревью, а для системы управления полетом — формальная верификация. Программист, построивший самолет «как привык», просто ошибся бы в оценке этой цены.
Технический долг и legacy: самолет на костылях
Каждый разработчик знает: под любым работающим проектом лежит слой решений, принятых «на скорую руку». В самолете от программистов этот слой был бы физически осязаем: проводка, проложенная «временно» десять лет назад, узел, который никто не трогает, потому что «оно работает — не лезь», и деталь, назначение которой знает только уволившийся инженер.
Особое место занял бы legacy-код — бортовой компьютер, написанный на языке, которому полвека, потому что переписывать дорого и страшно. Забавный факт: это едва ли не самая реалистичная часть всей шутки. Долгоживущие отрасли — авиация, банки, госструктуры — действительно десятилетиями эксплуатируют старое ПО, потому что замена проверенной системы рискованнее, чем ее поддержка.
Почему старый софт живет десятилетиями
Система, которая стабильно работает много лет, накапливает доверие и скрытые зависимости: ее поведение изучено, сбои предсказуемы, обходные пути известны. Переписывание «с нуля» обнуляет этот капитал и почти всегда занимает больше времени и денег, чем оценивалось. Поэтому зрелая стратегия — постепенная модернизация отдельных модулей, а не революционная замена.
Чек-лист ниже помогает распознать опасный технический долг в любом проекте — хоть в самолете, хоть в веб-сервисе:
☑️ Признаки критического технического долга
Деплой в пятницу и другие суеверия
Золотое правило разработки — не выкатывать изменения в пятницу вечером, чтобы не чинить их в выходные. В «авиационной» версии это правило звучало бы как запрет на вылеты после обеда в пятницу: экипаж уже мысленно в отпуске, диспетчер досматривает сериал, а у самолета только что обновили навигацию.
За шуткой стоит вполне серьезная дисциплина управления изменениями. В зрелых командах существуют freeze-периоды — запреты на релизы в критичные моменты: перед праздниками, во время пиковых нагрузок, накануне важных событий. Авиация знает аналог: регламентные работы выполняют по строгому расписанию, а не «когда руки дойдут».
⚠️ Внимание: если в вашей команде релизный процесс держится на суевериях вместо автоматизации — это симптом. Откат должен быть быстрым, мониторинг — настроенным, а ответственный за релиз — на связи. Тогда день недели перестает иметь значение.
Главная разница между авиацией и IT — не в компетентности инженеров, а в цене ошибки. Методология должна масштабироваться под риски, а не копироваться из модных практик.
Чему авиация все-таки может научить программистов
Если перевернуть шутку, окажется, что заимствовать стоит в обе стороны. Авиационная культура безопасности подарила миру чек-листы перед вылетом, обязательный разбор инцидентов без поиска виноватых (blameless postmortem в IT растет именно оттуда) и принцип дублирования критических систем. Все это давно и успешно применяется в эксплуатации высоконагруженных сервисов.
Вам как разработчику полезно перенять три привычки авиаторов:
- ✅ Чек-лист перед релизом — короткий, письменный, обязательный для всех, без «я и так помню»;
- 🔍 Разбор каждого инцидента с фиксацией причин и мер, чтобы ошибка не повторилась;
- 🔁 Резервирование критичных компонентов: если отказ одного узла роняет систему, узел нужно дублировать.
Обратное заимствование тоже работает: симуляторы для обучения, цифровые двойники, быстрое прототипирование — это вклад IT-мышления в современное авиастроение. Так что программист, строящий самолет, — не только анекдот, но и вполне реальный инженер, просто его привычки проходят жесткую адаптацию под требования отрасли.
Проведите с командой мысленный эксперимент: «А если бы наш сервис был самолетом — что бы мы делали иначе?» Обычно после этого упражнения в бэклоге появляются задачи на мониторинг, откат и документацию.
FAQ: частые вопросы
Правда ли, что в самолетах используется устаревшее ПО?
Бортовые системы авиалайнеров действительно консервативны: они проходят длительную сертификацию, и их обновление — сложная регламентированная процедура. Это осознанный выбор в пользу проверенной надежности, а не отставание от моды.
Почему в разработке ПО допустимо выпускать продукт с багами?
Потому что цена ошибки в большинстве цифровых продуктов несопоставимо ниже, чем в авиации: дефект чинится обновлением. Баги при этом классифицируют по критичности — блокирующие устраняют до релиза, незначительные могут уходить в бэклог. Там, где ошибка опасна для людей, такой подход неприменим.
Что такое blameless postmortem и откуда он взялся?
Это практика разбора инцидента без поиска виноватого: анализируются причины и системные факторы, а не личные ошибки. Подход вырос из культуры расследования авиационных происшествий, где давно поняли: наказание исполнителя заставляет скрывать ошибки, а открытый разбор — предотвращать их.
Может ли программист реально работать в авиации?
Да, и таких специалистов много: бортовое ПО, симуляторы, системы бронирования и навигации пишут обычные разработчики. Разница в процессах — разработка для критических систем ведется по специальным стандартам с обязательной верификацией и документированием.
Какой главный урок из шутки про самолет от программистов?
Методы работы должны соответствовать цене ошибки. Гибкость и скорость итераций отлично служат веб-сервисам, но системы, от которых зависят жизнь и безопасность, требуют авиационной строгости: чек-листов, резервирования и исчерпывающей проверки до запуска.