說說設計：我曾經是個機械設計師，也帶過團隊

myth2000

我曾經是個機械設計師，也曾經帶過設計團隊，或者今天我的工作離機械很遠了，但骨子里，我一直都還是個機械設計師，估計不論多少年，這點不太會改變。

看到好友提了這個問題，那我就分享下我的想法。

還是從字面上來看，機械設計，何謂設計？

設就是從無到有的過程，計就是復核校驗，合在一起，所謂設計，就是一個按照某個要求從無到有并且經過驗證校驗過，符合全需求的整體過程，是對一個需求的統籌規劃的過程。
那么所謂設計，其實就是在談怎么去滿足客戶的需求。

為了方便說明，我簡單畫了張圖來解釋一個設計的需求是如何被滿足的。

為了偷工減料和節省時間，我把項目經理和產品經理以及決策點放在了一起，從規范的角度來說這是錯的，請細心的朋友不要把這個問題放大，這只是我偷懶的做法，不想這張圖太夸張（同時也為了防盜版），而圖中的流程和活動大致是正確的。
項目的階段劃分也被我盡可能的精簡過，以適合大部分的制造企業。



這只是需求傳遞的過程，其過程中涉及到了整個開發設計開發的整體流程，這里就不詳述了。

一個設計從最原始的需求開始，需要被業務部門審核，迭代，確認技術可行性，財務規劃，預算分析等等一系列的過程。
需求收集是一個漫長和負責的工作，我們可以借用KJ，頭腦風暴，腦力書寫法，德爾菲法，強制連接法，奔跑法則，Blitz等等方法來進行收集。

做出立項并完成一個產品設計必須要滿足這樣幾個條件：
1.符合公司的策略（要么財務上的直接受益，要么戰略上某個部署的實施）
2.風險是被識別，而且有可控的風險應對計劃
3.企業有足夠的資源來完成項目
4.確保業務是真實的
5.確保我們是可以拿下這個業務的
6.我們做這個業務是值得的（這屬于項目組合管理的范疇，不展開了）
以上的最后三條是常規問題，就是Real, Win, Worth，這是項目決策的基本要素。

當決策機構確認了需求，并決定投入資源去開發設計這個產品之后，那所有的需求都應被匯總在一份文件中，由于原始的需求是難以識別的，甚至是非常寬泛和籠統的。產品和市場部門是有義務將需求轉化成企業內部可識別的語言的，這樣的一份文件我們可以稱之為產品需求文件PRD。

而從原始需求到PRD的轉換也是一個痛苦的過程，可以借用質量功能展開QFD1.0來完成，通過矩陣式的掃描來獲得工程部門可識別的需求。
而這時，項目經理也可以根據被轉換和識別過后的需求來定義項目計劃和工作結構分解WBS。
那所有WBS確立完了之后，相應的工程師才會接到相應開發設計的指令，以及明確的開發目標，這些目標應該是與PRD中的描述是完全一致的。而且按現在質量學和項目管理的理念來說，我們并不需要提供超出客戶期望的功能和服務。

要開始真正的產品設計，之前應已完成概念設計，這是一個高度概括和粗略的整體規劃。只有當這個概念設計被客戶充分認可之后，才能開始后續的設計。（哪怕是主動開發的產品，也一定是先做過市場認可度的調查，才能開展后續的工作。）

在設計工程師開始詳細設計之前，應先完成DFMEA，FMEA作為一種風險預判斷的工具，應成為產品的的指導性文件，并確保產品設計時充分考慮了實際使用的狀態，并作出預判斷和預應對。同時，從PRD或者QFD1.0也可以得出產品設計的大綱，成為后續設計的重要指導。

在產品的詳細設計時，應充分考慮客戶的需求被滿足的情況，以及各種極端的可能性，很大程度上CAE的分析正是基于這樣的一種理念。所有的CAE模擬都應與DFMEA中的描述，以及PRD中的需求描述一致。

DFMEA可以成為PFMEA的重要輸入，但不是強制輸入。FMEA是一種結構性的工具，是可以參考歷史資料的，尤其是PFMEA，對于一個成熟企業來說，是積累了大量的經驗的。在沒有DFMEA的情況下，依然可以制作PFMEA。這份文件將成為產品設計最終實現的重要依據，也是后續各種生產制造的基礎文件。而如果我們繼續沿用QFD的話，這里QFD3.0將成為PFMEA的另一大重要輸入。
所有的工藝細節以及流程，均應以滿足并且實現客戶需求，不損害客戶利益為前提，而不是以自己的便利性為導向。以確保產品設計的意圖被100%實現。

所有的設計都免不了驗證(V&V)，無論是verification還是validation都在證明一件事，那就是客戶的需求是滿足的，而且是可以很好的批量生產制造出來的。控制計劃CP和質量檢驗計劃QIP，還有各種WI,SOP等文件，幾乎所有的生產用的文件，都是為了這個目的而存在的。

只有這一切都和最初的PRD中描述的需求是完全一致的，而且是符合企業量產能力的，那我們才能說我們的設計完成了。
這時，最終的產品規格書PS，才算是定型下來。最后依然要再回過頭去，檢驗最初的需求滿足情況。

一個需求是需要閉環控制的，以確保需求在傳遞的過程中，沒有發生重大的偏差，我們不喜歡任何的驚喜。

至此，我們才能說一個設計完成了。

簡單說，我們要把客戶籠統的需求，變成一個實際工程可識別的語言，轉化成可量化的設計指標，然后由設計師按這個設計指標設計出實際的產品，然后進行相應的風險評估，然后通過設計驗證確保設計是可用的，且是可以被批量生產出來的，最終再與客戶的指標進行相互匹配的全過程。

其實一個設計，就是一個項目，回到項目的定義：在一定時間內為了某個特定目標所完成的產品，服務或者流程。
那么項目的所有的屬性也就是一個設計所需要考慮的因素。
套用PMBOK的說法，范圍，進度，成本，質量，人力資源，風險，溝通，采購，干系人，甚至更多的要素統統都是，最后整合在一起，也就成為了一個設計。

如果在一個設計工程師眼里，他只看到了一個產品一個功能，或者當前一個特定的設計活動，那他永遠就只是一個底層工作人員。前幾天我們在聊如何跳出平庸，這里其實就是一個例子，希望每個人都能清楚的知道自己在設計環節里的位置。或者今天你只是在做其中的一件事，但只有你知道了全貌，才能憧憬自己未來的發展。

設計也好，別的工作也好，做到后來，都歸結到了兩個詞上面：Methodology & Philosophy.
也就是系統方法論和理論哲學的問題，這幾天老鷹也提到了技術哲學，這是非常好的思考。

最后之所以強調方法論和哲學，是因為一個人的創造力是有限的，我們不指望我們都是天才，那如何通過有限的才華來創造無限的可能？那就是方法論和哲學能帶給我們的了，當你熟知設計的全流程，熟知設計的要素和精髓，那哪怕你的所學有限，但你可以通過對經驗的歸納和總結，通過不同的排列組合，然后找到問題的新解法。
典型的方法論就是Triz，一種簡單但實際的傻瓜式創新方法，已經被普遍的用于產品設計領域了。

@十九子
丫頭，我不知道我是不是回答了你的問題。

ryeee

很厲害的樣子。。。

愛貓人士薛定諤

專業詞太多了，門檻略高，看不太懂，

dukaijixie

蠻厲害嗎！

459827194

專業性太強，貌似不符合國情哦

G766115

補充一點：
如何做到設計考慮的全面呢？我的做法是做檢查清單，把需要考慮的因素都列上去（當然這些因素會不斷增加）。設計評審時，一項一項的過，看看漏了哪些要素。

k-xiangang

講的不錯；有內涵。

舞飛揚

寫得很贊！

咸Yu菋

大公司的做事習慣，小公司耗不起啊

梅子2014

樓主一如既往的贊