就拍板定案。

這個團隊也許永遠不能發現他們所選的概念設計方案是否恰當，只能在專案結束時看到結果，但往往事與願違，選擇的概念設計方案並不夠適用，因此不得不匆忙地嘗試其他備用方案。最可能的情況是成本增加了，質量必須妥協，時間也超過了計劃。

圖2�8傳統的開發流程

“順序而下”（waterfall）和“V”型開發流程首先設計整個系統，然後再設計其子系統。這種方法允許進行相對獨立的子系統設計，但意味著阻礙了子系統之間的銜接。在系統設計中，關於子系統之間介面的關鍵決策，往往建立在舊資料的基礎上。

結果，最終的設計通常是扭曲的，一些子系統過於死板，很難靈活調整，而另一些子系統又不足夠穩定可靠。這樣經常使得這些部件或製造系統在以後的開發中較少能夠被再次利用，如圖2�9所示。

圖2�9V型開發流程

很多公司透過投標程式選擇供應商。這意味著招標方需要首先發布產品效能引數，如果不使用圖樣的話，很難發現哪些供應商真正有能力做到，也不知道什麼樣的系統設計和部件效能引數是真正可行的，只能根據承諾——也就是報價——做出選擇。根據我的經驗，過於依靠承諾是一種美好的想當然的情況，也就是這裡說的“主觀臆測”。如果供應商實際虧錢的話，他們經常透過一些變更來要求重新談判合同。

大多數人都不喜歡不確定性，因此經常做出一些不成熟的決策以減少不確定性。豐田公司的一位高階經理曾說過：“我的工作之一是防止員工太快地做出決策。”進一步說，人性的本能是尋找一個更廉價、更簡單和更快速的方案，而不是尋找多個備用方案。這通常是錯誤的，因為在早期尋找多個備用方案通常比後來盯住少數幾個備用方案的做法要節省經費。但是很多人不願意相信：“永遠都不會一次就完全做對，總是可能需要從頭再來過。”

圖2�10主觀臆測示意圖

在時間進度圖（見圖2�10）上，我們看到：

�　預先研製在有盈利的證據之前，就選擇了一個基本的開發概念方案。

�　銷售部門在證明顧客的效能引數是否可以實現之前，就接受了專案。

�　產品開發部門在有證據表明產品是可以製造出來之前，就選擇了一個產品設計方案。

向主觀臆測挑戰

在你的流程圖上標註出主觀臆測，然後張貼出來。

任何時候當某人告訴你某個問題是由X導致的，你就問：“你還考慮了其他什麼可能的原因？你收集了什麼資料來排除其他原因？”

任何時候當某人說“我將要做A”時，你就問：“你還考慮了哪些其他方案？你收集了哪些資料去排除其他方案？”

分析過去有缺陷的專案，估計主觀臆測對公司造成的成本浪費，並公佈出來。

一旦可能的話，儘快實施以多套方案為基礎的並行工程，用第3章裡的“問題解決表”進行培訓。

限於效能引數的測試

為什麼在開發過程中要對產品進行測試呢？為了確保滿足效能引數的要求，做好投放市場的準備。

以上是標準的傳統做法，也是一種主觀臆測。按效能引數進行測試，並不能證明產品已經可以投放市場了。為什麼？從統計學上講，有限的測試永遠不可能確保產品的質量。萬分之一的缺陷經常會毀滅一個產品，但是你不可能拿一萬個樣品就每一種可能的失敗模式進行測試。因此透過效能引數測試的設計仍有可能會面臨失敗。

一個精益的開發系統主要是為了發現失敗點而測試——而設計是為了遠離失敗。將失敗點在權衡曲線上記錄下來，這將指導整個設計。