Comments 29
Управление разработкой? Профессиональная литература? Хм, у меня другое представление о профессиональной литературе.
Нужно постоянно пытаться сделать как лучше, чтобы получилось хотя бы как всегда. Не получилось.
Нужно постоянно пытаться сделать как лучше, чтобы получилось хотя бы как всегда. Не получилось.
Это вещь известная и просто шикарная. Бауманка оценит :)
Есть еще версия с пояснениями и примерами
И да… Этот текст имеет больше отношения к управлению разработкой (особенно в РКТ), чем многие модные сейчас методологии. Спасибо за перевод!
Есть еще версия с пояснениями и примерами
И да… Этот текст имеет больше отношения к управлению разработкой (особенно в РКТ), чем многие модные сейчас методологии. Спасибо за перевод!
Пунктуация что ты, делаешь ахаха. Ну серьёзно, ну нельзя же так.
И да, для переводов есть специальная галка при редактировании и даже специальное поле, в котором указывается оригинал — это позволяет проще искать и фильтровать статьи.
Примерно переводится как «Бесплатно кормят только на убой» или «бесплатно просто так не покормят».
Там же игра слов: дословно "не бывает бесплатного запуска", но launch (запуск) созвучно с lunch (обед). Полагаю автор намекал, что часто для полноценного завершения запуска изначально заложенных(или задуманных) средств не хватает и за все нужно дополнительно платить
Конечно, я даже прочитал как запуск, но если уж брать исключительно еду то «бесплатным бывает только сыр в мышеловке».
вот да, тоже показалось некорректным переводом.
КМК, речь о том, что на каждый тестовый (?) запуск требуются ресурсы — и надо очень хорошо об этом помнить при планировании испытаний, экспериментов, да и просто в разработке.
алсо не нашел ничего по «закон рэнджера», а под определение «закона Хайнлайна» подходит разве что «Никогда не приписывай злонамеренности то, что вполне объясняется глупостью; но не исключай злонамеренности»
КМК, речь о том, что на каждый тестовый (?) запуск требуются ресурсы — и надо очень хорошо об этом помнить при планировании испытаний, экспериментов, да и просто в разработке.
алсо не нашел ничего по «закон рэнджера», а под определение «закона Хайнлайна» подходит разве что «Никогда не приписывай злонамеренности то, что вполне объясняется глупостью; но не исключай злонамеренности»
Изначально фраза встречается в книге «The Moon is a Harsh Mistress». Там было про завтраки.
Ракета по сути это большая питарда, которую запускали тысячу лет назад. Где новые технологии? Законы они пишут.
петарда
Я, конечно, совершенно не разбираюсь в ракетостроении, но утверждение, что «ракета это по сути большая петарда» — совершенно неверно.
Ведь разница очевидна: петарда неуправляема, а ракета управляема.
Ведь разница очевидна: петарда неуправляема, а ракета управляема.
впринципе грустно, что до сих пор, дальние полеты производят методом пинка под зад(разогнались и по инерции).
хотя подвижки вроде бы есть
хотя подвижки вроде бы есть
Не использовать инерцию было бы весьма странно. Ведь, когда мы едем на велосипеде мы набираем скорость и перестаем на момент крутить педали — движемся по инерции. Также мы не крутим педали когда едем под горку. Совеременные велосипеды имеют «коробку передач» — тоже для экономии энергии велосипедиста. Экономное расходование энергии, одна из основных задач в конструировании средств передвижения.
Поясните пожалуйста, что вы имеете ввиду, говоря о «других» методах приведения транспортного средства в движение? Мне просто никакие другие на ум не приходят.
Поясните пожалуйста, что вы имеете ввиду, говоря о «других» методах приведения транспортного средства в движение? Мне просто никакие другие на ум не приходят.
Так себе она управляема.
erondondon Поясните, что вы имеете ввиду.
Современные автомобили — это по сути те же брички и колесницы, на которых ездили тысячу лет назад. Где новые технологии? Машины с автопилотами они выпускают…
Вы не могли бы ещё указать, кто такой этот Акин?
Akin, David
UMD, Associate Professor
Director of Space Systems Laboratory
Department of Aerospace Engineering
UMD, Associate Professor
Director of Space Systems Laboratory
Department of Aerospace Engineering
29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число Пи, и сдвиньте десятичную точку на одно положение вправо.
Надо было вот как:
29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число ПИ, и Здвиньте ДЕЦимальную точку на одно положение вправо.
Надо было вот как:
29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число ПИ, и Здвиньте ДЕЦимальную точку на одно положение вправо.
На пункте 39 что-то SLS вспомнилась
42.
Сорок два пункта.
Это специально — или случайность?
Сорок два пункта.
Это специально — или случайность?
13-й пункт какой-то спорный и мутный. Можно пример?
Есть тз. Его разрабатывали уже закладывая туда запас прочности и т.д., так что если вы в каком-то из мест проекта решите сделать лучше чем надо, просто потому что можете, вы только зря потратите время, которое вам пригодится на других этапах разработки или реализации проекта.
Есть наверное спорные моменты, когда какая-то уже отработанная технология многократно превысит какое-то из требований, не задерживая весь проект, но если это тз на высоконагруженную систему, каждый из узлов которой работает на пределе своих возможностей — это маловероятное развитие событий.
По крайней мере так я его воспринял.
Есть наверное спорные моменты, когда какая-то уже отработанная технология многократно превысит какое-то из требований, не задерживая весь проект, но если это тз на высоконагруженную систему, каждый из узлов которой работает на пределе своих возможностей — это маловероятное развитие событий.
По крайней мере так я его воспринял.
>>если вы в каком-то из мест проекта решите сделать лучше чем надо, просто потому что можете, вы только зря потратите время
Лучше всегда дольше? Иногда получается сделать лучше, дешевле и быстрее.
Банальный пример: требуется трехкратное резервирование системы, а в данном узле можно выполнять только четное резервирование для соблюдения соосной симметрии. Снижение количества узлов с 4 до 3 возможно только путем полного переделывания всей компоновочной схемы.
Лучше всегда дольше? Иногда получается сделать лучше, дешевле и быстрее.
Банальный пример: требуется трехкратное резервирование системы, а в данном узле можно выполнять только четное резервирование для соблюдения соосной симметрии. Снижение количества узлов с 4 до 3 возможно только путем полного переделывания всей компоновочной схемы.
Если от вас просят построить постую лодку, то значит на выходе должна получиться лодка, а не эсминец или лодка с элементами оного. В программировании это принцип YAGNI.
https://ru.m.wikipedia.org/wiki/YAGNI
Пункт 29 – про «сдвиньте точку вправо» в оригинале про оценки стоимости, а не времени. То-есть оценку времени умножить на Пи, а оценку стоимости увеличить на порядок.
Отлично маппится на создание ПО. Особенно мне про стыки понравилось, у нас тоже самая большая засада в интерфейсах, связывающих одну систему с другой.
Конгениально. В мемориз.
Sign up to leave a comment.
(Законы Акина) законы космической инженерии