[Анализ и проектирование систем, Проектирование и рефакторинг, IT-стандарты, Разработка робототехники, Дизайн] Всё как в жизни: законы проектирования космических кораблей (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
25-Янв-2021 13:31

Цитировать

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

Проектирование — это работа с цифрами. Исследование без цифр — всего лишь мнение.
Чтобы правильно спроектировать космический корабль, требуется бесконечное количество попыток. Именно поэтому полезно проектировать его так, чтобы он работал в условиях, когда что-то идет не по плану.
Проектирование — итеративный процесс. Необходимое количество итераций всегда на единицу больше, чем то, которое вы сделали в данный момент. Это верно в любой момент времени.
Ваши лучшие конструкторские разработки неизбежно окажутся невостребованными в итоговом проекте. Научитесь жить с разочарованием.
(Закон Миллера) Кривая определяется тремя точками.
(Закон Мара) Все линейно, если волшебным толстым маркером построить график в двойном логарифмическом масштабе.
Человек, который больше всего хочет управлять командой на старте любой проектно-конструкторской работы, с наименьшей вероятностью будет способен на это.
В природе оптимум почти всегда где-то посередине. Не доверяйте утверждениям, что оптимум находится в крайней точке.
Отсутствие всей необходимой информации никогда не должно становиться достаточной причиной для отказа от исследований.
Если сомневаетесь, прикидывайте. При крайней необходимости — предполагайте. Но не забудьте вернуться и прибрать за собой, когда появятся реальные цифры.

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. Космос — всецело непрощающая среда. Если вы облажаетесь с инженерией — кто-то умрет (и здесь нет возможности частичного зачета, основанной на том, что большая часть расчетов была верна…)Источники:

Оригинальная статья
Страничка Дэйва Аткина в университете Мэрилэнда

Если вам интересны материалы подобной тематики — приглашаю вас в свой телеграм-канал. Пишу в коротком формате о развитии softskills, brain science и своей работе в ИТ.
===========
Источник:
habr.com
===========
===========
Автор оригинала: David Akin
===========Похожие новости:

Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_itstandarty (IT-стандарты), #_razrabotka_robototehniki (Разработка робототехники), #_dizajn (Дизайн), #_printsipy (принципы), #_printsipy_proektirovanija (принципы проектирования), #_zakony (законы), #_razrabotka_elektroniki (разработка электроники), #_razrabotka (разработка), #_dizajn (дизайн), #_proektirovanie_sistem (проектирование систем), #_proektirovanie_interfejsov (проектирование интерфейсов), #_proektirovanie (проектирование), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_itstandarty (
IT-стандарты
), #_razrabotka_robototehniki (
Разработка робототехники
), #_dizajn (
Дизайн
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 16:50
Часовой пояс: UTC + 5