第5部分(第1/4 頁)

�裁純�⑷嗽筆艿秸餉炊嘞鋼碌墓婢氐南拗疲��礱僑勻患ち業乇г咕�３鑫侍餑兀�

傳統的開發方式想要將工作限制到一個標準的流程上，而豐田的開發人員總是說“一事一議”。豐田人針對已知的問題，設計出一套透過權衡曲線（第3章討論）來儲存獲取的知識的方法，同時預測各種新的問題仍會出現，因此需要繼續開發相應的新的分析和測試方法。也就是說，豐田只將最少量預期到的知識加以標準化（然後要求人們保持學習的態度）。

傳統公司發現：“對於只有一把錘子的開發人員，所有的事物看起來都像一個釘子。”出現的問題越多，就會有越多的標準任務。不久，人們開始抄近路，比如照抄舊的FMEA（失敗模式和效果分析），或者運用有限元模型，但只是為了獲得一個強度資料，而不是為了真正理解應力的分佈，甚至捏造虛假的事實。這樣做的結果只能是，更多的失敗產生了！管理層開始感受到挫折，於是要求更多的交叉檢查、報告和任務，開發人員也變得更加受壓制。於是，開發流程進入了一個死結：他們越是“改進”這個流程，失敗得就越慘。

接著，傳統公司試圖從流程中消除一些任務，可是更大的災難接踵而來，因為這些任務是基於某些原因而被扣上去的。例如，NASA（美國國家航空和宇航局）的“更廉價、更小、更好”的目標導致了一系列可怕的失敗。

那麼，什麼才是有效的、精益的對策呢？如何才能夠獲得一個有條不紊的、有效的流程，而同時允許（實際上是要求）開發人員根據實際情況選用最有效率的途徑去創造知識呢？

從長期來看，你必須運用一些精益開發的核心要素：

�　建立清晰的結果責任，而不僅是跟進流程。必須先建立一個重視流動和拉動的系統，然後，才能讓開發人員興奮地把硬性的煩瑣流程從作業中移開。

�　教導開發人員如何將資料轉換成可用的知識——也就是第3章裡要討論的權衡曲線表。要求他們努力阻止問題的發生，而不僅僅是透過模擬或測試來發現問題。

�　透過對價值的關注來指導大家學習標準化——最基本的原則是，每個人都有責任按照有效的方式來工作。

在此期間，運用圖2�2中挖掘出流程上有用的資訊，同時鼓勵開發人員負起責任，用最有效的工具去獲取所需資訊。舉例說明，我們將運用流程圖，來分析和改進傳統開發工作中常用的一個標準工具——失敗模式和效果分析（FMEA）。

圖2�2創造可用知識的流程圖

書　包　網　txt小說上傳分享

分析浪費的工具：以FMEA為例

我們從最左上方開始，以FMEA回答以下問題：

1�產品或流程為什麼失敗？

2�失敗的機率是多少？

3�後果會有多嚴重？

4�有什麼計劃可以防止或檢測到可能的失敗？

5�（在有些公司）產品失敗的機率和後果嚴重性是否低於某個規定的風險水平？如果不是的話，那麼開發團隊未能透過“入門評估”。

回答以上這些問題是否會增加可用的知識？回答第1到第4個問題會增加可用知識。但是第5個問題，評估團隊的績效有點像是“畫蛇添足”，不僅沒有價值，反而破壞了有用的資訊。

沿著“否”的箭頭向右移動，我們認識到這個問題的用意是，向管理層保證產品和流程是安全的。管理層需要學習評估產品的安全性，但更好的辦法是直接觀察產品和它的效能資料，並且詢問工程師們，如何確保自己負責的那部分工作已經符合要求。

第1到第4個問題中，哪些是重要的問題？第1個顯然是。但第2個和第3個問題失敗的機率和確切的後果，只有當我們是為失敗而設計時才是重要的！最重要的問題是：

什麼導致了失敗？

在什麼條件下產品會失敗？

什麼設計條件可以防止失敗？

這些問題引導我們去尋找一個更好的、不會失敗的設計。這樣獲得準確的答案會容易得多，否則，估計失敗的機率是非常困難的，一方面是因為對於一個設計良好的產品來說，失敗的機率非常低；另一方面遵循墨菲法則（Murphy�s　law），任何可能出錯的事物都會出現（小機率事件往往也會發生）——因此一定要努力設計那些完全不會出錯的產品。

開始消除浪費

透過舉辦一些研討會和運