研發初期制定設計驗證計劃－生活的希格斯實驗室 (已移站)

因應商業模式快速化的今天，實在很難看到一個專案可以好好從品質、資源、預算、風險等計劃開始做起。往往是在計劃階段就已經在做執行面的工作 (專案管理流程)。

例如，明明還在報價階段；蒐集並評估各項風險和要求；就已經在執行設計面的工作。這種變態的專案流程已經被視為常規，明明品質目標和風險還沒進行過相當的評估，卻已經把整個設計完成了八成。
等到正式進入執行階段，才在反覆驗證中發現品質目標無法達標、召修損失可能遠比預期高等因素，回頭修正設計。狀況好的只是造成更多的資源浪費，壞的狀況則是浪費資源還無法達成目標，造成雙重的損失。

設計驗證也常成為這種怪異商業生態下的犧牲品，沒好好進行過風險評估就喊出來的驗證計劃，對品保團隊來說只是不停撞牆而已。測了都過，但上市後的客訴量就是超過預期。

尤其是有特殊設計的產品，經驗少，品質目標不容易掌握，設計驗證的計劃就必須更謹慎去制定。

在這種生態下的設計驗證計劃沒有資源讓品保團隊先做好研究和評估，驗證條件只能尋求其它類似的經驗去進行規劃，甚至是像在集中市場拍賣一樣，你喊我喊，喊出一個雙方滿意的數字。

專案照這樣跑下去，等客訴回來了才知道測試計劃不充足已然太慢。
品質不能總是等測試完的結果才決定，或講深入點，不能等使用者幫你測了才知道好壞。

2000年，Howard Schultz 離開Starbucks CEO的位置，Starbucks 在後繼的兩任 CEO 帶領下擴大營業規模，但來店人數和獲利數字卻節節下滑。
2008年，Schultz 重返 Starbucks 擔任 CEO，帶領企業重新再找回自己的價值、增加社區互動、提高顧客的認同感，塑造 Starbucks 的「Coffee experience 」再造企業成功。

政大科管所李仁芳教授就認為Schultz再造成功的關鍵在於讓Starbucks的價值重回「人本精神」。
用白話一點的方式，我會解釋為「品質由經驗出發」。
如果把決定品質的方式分層，大概會分級成以下的狀況。

品質決策的等級

總是要等看到製程良率太低、測試有問題才願意正視品質問題，就是最低的品質觀念。Starbucks 從客戶經驗出發，重新打造咖啡品質文化，是高境界的品質概念。

就品保觀點而言，有特殊設計或需求的產品在設計初期即早進行使用者研究，從UX出發進行風險評估確實有其必要性。

有個專案的目標市場和作動設計都較少見，但專案還沒進行評估和研究就開始執行設計和報價，針對這個特殊設計的測試計劃客戶已經給出了條件。

這個部件在實際上使用是屬於連續操作的行為，客戶的營銷專業人員依照其目標市場使用者和行為進行評估，保固期內使用者的操作次數為20,000次。

原本在和客戶端的討論中，我司提出要求希望能夠先進行評估和研究再決定測試條件，但客戶根據Marketing提出的數據將測試標準定為每階段兩個樣品數、各必須完成20,000次連續操作的條件。

在缺乏類似設計經驗可以參考的情況下，直接使用小樣本數的設計驗證計劃是十分危險的，因為小樣本數測試是基於貝氏定理的應用，將過去設計經驗的有效度最大化。

這個部件一個樣本完成20,000次的測試就必須花掉五天的時間，加上不同供應商的材料，每次完成全部驗證就需要20天的時間，考量經濟因素，再增加測試樣本數或測試次數都會嚴重影響開發時程和人力。

在這種狀況下，品保人能做的就是審查測試條件的合理性，從風險管理的角度去提升品質層級。

我們可以暫時把這個驗證計劃視為客戶依據既有經驗設計，在成本考量下，測試到20,000次就停止的狀況。品保的工作是必須鑑定出這個測試結果達成原始設計目標值的機率。
由於部件屬於連續操作的失效，可視為服從指數分佈，預設幾個設計目標值來進行評估：
指數分佈的可靠度為

λ = 1/θ = 1/MTBF
1. 依據以往的設計經驗，設計的目標值為 θ1 = MTBF1 = 1/λ1，研發人員達成這個設計值的信心度至少有85%
2. 若漏失了一些重要因素，設計值 θ2 = θ1 * 50% = MTBF2 = 1/λ2
因此我們可以利用貝氏定理來評估不同設計值對兩個20,000次樣本的達成率

MTBF對照測試結果(2樣本通過)

選擇信心度較高95%的結果來看，兩個樣本測試通過較可能代表的MTBF設計目標值落在3~40,000之間。

依客戶端Marketing提出的研究數據，這產品在保固期內使用者預期會進行20,000次的操作，接下來品保就必須評估在這樣的設計值下，實際市場上使用20,000次後整體累積的失效率到底有多高。
累積失效率 F(t) = 1- R(t)

20,000次使用後的累積失效率

數據顯示，在保固到期前一刻，這個產品的累積召修率會有40~50%這麼高，保固過半時召修率就會到四分之一。
即使是再堅強的品保人面對這種客訴量也會崩潰的，很可能會因為召修率過高被客戶端要求改善設計，又再花一次設計變更的費用。

前面已經提過，增加樣品數或測試次數的做法在目前專案規劃的時程和人力資源下是缺乏執行可能的。
因此我們只好設計 TTF (test-to-fail) 來做進一步驗證。

由於資源的限制，TTF 儘只做一個樣本，而測試條件的合適性則先分別30,000、40,000 & 50,000 來做比較。

增加TTF測試設計的涵蓋度

數據顯示的是一個樣品測試通過 TTF 的機率，以花費資源及成效來看，30,000次的 TTF 是具有最佳的 C/P 值，但對於這個條件能涵蓋的預估風險仍然太高。50,000次 TTF 花費資源最多，但效率只比 40,000 次的 TTF 來得高一點點而已。考量最適成本和效率，大概是 40,000 這個條件最好了。不過，即使 TTF 測試通過，品保對保固到期的失效累積信心度還是有14.3%這麼高，感覺很不踏實啊......

本著風險評估要仔細的精神，我們再做更進一步的比較。
如果這個設計在第一階段的測試中，兩個樣本都通過了20,000次的測試，其中一個樣品又通過了 TTF，那產品進入下一階段試產驗證時，這個部件基本上不會有任何的變更。
第二階段的驗證再有兩個樣本通過20,000次測試，其中之一又通過 TTF 時，總計TTF測試通過樣本為兩個，設計信心度就可以再提升。

再增加一個TTF的信心度數據