Guideline & DFMEA & Lessons Learned
本篇打算簡單寫寫Guideline & DFMEA & Lessons Learned，是什麼，有什麼關係？
=======================================================
背景介紹下：
作為一個汽車零部件行業的結構工程師，入門的時候都會接觸到三個重要的設計相關的文檔。分別是設計指導手冊（Guideline,下文簡稱GL），設計失效模式影響和分析（Design failure mode and analysis,簡稱DFMEA），經驗教訓總結（Lessons Learned,下文簡稱LL）
這三個文件有個共同點，都記載了和設計有關的要點，都可以提供相關的設計信息，去幫助設計者完善設計，幫助設計者規避或者減少設計風險，或者降低影響。
個人風格比較偏實用主義，總是試圖簡化自己覺得能簡化的東西。
剛開始接觸這三個文件，很煩，明明差不多的東西，難道三個不同的地方寫三遍好玩嘛？？文件就不能統一化嘛！！搞這個流程的都是XXX。（當然不能說出來。。。歷史經驗教訓表明，很多時候我才是傻。。。但是沒人可以說明詳細緣由，總覺得很難把握重點進而把一件事情執行到位。惱。）
後來我還是沒有機會找到別人告知我這這三到底是啥，什麼關係，為何都要。或者有人說了，但是我沒理解。。。
下面接正題，說明下我想明白的東西，貼出來，以供討論。
GL & DFMEA & LL三個文件各自是啥？
GL & DFMEA & LL是什麼關係？
GL & DFMEA & LL三個文件是否必須？
=======================================================
GL & DFMEA & LL 分別是什麼？
GL是一份成熟的設計指導文件
內容規範，設計要點陳述清楚，目標明確。一般作為設計的輸入文件。獨立於所有項目之外，不會在短期內因為某一個項目或者某些事件就發生改變，穩定性極高。
DFMEA是一份checklist
用於羅列記錄我們或者團隊在設計先期識別到的各種設計要點，並針對各個要點設定初步的預防和探測措施，給予一定的風險評估，方便設計過程中檢查，跟蹤和更新。因為設計本身是一個複雜而且漫長的過程，很容易就在這個過程中遺漏一些細節。但是一份合理運作DFMEA系統提供了一個保證，允許我們把設計要求以及對應的措施一個一個詳細的追蹤完善下去。精確綁定在某個項目的過程之中，伴隨項目不同具備極高的特異性，但是類似項目又具備類似的DFMEA結構和內容。
LL是一份書面化的經驗小結，或者是各種小結的匯總。
它是這三個文檔中寫法最簡單，流程最簡單，也很容易被忽略的一份文檔。
個人最推崇的的寫法是三段式寫法，包含問題現象，問題原因，問題應對措施，打開Word，一張A4圖文並茂，清晰簡潔，一頁一事，便於查看。
LL有幾個特點：
LL 的產生和運用過程不限定於某個特殊階段，例如在項目的初期的時候，可以用其他項目輸出的LL，用於檢查和提醒當前的項目，避免犯重複錯誤。在當前項目進行過程中或者項目結束的時候，會產生許多新的失效以及相應的解決方案，此時就產生了新的LL，可以輸出存檔，供後續的新項目參考使用。
不限定於特殊人員，研發工程師可以寫，製程工程師可以寫，採購可以寫，項目經理也可以寫，只要是個經驗教訓，都值得被人記錄和分享。
LL是GL的一個重要輸入來源。一份經過可靠檢驗值得推廣的LL，經過確認和細化和規範的流程釋放，即可被吸納成為加入GL，名傳千古。
GL & DFMEA & LL是什麼關係？
圖是我們的好朋友，來一張。下圖展示了GL & DFMEA & LL三者在項目里的關係流。按照項目過程中順序排列，並展示了三者與項目的互動關係。
那麼可以從上圖中看到GL & DFMEA & LL三個文件圍繞項目和產品展開運作，為其提供支持服務。順序上，一般GL是在設計前期被引用，作為項目的輸入，用於指導後續開始的設計工作；DFMEA緊跟其後，與項目需求&產品設計之間反覆交互並更新，用於梳理和識別各種設計要點，設計風險，應對措施。LL一般產生於項目各階段收尾時候，對各種經驗教訓進行匯總工作，進行存檔，提供給後續工作和其他項目參考使用。
GL & DFMEA & LL三個文件都必須？
現在換個角度，從必要性的角度來理解下這三者的意義。
LL是基礎是起源是一切。
從前肯定啥都沒有，但是設計怎麼搞？按經驗主義搞！這就是最樸素的LL，只不過書面形式較少，口述親授比較多。然後對實際案例的提煉總結和書面記錄，這便誕生了LL。GL是LL的升華。
區別於LL的最大特點，GL是對多份LL的總結和提煉，是經過進一步抽象和泛化的工具，脫離了具體的經驗範疇，不再糾結於細節產品，提煉出設計特徵，向方法論靠攏，可以說是LL 的飛仙版本。DFMEA是一份設計過程的checklist。
設計過程日漸複雜，為了防止缺漏遺失，確保設計過程完善，我們需要一份動態的checklist來作為檢查和跟蹤設計進度。大概就是DFMEA的起源。
藉此我們可以來認識一個現象：
很多小公司當然大公司也好不哪裡去，三個文檔都寫爛，甚至不全，但是項目和產品依舊能勉力運作下去，為何？具體怎麼個不好法咧：-GL寫的不好，用的不好，推廣的不好；-DFMEA只是草草一寫，應付了事，甚至純粹當成一項應付IATF16949的審核任務，有很多 的-DFMEA甚至是和設計過程獨立開來的，產品凍結設計了，然後寫一份DFMEA交差；-LL寫的也不好，各自為政，格式不統一，形式大於內容，交流分享渠道不暢通等等。但是他們的產品依舊沒有逆天爆炸，還總是能度過危機，磕磕絆絆還總是能走到結束。這裡就不得不說，某些大牛工程師的個人經驗真的很好用。三個文檔都沒有做好，但是依靠樸素版本的LL就能度日為生。由此也可見三個文檔地位關係。但是想干大事的時候，必須團隊作戰，依靠個人經驗就比較費錢費事費人品。為何？
因為放在個人腦子裡的經驗教訓有固有優勢，那就是便捷直觀，畢竟活人教程和書面文件差異挺大的，但是這對於團隊和個人的可持續成長是一個嚴重的制約。
首先是導致文檔流於形式，導致人力浪費。對個人經驗主義的依賴，會對團隊在文檔維護上的積極性產生嚴重的負面暗示：不寫也沒關係，節省了時間；我寫了沒人看，沒有產生實際作用。團隊成長基本停滯，甚至退化。導致擁有經驗的人員不停的從零開始重複同一個故事，不必要的工作負擔。流程上為了完善，還是要執行這些文檔操作，應付了事，未發揮本來功能的流程文檔，真正的浪費時間。
然後是人員的不穩定性風險，人走了，經驗就沒有了。
再然後是純人力傳播會導致嚴重的信息失真，應該比較好理解，不贅述。
最後，無法被檢索，存在各個人腦子的經驗教訓，幾乎不可能提供完善及時的檢索服務，經常發生事後諸葛亮的故事——失效發生了，有人一拍大腿告訴你早前他們遇到過並且解決過了?（你說氣不氣）。統一格式記錄在案的，允許前期就進行規範詳細的檢索，極大的減小設計風險。
個人想法，這三個文件是三個工具，小公司小團隊小項目自然可以無所謂，單純依靠個人的經驗主義，自然能做下去，一鎚子買賣，做完就撤，寫這些勞什子玩意當真就是浪費時間。
但是如果參與在規模稍微大些的公司，多個項目中，不同團隊里，這三個工具的認知水平和維護水平，基本上就是團隊設計能力和效率的天花板了。
仁者見仁，各自取捨。
推薦閱讀：