Всё как в жизни: законы проектирования космических кораблей

Автор оригинала: David Akin
  • Перевод

Это перевод оригинальной статьи Дейва Акина. Дэйв — инженер, профессор, директор лаборатории космических систем центра робототехники Мэрилэнда. Я работаю продактом-менеджером в ИТ и нашла здесь много релевантных идей. Некоторые законы и вовсе выглядят очень универсальными.


  1. Проектирование — это работа с цифрами. Исследование без цифр — всего лишь мнение.

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

  3. Проектирование — итеративный процесс. Необходимое количество итераций всегда на единицу больше, чем то, которое вы сделали в данный момент. Это верно в любой момент времени.

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

  5. (Закон Миллера) Кривая определяется тремя точками.

  6. (Закон Мара) Все линейно, если волшебным толстым маркером построить график в двойном логарифмическом масштабе.

  7. Человек, который больше всего хочет управлять командой на старте любой проектно-конструкторской работы, с наименьшей вероятностью будет способен на это.

  8. В природе оптимум почти всегда где-то посередине. Не доверяйте утверждениям, что оптимум находится в крайней точке.

  9. Отсутствие всей необходимой информации никогда не должно становиться достаточной причиной для отказа от исследований.

  10. Если сомневаетесь, прикидывайте. При крайней необходимости — предполагайте. Но не забудьте вернуться и прибрать за собой, когда появятся реальные цифры.

11. Иногда самый быстрый способ дойти до конца — выбросить все и начать сначала.

12. Не существует единственно правильного решения. Но всегда есть несколько неправильных.

13. Проектирование основано на технических требованиях. Нет никаких оснований делать что-то хоть немного «лучше», чем предписывают эти требования.

14. (Закон Эдисона) «Лучшее» — враг «хорошего».

15. (Закон Ши) Способность улучшать дизайн проявляется в первую очередь в интерфейсах. Это также лучшее место, чтобы все испортить.

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

17. Факт публикации исследования не делает его верным.

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

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

20. Плохой проект при хорошей подаче в конце концов обречен. Хороший проект при плохой подаче — обречен сразу.

21. (Закон Ларраби) Половина из того, что вам рассказывали на уроках в школе — чушь. Образование — это выяснение того, какая половина чушью не является.

22. Сомневаешься — документируй. (Требования к документации достигнут максимума вскоре после завершения программы.)

23. Сроки, которые вы ставите, будут казаться научной фантастикой до тех пор, пока ваш заказчик не уволит вас за то, что вы в них не уложились.

24. Это называется «Структура декомпозиции работ», потому что оставшаяся часть работ будет расти до тех пор, пока и если вы не начнете ее декомпозировать и структурировать.

25. (Закон Боудена) После неудачного тестирования всегда можно улучшить расчеты, чтобы показать, что у вас действительно всё это время был отрицательный запас прочности.

26. (Закон Монтемерло) Только без глупостей.

27. (закон Варси) Сроки сдвигаются только в одном направлении.

28. (Закон Рейнджера) Не существует такой вещи, как бесплатный запуск.

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

30. (Закон Тизенхаузена о техническом проектировании) Если вы хотите добиться максимального эффекта при проектировании новой инженерной системы — научитесь рисовать. Инженеры всегда конструируют автомобиль так, чтобы он выглядел как исходный замысел художника.

31. (Закон эволюционного развития Мо) Вы не сможете добраться до Луны, взбираясь на все более высокие деревья.

32. (Закон демонстраций Аткина) Когда оборудование работает идеально, действительно важные посетители не появляются.

33. (Закон Паттона о программном планировании) Хороший план, самым безжалостным образом приведенный в исполнение сейчас — лучше, чем идеальный план к следующей неделе.

34. (Закон Рузвельта о планировании задач) Делайте то, что можете, там, где находитесь, с тем, что имеете.

35. (Закон о проектировании де Сент-Экзюпери) Конструктор знает, что он достиг совершенства не тогда, когда нечего добавить, а тогда, когда нечего убрать.

36. Любой рядовой инженер может спроектировать что-то изящное. Хороший инженер проектирует работоспособные системы. Великий инженер делает их эффективными.

37. (Закон Хеншоу) Одно из ключевых правил для достижения успеха миссии — установление четких границ ответственности.

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

39. Любая исследовательская программа, которая «просто случайно» включает новый запуск ракеты-носителя, де-факто является программой запуска ракеты-носителя.

40. (альтернативная формулировка) Три ключевых правила для обеспечения доступности и своевременности новой космической программы:

  • Никаких новых ракет-носителей

  • Никаких новых ракет-носителей

  • Что бы вы ни делали, не создавайте новых ракет-носителей.

41. (Закон Макбрайна) Вы не сможете сделать лучше, пока не сделаете, чтобы работало.

42. На то, чтобы сделать правильно, времени всегда не хватает, но на то, чтобы потом переделывать, время всегда находится.

43. Нет программы полета — нет денег. Есть программа полета — нет времени.

44. Вы действительно начинаете что-то понимать, когда замечаете это в третий раз (или когда впервые учите этому).

45. Космос — всецело непрощающая среда. Если вы облажаетесь с инженерией — кто-то умрет (и здесь нет возможности частичного зачета, основанной на том, что большая часть расчетов была верна…)


Источники:

  1. Оригинальная статья

  2. Страничка Дэйва Аткина в университете Мэрилэнда


Если вам интересны материалы подобной тематики — приглашаю вас в свой телеграм-канал. Пишу в коротком формате о развитии softskills, brain science и своей работе в ИТ.

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 5 953 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 5

    0
    или можно брать уже готовые объекты и совершенствовать их
      0
      В современном мери так и происходит. Хочешь ты или нет, но натыкаешься на уже кем-то придуманные вещи, но в наших силах их переделать по своему и улучшить
      +1

      N24 переведён неверно. Там игра слов, и правильнее будет как-то так: оно называется СДР потому что если вы не будете применять структурированный подход, то количество оставшейся работы будет расти до тех пор, пока вы сами структурно не декомпозируетесь.


      N29 имеет в виду управление портфелями проектов (Program Management), а не управление разработкой программ (Software Development Management).


      N40 — это N39 v2, иначе не очень понятна вся шутка: чтобы проект доставки учеников в школу получился, в нем ни в коем случае не должно быть "разработать новый школьный автобус".


      N45 будет лучше начать по-русски как "Космос — не игрушки"

        0
        Проектирование — это работа с цифрами

        А ещё сравнивание решений это работа с цифрами, а не сравнение списка плюсов и минусов как это часто пытаются делать
        Проектирование основано на технических требованиях. Нет никаких оснований делать что-то хоть немного «лучше», чем предписывают эти требования.

        С этим трудно согласиться, тот же вояджер ожидали что проработает намного меньше чем реально получилось и смог он наверно благодаря тому что делали лучше чем надо.
          0
          Почти три года назад перевод был, на мой вкус, гораздо удачнее (не путать хороший перевод с дословным переводом): habr.com/ru/post/354936
          И объективно внимательнее — например, нюанс с пунктом 39.

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

          Самое читаемое