Есть такое устойчивой выражение "не рокет сайнс", которое обычно применяется, когда надо подчеркнуть, что это что-то простое и не требующее больших усилий. И сегодня, в день космонавтики (к тому же ещи и Артемис 2 вчера приземлился), я традиционно вспомнил, что когда-то я учился на инженера аэрокосмической области. Да-да, готовился иметь дело с расчетами, прочностью, аэро и гидродинамикой, сложными системами и всякими другими штуками, рядом с которыми типичный созвон “а почему не обновился статус в Jira?” выглядит как что-то действительно невероятно простое.
С тех пор жизнь немного свернула не туда, и вместо ракет я менеджерю IT-проекты. Но чем дольше я работаю в софте, тем чаще замечаю: между аэрокосмической промышленностью и современной айтишкой сходств сильно больше, чем кажется. Просто в одном случае ошибка может закончиться очень дорогим взрывом, а в другом, очень длинным сообщением в Slack и ночным созвоном с фразой “ребят, а у всех прод лег?”
🗓 Спринты против вотерфола
В IT все любят спринты. Две недели побегали, что-то сделали, что-то не успели, что-то перенесли, на ретро договорились больше так не делать, а потом в новом спринте сделали ровно так же.
В аэрокосмической промышленности такой стиль работы не очень приветствуется.
Потому что если ты проектируешь ракету или спутник, у тебя нет роскоши “давайте соберем MVP первой ступени и потом по фидбеку рынка поймем, чего не хватает”. Рынок, конечно, даст тебе фидбек. Но, скорее всего, один раз.
Поэтому там исторически ближе вотерфол: сначала долго считают, потом долго проектируют, потом долго проверяют, потом еще раз проверяют, потом отдельные серьезные люди перепроверяют тех, кто уже все проверил. И только потом начинается настоящее производство.
В IT же можно выкатить полусырой функционал, спрятать его за фича-флаг, показать 5% пользователей, собрать метрики, откатить и через неделю назвать это “управляемым экспериментом”.
🗺 Сценарии нужно продумать заранее. Очень заранее
Есть еще одна важная разница.
В IT мы часто позволяем себе двигаться итеративно: сначала собрали базовый флоу, потом посмотрели, где пользователи отваливаются, потом докрутили edge cases, потом внезапно обнаружили, что система должна работать не только в идеальном мире, но и у человека с плохим интернетом и древним Android.
В аэрокосмической области так не выйдет.
Там сильно заранее, еще до начала реального строительства, нужно продумать длинные и разнообразные сценарии от самого начала до самого конца. Не только счастливый путь в духе “все включилось, красиво полетело и не менее красиво приземлилось”, а вообще всю цепочку: как изделие будут собирать, тестировать, транспортировать, хранить, как оно поведет себя при вибрации, перегрузках, холоде, жаре, что будет при отказе одного узла, двух узлов.
И все это надо продумать до того, как в цеху начнут резать металл.
Потому что в космосе нет удобной опции “давайте сначала построим, а потом по ходу поймем, чего не учли”. Точнее, опция есть. Но обычно она называется “аварийная комиссия”.
На этом фоне многие IT-проекты напоминают ремонт квартиры в стиле “сейчас стену снесем, а там на месте решим, где вообще будет кухня”.
🪶 Запас прочности
При выводе груза на орбиту лишний вес это враг. Каждый дополнительный килограмм нужно вывести, удержать, компенсировать. А значит, заплатить за него деньгами, топливом и сложностью конструкции. Поэтому там часто проектируют с минимально достаточным запасом прочности. Не “чтобы стояло веками”, а “чтобы гарантированно выдержало нужные нагрузки и при этом не было тяжелее, чем необходимо”.
IT по духу устроено иначе.
Большая часть современного софта ближе не к ракетостроению, а к производству тракторов. С запасом. С перевесом. С тремя дополнительными слоями абстракций. С отдельным сервисом, который помогает другому сервису логировать запросы к третьему сервису. Все это тяжело, местами дымит, но в целом едет. Тем более, что современное железо вполне себе вывозит такие порой лишние надстройки.
🧪 Тестирование
В IT баг штука неприятная, но обычно поправимая. Где-то верстка поплыла, где-то метрика не улетела, где-то пуш пришел не тему. В худшем случае все собрались ночью, откатились, написали постмортем и сделали вид, что это был valuable learning.
В ракетостроении нельзя сказать “починим в следующем патче”, потому что подойти к уже улетевшему изделию с ноутбуком бывает затруднительно. Именно поэтому космическая инженерия так любит испытания, резервирование, моделирование отказов и общий вайб “а давайте заранее представим вообще все плохое, что может случиться”.
Айтишка в этом смысле избаловалась. Мы давно живем в мире, где прод это почти тоже тестовая среда, просто с реальными пользователями и чуть более дорогими последствиями.
📚 Документация
Айтишники любят шутить про документацию. Обычно никто ее не пишет, никто ее не читает, а когда что-то ломается, все внезапно начинают искать древний Confluence, который не обновлялся со времен падения Римской империи.
В аэрокосмической отрасли такой подход быстро приводит к очень неприятным вопросам.
Когда система сложная, документация это не бюрократия ради бюрократии. Это коллективная память проекта. Способ не зависеть от магии, героизма и человека по имени Вася, который “просто все держал в голове”, а потом уволился и уехал выращивать лимоны (реальный кейс).
IT к этой мысли тоже приходит. Обычно после пары серьезных инцидентов и разговора в духе: “А кто вообще понимает, как эта штука работает?”
🔁 Дублирование систем
В универе нас учили, что дублирование это норма. Если критичная система может отказать, ее страхуют. Иногда дважды. Иногда тремя разными способами. Потому что отказ там это не просто минус конверсия и недовольный менеджер.
В IT отношение к резервированию заметно более философское.
Все знают про single point of failure. Но в половине компаний этот single point of failure зовут Дима, и он сейчас в отпуске.
Сервисы, базы, процессы, доступы, все это тоже нуждается в резервировании. Но пока ничего не упало красиво и дорого, бизнесу бывает сложно объяснить, зачем платить за надежность заранее.
Космос в этом плане взрослее. Он давно понял, что стратегия “починим потом” хороша только там, где у тебя гарантированно будет это “потом”.
⏳ Time-to-market
В IT (особенно в стартапах) очень любят скорость. Быстрее MVP, быстрее релиз, быстрее конкурентов, быстрее, пока инвестор еще заинтересован, а команда еще не выгорела.
В аэрокосмической отрасли скорость тоже важна. Но там сильнее чувствуют разницу между “быстро” и “слишком рано”.
Потому что есть отрасли, где опоздать неприятно. А есть отрасли, где недотестировать смертельно.
На этом фоне многие айтишные трагедии уровня “мы не успели выкатить новый онбординг к понедельнику” выглядят чуть менее апокалиптично, чем обычно кажется внутри продуктовой команды.
Хотя переживают по этому поводу иногда так, будто реально сорвали запуск на Dragon Crew.
🧠 Почему IT все же не rocket science
И вот здесь главный парадокс.
Когда в IT говорят “это не rocket science”, обычно имеют в виду: “давайте без лишнего пафоса, это решаемая задача”. И, честно говоря, чаще всего это правда.
Потому что у цифровых продуктов есть огромная привилегия: их можно бесконечно пересобирать. Ошибаться. Учиться. Дорабатывать. Откатывать. Перепридумывать. Иногда даже полностью закопать и сделать заново, а потом назвать это сменой стратегии.
В космической инженерии такой роскоши сильно меньше. Там желательно быть правым заранее. Или хотя бы очень близко к этому.
Поэтому IT и не rocket science. И это вообще-то хорошая новость.
Это значит, что можно экспериментировать. Можно двигаться итеративно. Можно не ждать идеального чертежа мироздания перед первым релизом.
Можно выпускать не космический корабль, а просто полезный продукт, который решает конкретную боль и не разваливается от первого пользователя.
Хотя если ваш текущий процесс выпуска фичи уже занимает девять месяцев, требует согласования с половиной компании, трех комитетов, четырех документов и одного ритуального танца вокруг релизного календаря, поздравляю.
Вы все-таки немного приблизились к аэрокосмической промышленности. Только без красивых скафандров.