Представьте, что вы строите тысячи ракетных двигателей и тратите миллиарды долларов на стремление сделать человечество многопланетным видом. Если ваш производственный процесс не будет максимально эффективным, у вас закончатся деньги еще до того, как вы доберетесь до него. Вам, наверное, нужно как сумасшедший оптимизировать этот процесс, не так ли? Так почему бы нам не посмотреть, можем ли мы таким же образом оптимизировать наше программное обеспечение…

(пожалуйста, не обращайте внимания на тот факт, что никому не нужно производить программное обеспечение, поэтому оно называется программным, а не аппаратным, просто потерпите меня)

В недавнем интервью Илон Маск рассказал о том, что производство недооценивается и является самой сложной проблемой, которую пришлось решить SpaceX.

«В производственную систему уходит на 10 000% больше работы, чем на саму вещь».

«Объем усилий, затрачиваемых на проектирование, округляется до нуля по отношению к количеству усилий, затрачиваемых на производственную систему».

Далее он описал 5 шагов, используемых для оптимизации проектирования для производства, которые возникли в результате многих успехов и ошибок ракетных программ и Tesla в прошлом:

1. Сделайте требования менее глупыми

Требования определенно тупые; неважно, кто их вам дал. Таким образом, требования оспариваются, что позволяет мыслить нестандартно (см. Cybertruck).

«Все ошибаются. Независимо от того, кто вы, иногда все ошибаются ».

«Все дизайны неправильные, вопрос только в том, насколько они неправильны».

Он также заявляет, что конкретные люди должны владеть требованиями, а не отделами, чтобы их можно было задавать намного быстрее.

2. Очень постарайтесь удалить деталь или процесс

Вы не можете позволить себе добавлять деталь «на всякий случай». Маск рекомендует удалить как можно больше частей, даже если вы добавите их позже.

«Если вы не добавляете что-то время от времени, значит, вы удаляете недостаточно».

3. Упростите и оптимизируйте дизайн

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

«Самая распространенная ошибка умного инженера - оптимизировать то, чего не должно быть».

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

4. Ускорьте цикл

Здесь вы начинаете находить проблемы и получаете возможность исправить их, пока не стало слишком поздно. Это как научиться бегать перед тем, как пробежать марафон.

«Ты движешься слишком медленно, иди быстрее! Но не спешите, пока сначала не поработаете над тремя другими делами ».

5. Автоматизировать

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

Было бы очень дорого пытаться автоматизировать что-то слишком сложное или ненужное.

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

«Если что-то доходит до конечного тестирования и проходит, то вам не нужно проводить внутрипроцессное тестирование».

Мы можем резюмировать этот процесс следующим образом:

Дизайн → Вопрос → Упростить → Оптимизировать → Ускорить → Автоматизировать

Как это связано с программным обеспечением?

Допустим, вместо того, чтобы строить тысячи ракет, вы разрабатываете следующее большое приложение / веб-сайт / API. Это огромная задача. Если вы все сделаете правильно, вас купит Google в течение 5 лет, иначе вы потратите 15 лет, никогда не получите полную функциональность, потратите все свои деньги и вас обгонит кто-то другой. Как эта ситуация соотносится с ситуацией SpaceX?

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

Производство ≈ Начало жизни

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

Как и в случае с ракетами, это недооцененная часть программирования. Неопытный разработчик программного обеспечения может предположить, что их скомпонованный скрипт можно без изменений использовать в производственной среде. Это все равно, что построить ракетный двигатель в своем гараже из запчастей и решить, что вы собираетесь построить еще 100 000 экземпляров точно таким же образом.

Часть = сценарий, услуга или программа

Исключение всего сервиса из вашего приложения (например, удаление почтового сервера, потому что вы можете просто использовать API), несомненно, отличный способ снизить сложность и ускорить работу.

Стоимость = Стоимость?

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

Существует также альтернативная стоимость сложности. Если функция с низким приоритетом требует в общей сложности дня на разработку, развертывание, отладку, документирование и т. Д. В течение месяца, то вы упустили возможность запустить потрясающую функцию, или представить свой продукт на конференции, или желаю корпоративной вечеринки!

Вес = сложность

Для ракет это означает не только вес детали, но и то, сколько тяги вы можете получить при таком весе. Сложность программного обеспечения означает более сложную документацию, техническую задолженность, ошибки, развертывание и т. Д., Что увеличивает затраты, но, что более важно, замедляет вас и убивает ваш импульс.

Снижение сложности позволяет продолжить работу с тем же количеством ресурсов.

Требование = Требование

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

Feature = Feature

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

Текущее тестирование = модульные тесты

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

(я не предлагаю избавляться от них, просто запускайте их реже)

Колония на Марсе = __________

Это помогает понять, над чем вы работаете. Четкая и амбициозная цель, безусловно, помогла SpaceX сосредоточиться на самом важном. Какова конечная цель вашего проекта? Что заставит вас сказать «Миссия выполнена»?

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

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

Что нам делать по-другому?

Со всеми параллелями, описанными выше, я думаю, мы можем извлечь некоторые уроки из пяти шагов. Оглядываясь на некоторые из моих собственных проектов, которые было трудно реализовать, я теперь вижу, что мы пропустили некоторые шаги или сделали их в неправильном порядке, как и Илон признал, что Тесла делал в прошлом. Исходя из этого, я думаю, что мы все должны поступать по-разному:

  • Бросьте вызов всем требованиям, даже самым маленьким. Типичный пример: «У нас есть потоковые данные, поэтому нам нужен конвейер потоковых данных», но на самом деле нет необходимости обрабатывать данные в реальном времени. Микропакетная обработка намного проще и дешевле в сборке.
  • Сделайте паузу, когда у вас появится рабочая концепция, чтобы спросить, какие процессы не нужны, и просто удалите их. Не тратьте время на функцию, которая никого не волнует, только потому, что вы хотите, чтобы все было «готово к производству».
  • Осознайте истинную стоимость сложности. Любая «часть» в вашем приложении, которую можно заменить чем-то более простым, также должна быть удалена.
  • Не оптимизируйте что-то неправильное. Скорость - ваш приоритет или это снижение затрат? Стоит ли вам тратить время на улучшение функций или добавление новых? Найдите в компании реального человека, который объяснит вам, в чем состоит приоритет и почему.
  • Не оптимизируйте слишком быстро. Не придумывайте рамки, пока не попробуете что-нибудь простое. Не определяйте модель данных, когда данные не окончательно обработаны. Будьте гибкими, чтобы меняться повсюду.
  • Ускорьте код перед автоматизацией. Вы узнаете, какие части требуют дальнейшей оптимизации, и обнаружите проблемы, которые невозможно исправить после запуска.

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

Полный текст упомянутого интервью можно найти здесь: https://everydayastronaut.com/starbase-tour-and-interview-with-elon-musk/