2. Создание правильной ракеты занимает бесконечное количество времени. Поэтому следует создавать ракеты, в которых что-то неправильно.
3. Конструирование — циклический процесс. Количество итераций всегда на одну больше, чем уже было. Это верно на любой стадии.
4. Ваши лучшие наработки в окончательном решении будут не нужны. Привыкните жить с этим.
5. (Закон Миллера) Три точки — это уже кривая.
6. На логарифмической бумаге всё есть прямая.
7. На начальных стадиях разработки тот, кто больше всех хочет возглавлять работу, меньше всех подходит на эту роль.
8. В природе оптимум почти всегда в середине. Не доверяйте утверждениям, в которых оптимум в районе экстремума.
9. Недостаток информации ещё не причина откладывать анализ решения.
10. Не уверен — решай приблизительно. Но обязательно вернись к решению, когда появятся настоящие цифры.
11. Иногда самый быстрый путь к выполнению проекта — всё выкинуть и начать сначала.
12. Единственно верного решения не существует. Хотя существует много неверных.
13. Разработка базируется на требованиях. Нет причины делать что-то хоть капельку «лучше», чем указано в требованиях.
14. (Закон Эдисона) «Лучшее» враг «хорошего».
15. (Закон Ши) Все возможности для улучшения решения обычно кроются в стыках. Стыки же и основное место для «косяков».
16. Люди, которые обдумывали эту задачу до вас, не имели прямой связи с мудростью предков. Поэтому не стоит думать, что их решение было лучше вашего. Тем более не стоит выдавать его за своё.
17. То, что решение было опубликовано, не делает его более верным.
18. Опыт проверяет решения в жизни. Слишком много проверки жизнью может обречь казалось бы неплохие решения.
19. Вероятность того, что вы намного умнее всех в своей области, очень невелика. Если в ваших расчётах финальная скорость вышла в две скорости света, то вы, возможно, изобрели телепорт, но скорее всего вы просто накосячили.
20. Плохое решение с хорошим отчётом — со временем будет отвергнуто. Хорошее решение с плохим отчётом будет отвергнуто сразу.
21. (Закон Ларраби) Половина того, чему вас учили преподаватели — полная чушь. Осталось разобраться, которая половина. В этом суть образования.
22. Если сомневаешься — документируй. (Потребность в документации достигает максимума вскоре после закрытия программы).
23. Расписание срока работ, которое вы составите, всегда кажется отвлечённой фантастикой, пока заказчики не уволят вас за его несоблюдение.
24. Это называется «Work Breakdown Structure» (порядок разбивки работы), потому что вы будете Work пока не настанет Breakdown, и придётся внедрить какой-то Structure.
25. (Закон Баудена) После провала испытаний, всегда можно улучшить расчёты, показав, что негативная вероятность присутствовала изначально.
26. (Закон Монтемерло) Don't do nuthin' dumb — не надо делать фигню!
27. (Закон Варси) Сроки смещаются только в одну сторону.
28. (Закон Рэнжера, иногда ошибочно Закон Хайнлайна) TANSTAAFL: There ain't no such thing as a free launch. Примерно переводится как «Бесплатно кормят только на убой» или «бесплатно просто так не покормят».
29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число Пи, и сдвиньте десятичную точку на одно положение вправо.
30. (Закон инженерных решений фон Тисенхаузена) Если хотите, чтобы ваш вклад в конструкторскую разработку инженерной системы был максимальным, научитесь рисовать. Инженеры всегда в конце концов делают что-то похожее на картинку концепт-художника.
31. (Закон эволюционной разработки Мо) Нельзя добраться до луны, залезая с каждым разом на более высокое дерево.
32. (Закон демонстраций Аткина) Когда всё работает как надо, действительно важные посетители не приходят.
33. (Закон планирования програм Паттона) Хороший план насильно исполненый сейчас, лучше чем идеальный на следующей неделе.
34. (Закон планирования задач Рузвельта) Делай что можешь, там где ты есть, с тем что под рукой.
35. (Закон дизайна Сент-Экзюпери) Дизайнер знает, что достиг совершенства, ни тогда когда уже нечего добавить, а когда уже нечего убрать.
36. Обычный инженер делает элегантные системы. Хороший инженер — работающие. Настоящий инженер — эффективные.
37. (Закон Хэншоу) Важнейшая вещь в успехе программы это чётко выстроить ряды виновных.
38. Возможности повышают требования, игнорируя ограничения из учебников.
39. Любая космическая программа, в которой «оказалась» разработка новой ракеты, по факту есть программа разработки новой ракеты.
39. (альтернативная формулирока) Три правила сохранения космических програм в пределах бюждета и сроков:
1) Никаких новых ракет.
2) Никаких новых ракет.
3) Делайте что угодно, только никаких новых ракет.
40. (Закон Мак-Брайена) Не надо улучшать то что ещё не заработало.
41. Никогда не хватает времени сделать всех нужных элементов, но почему-то всегда хватает времени сделать много ненужных.
42. Космос совершенно не прощает ошибок. Если инженер ошибся то кто-то погибнет (и нет такой вещи как «частичная вина», мол, в основном-то решение было правильным).
Оригинал
Комментарии (28)
redfs
05.05.2018 18:43+1Это вещь известная и просто шикарная. Бауманка оценит :)
Есть еще версия с пояснениями и примерами
И да… Этот текст имеет больше отношения к управлению разработкой (особенно в РКТ), чем многие модные сейчас методологии. Спасибо за перевод!
Readme
05.05.2018 19:26+1Пунктуация что ты, делаешь ахаха. Ну серьёзно, ну нельзя же так.
И да, для переводов есть специальная галка при редактировании и даже специальное поле, в котором указывается оригинал — это позволяет проще искать и фильтровать статьи.
Dima_Sharihin
05.05.2018 20:48Примерно переводится как «Бесплатно кормят только на убой» или «бесплатно просто так не покормят».
Там же игра слов: дословно "не бывает бесплатного запуска", но launch (запуск) созвучно с lunch (обед). Полагаю автор намекал, что часто для полноценного завершения запуска изначально заложенных(или задуманных) средств не хватает и за все нужно дополнительно платить
LynXzp
06.05.2018 02:01Конечно, я даже прочитал как запуск, но если уж брать исключительно еду то «бесплатным бывает только сыр в мышеловке».
ovetganna
06.05.2018 12:21вот да, тоже показалось некорректным переводом.
КМК, речь о том, что на каждый тестовый (?) запуск требуются ресурсы — и надо очень хорошо об этом помнить при планировании испытаний, экспериментов, да и просто в разработке.
алсо не нашел ничего по «закон рэнджера», а под определение «закона Хайнлайна» подходит разве что «Никогда не приписывай злонамеренности то, что вполне объясняется глупостью; но не исключай злонамеренности»
andreysmind
06.05.2018 13:00Изначально фраза встречается в книге «The Moon is a Harsh Mistress». Там было про завтраки.
erondondon
05.05.2018 23:04-1Ракета по сути это большая питарда, которую запускали тысячу лет назад. Где новые технологии? Законы они пишут.
lxsmkv
06.05.2018 01:17+1Я, конечно, совершенно не разбираюсь в ракетостроении, но утверждение, что «ракета это по сути большая петарда» — совершенно неверно.
Ведь разница очевидна: петарда неуправляема, а ракета управляема.kalininmr
06.05.2018 01:52впринципе грустно, что до сих пор, дальние полеты производят методом пинка под зад(разогнались и по инерции).
хотя подвижки вроде бы естьlxsmkv
06.05.2018 14:44Не использовать инерцию было бы весьма странно. Ведь, когда мы едем на велосипеде мы набираем скорость и перестаем на момент крутить педали — движемся по инерции. Также мы не крутим педали когда едем под горку. Совеременные велосипеды имеют «коробку передач» — тоже для экономии энергии велосипедиста. Экономное расходование энергии, одна из основных задач в конструировании средств передвижения.
Поясните пожалуйста, что вы имеете ввиду, говоря о «других» методах приведения транспортного средства в движение? Мне просто никакие другие на ум не приходят.
Ohar
06.05.2018 04:42Вы не могли бы ещё указать, кто такой этот Акин?
redfs
06.05.2018 09:02Akin, David
UMD, Associate Professor
Director of Space Systems Laboratory
Department of Aerospace Engineering
wheredevel
06.05.2018 08:07+229. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число Пи, и сдвиньте десятичную точку на одно положение вправо.
Надо было вот как:
29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число ПИ, и Здвиньте ДЕЦимальную точку на одно положение вправо.
Henry7
06.05.2018 12:2113-й пункт какой-то спорный и мутный. Можно пример?
NiPh
06.05.2018 14:50Есть тз. Его разрабатывали уже закладывая туда запас прочности и т.д., так что если вы в каком-то из мест проекта решите сделать лучше чем надо, просто потому что можете, вы только зря потратите время, которое вам пригодится на других этапах разработки или реализации проекта.
Есть наверное спорные моменты, когда какая-то уже отработанная технология многократно превысит какое-то из требований, не задерживая весь проект, но если это тз на высоконагруженную систему, каждый из узлов которой работает на пределе своих возможностей — это маловероятное развитие событий.
По крайней мере так я его воспринял.Henry7
06.05.2018 16:03>>если вы в каком-то из мест проекта решите сделать лучше чем надо, просто потому что можете, вы только зря потратите время
Лучше всегда дольше? Иногда получается сделать лучше, дешевле и быстрее.
Банальный пример: требуется трехкратное резервирование системы, а в данном узле можно выполнять только четное резервирование для соблюдения соосной симметрии. Снижение количества узлов с 4 до 3 возможно только путем полного переделывания всей компоновочной схемы.
dmbreaker
07.05.2018 07:43Если от вас просят построить постую лодку, то значит на выходе должна получиться лодка, а не эсминец или лодка с элементами оного. В программировании это принцип YAGNI.
https://ru.m.wikipedia.org/wiki/YAGNIHenry7
07.05.2018 10:00Если «лучше» в данном контексте синоним «сложнее», то я полностью согласен с этим принципом.
ermouth
06.05.2018 12:21Пункт 29 – про «сдвиньте точку вправо» в оригинале про оценки стоимости, а не времени. То-есть оценку времени умножить на Пи, а оценку стоимости увеличить на порядок.
ganqqwerty
06.05.2018 12:37Отлично маппится на создание ПО. Особенно мне про стыки понравилось, у нас тоже самая большая засада в интерфейсах, связывающих одну систему с другой.
AGrin
06.05.2018 16:14Да, и чем более сложное и критичное к ошибкам ПО — тем в большей степени маппится. Однозначно.
andyudol
Управление разработкой? Профессиональная литература? Хм, у меня другое представление о профессиональной литературе.
Нужно постоянно пытаться сделать как лучше, чтобы получилось хотя бы как всегда. Не получилось.