文｜唐納德‧高斯（Donald C. Gause）、傑拉爾德‧溫伯格（Gerald M. Weinberg）

譯｜褚耐安

 

　　芭芭拉、賴利和泰德準備前往白堊洞穴，與低價粉筆公司再次開會。「雖然我們的需求要件作業還沒有全部完成，」芭芭拉說：「但我們帶一些設計概念去開會，或許是個不錯的主意……」她頓了一下，似乎有些得意，然後繼續說：「……可以和客戶拜倫商討一些重點。」

 

　　泰德和賴利沒有答話，芭芭拉繼續說：「總結目前我們知道的，我畫出前一次會議訂定的解決方案空間。我認為，A點和B點是超級粉筆兩個可能較有意義的設計。你們認為呢？」

 

　　讀者們：繼續閱讀之前，試著選擇圖中的A點和B點，哪一個點是超級粉筆的較佳形體，並說明原因。

 

 

　　「我認為A點比較好，」泰德說：「它比較細，因此耗用的材料較少，可以降低生產成本。」

　　「不，我認為B點比較好，」賴利反駁：「粗的粉筆看起來比較『超級』，可以賣得更好，創造更多利潤。」

　　「不見得，」泰德說：「利潤是營收減去成本。即便營收增加，也可能被高成本吃掉。」

　　「我認為你不了解粉筆這門生意，」賴利說：「光說一件事。包裝占了成本的一大部分，而細的粉筆容易折斷，造成損失。增加一點材料只增加一點成本，但是不容易折斷，也就是說退貨率會比較低，利潤會比較高。」

　　泰德望向芭芭拉，似乎有些沮喪：「芭芭拉，妳是資深設計者，妳認為呢？」

　　「我認為，」芭芭拉說：「你們兩個都需要再上一堂需求要件課程，課程名稱是偏好。」

　　「什麼是偏好？」

 

　　定義偏好

　　偏好（preferences）即是選擇性地較喜歡某一項特性。只要是可滿足每一項限制的成果，都是可接受的解決方案；但某項可接受的解決方案比其他方案更受到喜愛。偏好使設計者得以比較各個可接受的解決方案，並選出較好的一個。

 

　　我們就像眾多設計者一樣，只要能達臻特定水準，即不願意多花一毛錢改進解決方案。只要我們能不多花額外的錢，我們願意考量每一項已知的偏好。

 

　　譬如，假設電梯資訊裝置的客戶表示，「彈性提供資訊」是他偏好的特性之一。我們必須以客戶的期望的相同方式，陳述這項偏好，並說明其中的數量關係。譬如：彈性提供資訊：這套系統提供的資訊可以有最多的形式和格式控制。因此，大樓管理單位透過諮詢經常搭乘電梯的人，可以決定並調整這項裝置提供資訊的形式。如此，電梯資訊裝置可以經由專人控制，以提供符合乘客需求、習慣、文化的資訊。

 

　　如果沒有這段定義，許多人會以為，所謂彈性，即是任何人都可以改變資訊的格式。這段定義明確指出，不是由客戶，而是由專家來負責為使用者調整資訊。

 

　　偏好的來源

　　現在，我們來考慮芭芭拉問泰德和賴利的問題。A和B兩種超級粉筆，哪一個比較好？於需求要件作業階段，正確的答案是：我們不知道。果然，他們去開會的時候，拜倫表示：他偏愛解決方案空間裡，位於A點和B點上方，界於兩點之間的第三點。

 

 

　　「如果粉筆適用於標準的粉筆套，會有利於行銷。」拜倫解釋：「但如果比普通粉筆稍長一些，可以讓人有『超級』的感覺。」

 

　　這段故事的意義非常簡單，而且每一個設計者都必須牢記：

　　客戶才能有偏好，設計者沒有。

 

　　但設計者常常忘記這一點，尤其是客戶經常不知道自己有所偏好──除非設計者提供選項，要求客戶選擇。

 

　　讓偏好可以度量

　　偏好的效用，在於引導設計者滿足客戶。因此，除非偏好能以數量方式表示，否則設計者無從知道，他們滿足客戶偏好到何程度。

 

　　許多文章討論衡量基準（metrics）──即度量某項特性的數量單位──的重要性，卻都沒有觸到要點。請記住，就像我們先前說的：基準本身並不重要，重要的是「訂定基準」的過程。訂定度量每一項偏好的衡量基準非常重要，因為這個思考過程可以幫助每一個人確實了解，自己到底偏好什麼。

 

　　訂定衡量基準時如果遭逢瓶頸，請暫停腳步。首先，檢查是否有兩項或數項偏好混合為一，這種情形將使訂定基準發生混淆。將所有提出的衡量基準各繪製在一張表格上，然後逐張問：「這個基準度量的偏好，名稱是什麼？」你將得到許多相類似的答案，表示其中存在幾個相類似的偏好。如果這樣做還不能解決問題，成立一個獨立工作小組，負責稍後訂定這項基準；然後討論度量下一個偏好的基準。

 

　　請注意，於早期階段，你可能無法提供精確的度量方式。事實上，你無須要求過度精確，以免增加需求要件作業的負荷。但是，朝這個方向努力，對於最後的設計成果必有加分效果。度量產品特性使設計者能將彈性提供資訊以及以多種感知方式顯示資訊這兩項偏好極大化，並符合其他各項限制，於解決方案空間內進行探索。

 

　　區分限制與偏好

　　產品特性一定有限制；對於產品特性的偏好，則是客戶期望解決方案更優質的心態。我們以下列故事，說明這兩個概念的不同：

 

　　有一次，傑瑞的律師赫伯特（Herbert），開車載他到紐約鬧區去談幾個合約。到達會晤地點，律師將汽車停在「嚴禁停車」的標示牌前。傑瑞指指標示牌，赫伯特聳聳肩說：「我可能會被開罰單，也可能不會被開罰單，機率五五波，而罰款是五十美元。所以我認為，這個停車位的費用是二十五美元。根據這個計算方式，我們倆在這附近都找不到更便宜的停車位了。」

 

　　對傑瑞而言，「嚴禁停車」是一項限制：他不可以在這裡停車，此事與費用無關。對於赫伯特而言，這卻是個偏好：想辦法將這趟出門的總費用降至最低，包括停車費與律師鐘點費。特性本身不會告訴我們，它是一項限制或一項偏好。

 

　　唯有客戶的恐懼或期望的強度，能判定是限制或偏好。

 

　　進度表是不是限制？

　　為了顯示區別限制與偏好的重要性，我們再一次複習，上一章提到的完成系統設計的最後期限的例子。對團隊成員而言，十一月一日是一項限制；對老闆而言，卻只是一項偏好，而且是溫和的偏好。

 

　　如果我們說，某些開發案的完成期限是限制，但其他專案的完成期限是偏好，恐怕有許多人會大吃一驚。但有些時候，完成期限既不是限制也不是偏好。讓我們來看看，如果判斷錯誤會發生什麼後果。

 

　　一套統計美國總統選票並公布結果的電腦系統，必須於兩年後十一月第一個星期一之後的第一個星期二之前，完成作業準備。如果不能按照期限完成，就要再等四年。這個例子裡，符合完成期限顯然是一項限制。

 

　　一套提供每月營業額的電腦系統，如果能在下個月之前完成，很好；但並沒有要求在下個月完成。如果我們三十年來不曾使用這套系統，業務仍然蒸蒸日上，那麼多等一、兩個月顯然無關生死；但有些人卻認為這是生死大事。

 

　　許多開發案因為無法區分，進度表究竟是限制還是偏好，因而飽受驚嚇。如果團隊成員誤以為最後期限是一項限制，於是因為趕工犧牲了品質，最後，這項品質低劣的成果無法通過測試，專案因而「延遲」。然後，他們發現最後期限並不是限制，因為客戶同意「延遲」交貨。

 

　　許多畢業於較散漫大學的程式設計師或電腦工程師，通常難以區分進度表是限制，或偏好，或僅僅是裝飾品。他們進入社會後仍然保持散漫的習慣，使得許多公司的經理人相當沮喪──沮喪的後果是，經理人將每一個專案的完成期限都列為限制。如果經理人能與這些社會新鮮人充分溝通，明確告訴他們專案的完成期限是限制或偏好或裝飾品，就不會那麼沮喪了。

 

　　受限制的偏好

　　限制使你能夠區分解決方案與非解決方案。你可能獲得符合限制的解決方案，或找不到解決方案。相對地，偏好則是你永遠覺得不夠。因此，偏好有一個最大的危險：貪心。

 

　　如果有一件事比設定不恰當的時限還糟糕，那就是設定不恰當的偏好時限。譬如，你被告知必須在七月一日完成系統設計。於是你擬定計畫，動手設計。但之後你又被告知，你必須愈快完成愈好。這種設定期限方式，你如何判定自己的工作成效？如果你在六月一日完成系統設計，或許你也能在五月十五日……或八日……或七日就完工。

 

　　顧問永遠有辦法辨識，專案是否緣起於未受限制的偏好的情境：只要觀察是否有極度驚恐的氣氛。如果你希望擺脫驚恐，至少某些時刻，你必須學會如何對客戶的偏好設置限制。

 

　　運用解決方案空間圖，與客戶討論限制的目的，成效會相當好。方法是由你指出解決方案空間內的幾個點，並與客戶討論他們對這些點的感覺。聆聽他們的感覺，你將能繪出他們不願意搏命達臻的解決方案空間區塊。圖17-2顯示，BLT設計公司與拜倫討論之後，繪製的解決方案空間圖。

 

　　所值幾何圖

　　另一個限制偏好的更好方法是，用一個函數，說明偏好水準與對應於此偏好水準必須支付的代價。我們稱為所值幾何（what’s-it-worth?）函數，或所值幾何圖。即顯示「我們要求這套系統，能使取樣人數中至少百分之三十，以多種感知方式接收資訊。我們希望效果能更好，但不指望比率超過百分之九十。」這個陳述的兩種可能的函數。

 

 

　　圖17-3的兩條線都符合文字敘述，但兩者迥然不同。偏好#1表示，於百分之三十這個點，多種感知特性突然變得有價值，但百分比繼續增加，這項特性的價值卻增加不多。偏好#2表示，多種感知資訊於百分之三十這一點的價值很小，但此後迅速增值。

 

　　按照偏好#1設計，與按照偏好#2設計，兩者強調的重點不同。如果不繪製所值幾何圖，以釐清顧客對這項偏好的評價的話，設計者只好用猜的。由於這兩條偏好函數，只是千萬個可能評價方式其中之二，猜對的可能性可說是微乎其微。

 

 

 

　　所值幾何圖是化解貪心的特效藥。不畫這張圖，設計者可能會犧牲其他偏好，以盡可能滿足單項偏好。盡力滿足單一項偏好的企圖發揮到極致，就成為設計者最可怕的毛病：力求完美徵候群（optimitis）。

 

　　產品開發第零定律

　　你現在應該很容易了解，區別限制與偏好為什麼如此重要。當所有的功能─特性限制都已獲得滿足，才能考慮偏好。換句話說，當我們已處於解決方案空間中，才能開始進行關於偏好的作業。偏好指出，在解決方案空間裡，哪些方案較受喜愛。如果贏得冠軍是一項限制，那麼就不需要考慮：我們的車是否在預賽中跑得最快，或大多數時間領先，或擁有最多贊助者。

 

　　如果無須贏得冠軍杯，設計賽車的工作就簡單多了。這就是產品開發第零定律：

　　如果無須符合客戶指定的限制，則產品可以滿足其他任何需求要件。

 

　　如果某電腦系統無須執行客戶指定的功能，則可以使用任何程式語言，可以跑得非常快，而且製作成本非常便宜。由於它不符合限制，就客戶的觀點而言，這個電腦系統毫無用處。它可能只是一個沒有功能選項的輔助器──速度快、便宜、可使用任何程式語言。

 

　　第零定律不只用來形容開發電腦軟體，也適用於任何產品開發。切勿讓偏好偷偷變成限制；反之亦然。

 

　　如同產品的限制，每一個偏好的最終定義必須完整、一致、準確，以終結（或避免）產品滿足偏好到何種程度的爭議。我們知道，這種準確性不可能由一大堆人在大會議室中討論達成。於需求要件作業早期階段，你必須確認所有的偏好，以及各個偏好衍生的重要事項。然後，草擬偏好的工作，可以打散成幾個子工作，分配給適當的小團隊處理。初稿完成之後，再匯整起來，由具有代表性的大團隊進行技術審查。

 

　　許多設計案設置的限制過於嚴苛，使得隱含的偏好變成：「找到任何符合限制的解決方案，即大鬆一口氣，結束專案。」限制過於嚴苛的症狀之一，即是草草結束對於偏好的界定。請學會察覺，團隊成員希望草率結束界定偏好的壓力。何謂草率？如果某個專案的開發期間是一整年，花一兩天討論偏好算是相當合理。

 

　　向客戶提出下列警語：你或許想把所有的特性都說成偏好。由於天下沒有白吃的午餐，設計者就會根據他們自己的隱含偏好做決策。這些偏好隱藏得太好，連設計者自己都無法察覺。最糟的狀況是，設計者告訴你：「沒問題！」然後代你做決定。

 

　　你可以運用「柳橙汁測驗」，以避免這類暗中做手腳的設計者。「柳橙汁測驗」源自於選擇召開大型會議的飯店，可用以測試旅館業者的服務品質。方法是，你提出一個不合理的要求，聽聽對方的反應。譬如你要求在早上七點鐘，提供七百杯現搾的柳橙汁。如果飯店的人回答：「沒問題！」那就表示他們將讓你大失所望囉。

 

 

 

 

書籍資訊

書名：《從需求到設計：如何設計出客戶想要的產品》（十週年紀念版） Exploring Requirements: Quality Before Design

作者： 唐納德‧高斯（Donald C. Gause）、傑拉爾德‧溫伯格（Gerald M. Weinberg）

出版：經濟新潮社

日期：2017

[TAAZE] [博客來]