阿金的太空船設計定律

Feb 7 2011

學習處理事情的過程中,我會一直有個困擾浮現:究竟,應該怎麼做好一件事? 怎樣的解決方案才是真正地解決了大家的問題? 面對一個問題,怎麼設計一個解決方案? 諸如此類的問題,一直反覆出現,尤其是在工作的過程中。這並不是說,只有工作這件事,才會有這類的困擾,只是工作遇到的問題,比較容易客觀處理,不像家人事務這樣需要涉及很多的情感與人本情懷,這多少暗示了工作上的問題,比較有機會以比較理性的方式處理,不過這也有可能多少是工程師背景的我的一廂情願。

不管怎樣的情境(context),如何設計一個好的解決方案,是一輩子都會遇到的課題。我無意間得知了一位 Dave Akin 的教授寫的一份清單,是他數十年投入太空船設計的過程中,累積的一些金玉良言,有趣的事,這些精辟的見解,在其它地方也挺受用的。至少在我投入解決生活或是工作上的問題時,是受用的。趁著春節期間,隨意翻譯一下,練練英文好了。

Idea

  1. 任何與工程相關的事,都是與數字有關。所以呢,一個沒有涉及到數字的分析,不叫分析,充其量只是一些個人見解而已。
  2. 要設計好一艘太空船,是一件非常非常花費時間與力氣的事。這也是為什麼,我們允許一個好的設計在執行時,是可以有一些問題的,不然你永遠無法產生出一個“好“的設計出來。
  3. 設計,是一個反覆的過程(iterative process),它得一次又一次的改善,一次又一次地實驗,而不是一次就到位。而且,你永遠需要再一次地修改/改善現在的設計,不論在任何時候,這都是真理。
  4. 在最後設計階段的成果中,你之前花費大量心力的一些地方與細節,都將無可避免地全數被丟棄。學習怎麼面對這種失落,是你必備的心理技能之一。
  5. (Miller’s Law) 三個點,就可以決定出一條曲線的樣子(而不是一條直線)。
  6. (Mar’s Law) 幾乎所有的事情,都可以看作是線性的,只要你以 log 或是 log-log 的觀點去看待的話。
  7. 在設計的初期,那些努力或極力爭取想成為團隊中領導人物的,其實都是最沒有能耐也最不適合擔任領導人的人!!
  8. 在我們身處的大自然,最佳解(optimum)總是出現在中庸處,而不是偏頗任何一方的極端狀況,切記!
  9. 因為沒有充份資訊或是完整記錄,而無法開始你的分析作業,這是一個爛到透的理由,根本不足以稱作是個理由。
  10. 當你感到懷疑或有疑慮時,直接停下來做個評估與分析吧。如果遇到的是緊急狀況,得立即處理,那就憑你的第六感,用猜的吧。重點來啦,記得事後回去重新檢視整個過程,排除掉當時的混亂狀況,透過事後的一些數據來釐清與分析一些結果出來,這讓你之後遇到類似的事時,能更加胸有成足地應對。
  11. 有時候,最快找到好的答案的方式,是丟棄掉已經進行一半的成果,然後重新來一次!
  12. 記住,永遠不會只有一個正確答案的;但是呢,也請記得永遠會有非常多的錯誤答案。換句話說,不要過分依賴你認為的“那個正確答案“,或是以為“那個你之前遇到過的錯誤答案“就是唯一的一個,這個世界比你想像中的大得多了。
  13. 設計這回事,永遠都是根據需求而來的。所以呢,當你指出你的設計比需求來得好,甚至注意到一些需求沒有提到的細節這事時,是無法有效證明的。如果你注意的細節沒有寫在需求裏,那也許是我們都不關心的事!
  14. (Edison’s Law) “Better” is the enemy of “good”.
  15. (Shea’s Law) 改善一項設計,常常是發生在界面(或是使用界面),很不巧的是,這常常也是你將整個設計變得非常糟的地方。
  16. 前人針對同一個問題所做的實驗與分析,不見得就可以直接拿來用的。怎麼說呢? 一來,他們當時面對這問題時,無法預知到未來的環境有何不同;二來,他們也不見得有睿智得以猜到各種狀況。因此,你不應該相信他們的結論,更不應該直接把他們的結論拿來充作己用,而是應該自行重新重頭來過。
  17. 列印出來的分析資料,並不代表它比較正式或是正確,事實上,有沒有以白紙黑字的形式出現,都無關乎內容的正確性。(按譯:言下之意是,身而為人,還是很容易受限於一些表面的樣貌而影響觀點,這也暗示,做一些表面功夫,的確是可以騙倒一些人!!!)
  18. 經驗這種東西呀,非常適合拿來提供一些過往的事實作為佐証,這方面它非常有用。但是如果過於依靠過去的經驗,則會整個抹煞掉值得開發的事物與想法。
  19. 當你手邊的分析結果與其它人大相庭徑時,這不見得代表你比所有人都來得聰明,很可能是你哪弄錯了! 舉個例子,你的分析指出你的終端機速度是光速的兩倍,這可能代表你發明/發現了時光穿梭機,但更可能的情況是,你整個搞錯了!
  20. 一個擁有好的呈現方式的爛設計,最終會失敗;但是一個呈現方式很爛的好設計,則會在一開始就出局了 :D
  21. (Larrabee’s Law) 在課堂上,你聽到的所有東西裏頭,其實有將近一半都是無用的垃圾。所以教育這件事呢,主要是在讓你學會“分辨出那一半的能力。
  22. 當有懷疑的地方時,就記錄下來。
  23. The schdule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.
  24. It’s called a “Work Breakdown Structure” because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.
  25. (Bowden’s Law) Following a testing failure, it’s always possible to refine the analysis to show that you really had negative margins all along.
  26. (Montemerlo’s Law) Don’t do nuthin’ dumb. 千萬不要避免去做一些你覺得蠢的事!
  27. (Varsi’s Law) Schedules only move in one direction. 計畫時刻表只會往一個方向移動。(按譯:往增加或是延後的那個方向,亦即 schedule 只會發生預算增加或是時間延後,不可能減少的。)
  28. (Ranger’s Law) There ain’t no such thing as a free launch.
  29. (von Tiesenhausen’s Law of Program Management) 為了要得到比較正確的開發時程與資源需求,你可以把你一開始提出來的預估時間乘上 π (3.14159265),然後再把小數點往右移一位,這大概就是比較接近事實的資源需求。(按譯:這聽起來很不可思議,等於是把初步的時間評估乘上 30 倍左右了! 你如果真的這麼做的話,要怎麼向你的主管或上級報告呢? 我想這是另一個問題,但這的確多多少少指出了現實中問題處理過程中的複雜性。)
  30. (von Tiesenhausen’s Law of Engineering Design) 如果,你想要在一個新的工程設計中,盡可能地有最好的成果的話,那就去學畫畫吧!! 工程師總是在最終,設計出與一開始藝術家畫的概念圖很像的 vehicle 來!!
  31. (Mo’s Law of Evolutionary Development) 你無法只靠接連地爬上愈來愈高的樹而最終到達月球。(按譯:這說明了沒有搞清楚問題與解決方案之間的根本差異與限制所在。)
  32. (Atkin’s Law of Demonstrations) 如果設計出來的硬體運作得非常的完美,沒有任何狀況,那表示你根本沒有請出一位真正的使用者出來,而只是自個兒在那邊測試得很高興而已。(按譯:請多多想想 Eat Your Own Dog Food 這件事。)
  33. (Patton’s Law of Program Planning) A good plan violently executed now is better than a perfect plan next week. 與其等到一個非常完美的設計出現才動工,不如在現在還堪用/還不錯的設計藍圖中開始,然後一步步改善。(按譯:再次強調了 waterfall model 的不切實際與 iterative model 的重要性。)
  34. (Roosevelt’s Law of Task Planning) Do what you can, where you are, with what you have. 因時制宜。
  35. (de Saint-Exupery’s Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
  36. 任何一個平庸的設計師都可以設計出一個典雅(elegant)的作品出來;一個好的設計師則是可以讓系統變得有效率(efficient);而一位非常優秀的設計師,則是把系統設計的有用(effective)。(按譯:這實在是個值得玩味的觀點)
  37. (Henshaw’s Law) One key to success in a mission is establishing clear lines of blame.
  38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.
  39. The three keys to keeping a new manned space program affordable and on schedule: 不要試圖重新造輪子(don’t re-invent wheel)
    1. No new launch vehicles.
    2. No new launch vehicles.
    3. Whatever you do, don’t decide to develop any new launch vehicles.
  40. Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there’s no partial credit because most of the analysis was right…)

PS. 隨後即發現,我的英文還是一樣有待改善呀…

PS2. 整篇最滿意的,就是挑了一張 CC 版權的 flickr 照片 ^^;

comments powered by Disqus