Первый рейс самолета, собранного командой разработчиков, начался бы с сообщения на табло: «Вылет задерживается — выкатываем хотфикс на двигатель №2, сборка упала на проде». Эта шутка, известная в IT-среде в десятках вариаций, точнее любого учебника показывает разницу между инженерной культурой авиации и культурой разработки ПО. Там, где авиастроитель думает категориями отказоустойчивости и сертификации, программист думает категориями итераций, MVP и «потом допилим».

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

Требования: ТЗ на самолет, написанное за один созвон

Любой проект у программистов начинается с требований, и самолет не стал бы исключением. Заказчик сказал бы что-то вроде «нужна летающая штука, желательно быстрая, бюджет обсудим», а аналитик зафиксировал бы это как user story: «Как пассажир, я хочу перемещаться по воздуху, чтобы экономить время». Детали вроде дальности полета и количества двигателей уточнили бы уже после того, как прототип улетел в тестовый контур.

Характерные признаки «авиационного ТЗ от программистов» выглядели бы так:

  • 📋 Формулировка «самолет должен летать» без критериев приемки — что считать полетом, решает тестировщик;
  • 🔄 Изменение требований посреди сборки: «а давайте он еще и плавать будет, это же фича на один спринт»;
  • 🗑️ Отказ от документации с аргументацией «код — лучшая документация, чертежи потом нарисуем»;
  • 🎯 Фиксация дедлайна до оценки задач: презентация инвесторам назначена, значит, самолет должен быть готов.

Ирония в том, что в реальной авиации подобный подход невозможен физически: крыло нельзя «допилить в следующем релизе». А вот в разработке ПО гибкость требований — норма, и именно эта норма формирует специфическое мышление, которое мы и переносим в шутку про самолеты.

MVP: минимально жизнеспособный самолет

Концепция MVP — минимально жизнеспособного продукта — священна для IT-мира. Применительно к авиации она породила бы конструкцию, которую сложно назвать лайнером: один двигатель вместо двух, кресла появятся во второй версии, а шасси пока не убирается, потому что «это не блокер для запуска».

Логика здесь безупречна с точки зрения стартаперской методологии: сначала проверяем гипотезу, что самолет вообще взлетит, и только потом инвестируем в комфорт. Проблема очевидна — в авиации «проверить гипотезу на пользователях» означает рисковать живыми людьми, поэтому MVP-подход останавливается у дверей испытательного полигона.

📊 Какая IT-привычка была бы самой опасной в авиастроении?