書摘《從需求到設計》
前言
如果你不瞭解自己所說的事，即便你遣詞用字精確，也毫無意義。 p. 27
不值得做的事，就不值得把它做好。 p. 29
第一部 先有一點共識
多年來，我們在全世界許多軟體開發組織裏，證實了這一點。而且我們發現，客戶很難說清楚需求要的情況，不僅在軟體開發領域發生，在每一個為他人設計或建造產品的場合都會發生。 p. 32
1 光有方法，還不夠
正規方法最容易處理的問題，可以迅速被解決，但剩下來的瑣碎 (messy) 問題，則無法運用正規風法來解決。 p. 37
從事產品設計和系統設計多年的人，在他們的日常工作中，已發現到這個問題。他們覺得，用於處理技術性工作的時間愈來愈少，用於處理人與人之間關係的時間愈來愈多；用於細微末節工作的時間愈來愈少，大問題則似乎永遠處理不完。 p. 38
一個好的表示法的重要特質是容易修改，而且不影響需求要件作業的順暢度。我們不希望圖表的應用過於僵硬，以至於更改圖表變得麻煩。 p. 40
一張圖最重要的特質，即是讓每個人都可以看得懂。 p. 40
地圖和實況不符合時，以實況為準。 p. 42
務必記住，客戶只是不懂設計程序，他們在自己的領域可是專家 (而專業設計者通常不是)。因此，客戶的參與是必要的。 p. 45
使用最終產品的時候，我們不在乎它是否被正確轉化，只在乎我們是不是喜歡這項產品。 p. 47
2 需求要件語意曖昧
即便需求要件陳述得很清楚，仍然可能使用語意曖昧的字詞。譬如，「小」這個字並沒有明確指出這個團體得規模。 p. 52
探索者必須做下列動作：
- 朝某個方向前進。
- 觀察他們發現的事物。
- 記下發現的事物。
- 以先前對於目的地預設的觀點，分析所發現的事物。
- 運用所記錄的資料和分析的結果，選定新方向。
- 回到步驟 1，繼續探索。 p. 57
3 語意曖昧的原因
根據我們的經驗，造成多種答案的原因有四：觀察錯誤、記憶錯誤、解讀錯誤，以及題目語意曖昧。 p. 65
對於同一件事物，不會有任何兩個人認知的內容完全相同 (觀察錯誤) 或完整無誤地保存所觀察到的內容 (記憶錯誤)。 p. 66
取走敘述需求要件的文字資料，要求參與者根據記憶，寫出需求要件內容。記憶內容不同之處，即是原始資料的語意曖昧之處。 p. 71
4 直接詢問法的侷限
如果你希望成為一個能力高強的設計者，最好嫻熟直接詢問法，以及直接觀察法，以及一般的問題技巧。 p. 73
決策樹上的每一片樹葉都是正確的解決方案，但大多數樹葉都是對於錯誤問題的正確解答。換句話說，每一片樹葉都是一個解決方案，但大多數樹葉是不被接受的解決方案。 p. 75
不幸的是，導致錯誤設計決策的錯誤假設，通常集中於樹根部位，但卻是在靠近葉片時才容易被發現。這個是為什麼我們在設計程序的初始階段，即必須致力於解決語意曖昧問題。 p. 75
事實上，再多的先期努力也無法完全避免錯誤假設。因此，進行設計工作時，我們需要運用若干技巧，以簡化改正錯誤的工作。 p. 76
敏捷方法就是其中之一。
運用任何新工具之前，我們必須接受一個觀念：完美之人也有能力不足之處。 p. 85
設計者會犯的一個重大錯誤，即是試圖給予客戶需要的東西，而不是客戶想要的東西。 p. 86
第二部 起步的方式
5 開始
所有的需求要件作業進行之前，都會先有某種萌發程序 (initiation process)：某人興起一個概念 (點子，idea)，想要設計或建造某個東西。不論這個概念由何而來，這個概念即是需求要件作業程序的起點。 p. 91
我們將「問題」定義為：你的期望和你的感受之間的落差。 p. 92
我們最常見到的起點或許是：還沒有陳述該解決的問題 (也就是某人所感受到的和所期望的)，就開始思考解決方案。 p. 93
一般而言，解決方案找到它能解決的問題，必須經過許多釐清需求要件的程序和設計工作。 p. 95
畢竟，不是每個解決方案都能像便利貼那樣。
許多產品的開發程序起始於各種比喻是思惟方式 — 明喻或比較。譬如說，某人說：「製造一個類似這個的東西。」雖然客戶強調「這個」，但釐清需求要件的程序則是界定「類似」的定義。 p. 95
運用基準法的最大危險是：一旦我們確認客戶期望的是何種產品，設計者的思維就會受限制。 p. 97
模型法 (mockup)，即製造實體模型，可以避免這種語意曖昧。而且，模型可以在產品實際產製之前，用來進行說明、研究以及測試。 p. 98
所有的開發案皆起始於，假設對某問題的解決方案存在。 p. 99
6 開放式問題
就決策樹而言，開放式問題可以幫助你選定某顆樹，而不是選擇某個枝枒。因為開放式問題與個別設計案無關，而是設計者的一種工具，以避免設計者陷入過於龐雜的細節。 p. 105
開放式問題的後半部分，應該以產品的宏觀面，以及設計程序本身，這兩個方面為重點。後設問題的答案，則能確保雙方循正確軌跡釐清需求要件。後設問題可凸顯許多原本以為無須說明的事項，而這些事項正是問題的曖昧之處。 p. 112
7 找到對的人參與
開發工作最常犯的錯誤，或許就是沒有網羅到適當人選參與開發團隊。 p. 117
開放式問題的第一題永遠是：「客戶是誰？」為什麼這是第一個問題？因為客戶支付我們經費已進行需求要件作業。沒有人支付經費，就沒有開發工作。 p. 117
不論是哪一種情形，客戶就是付錢的人，也是最後決策者。使用者則是受產品影響或影響產品的人。 p. 118
為什麼使用者必須參與？如果你將你認為最適合使用者的東西給使用者，事情不是比較單純嗎？ p. 119
鐵道的矛盾的衍生意義在於，產品能創造新使用者。 p. 120
我們設計資訊系統時，必須先確認誰是輸家，並設置特殊需求要件，使系統對於不當使用者「不友善」。某些狀況，我們甚至希望輸家不知道產品存在。譬如保全系統，如果入侵者不知道系統存在，保全效果將更佳。 p. 122
我們的職責不僅是確認使用者，還必須決定與使用者接觸的方法 — 友善，不友善，漠視，或其他。 p. 122
決定那些使用者必須參與，以獲得哪一種訊息，是一回事；這些使用者同意參與，則是另一回事。某些開發案，找到使用者即是一件非常困難的事。 p. 130
8 有效率的會議
人際成本最高的部分就是開會。 p. 133
為了讓每個參加開會的人都舒適愉快，討論實質問題之前，對於會議規則先取得共識。討論議事規則的時候，最容易發現人們不喜歡開會的原因。 p. 138
多數人能可忍受枯燥無聊，以獲得安全感。人們不願意缺席某個會議，因為這個會議可能討論與自己的工作有關的事務。因此，他們去參加與自己無關的會議，以免錯失會議中討論與他們密切相關的事務。 p. 142
第一個讓人有安全感的方法為：事先公布議程，並確實遵守議程。 p. 142
如果你不希望懲罰相信公告議程的人，就必須有處理臨時動議的方法，以免沒參加會議的人受傷害。 p. 142
如果不相干人士前來開會，別假裝沒看到，也不能期望他們不會干擾會議。立即處理而且小心處理。會議開始之前請他們離開，是最適當也是最不傷人情面的時機。 p. 144
這超難，特別是某些人會覺得他們不是不相干人士...
規劃會議的第一個原則是，一次會議只有一個主題。 p. 144
會議成功的最後一個原則，和童子軍信條一樣：充分準備。 p. 145
9 努力減少語意曖昧
有意義的訊息，比沒有意義的訊息容易記憶。 p. 149
記憶法的變化方式之一，即是要求成員界定問題陳述文句最重要的部分。將每個人界定的成果，綜合起來討論，其中的差異即是語意曖昧之處。 p. 162
第三部 探索可種可能性
10 激發概念的會議
腦力激盪已然成為流行詞彙，具有多種解讀意義。根據我們的經驗，當某人說：「我們來進行腦力激盪！」結果卻變成「腦力冰風暴」(brainblizzards) —— 將你的腦袋冰凍，埋在雪堆下，冷得直發抖。 p. 169
對於任何概念的正反意見可以並存，稍後再做決定。概念萌生之後，紀錄者必須像列表機一樣逐一記錄。 p. 172
概念愈狂野愈好。開會的環境必須安全，使與會者無須擔心被視為愚蠢。 p. 173
最重要的是，主席必須避免任何過於嚴肅的批評，或嚴重對立。沒有笑聲的會議，不可能是一次成功的會議。 p. 173
如果擔心浪費時間，可限定腦力激盪時間，但要求與會者在時限內，盡可能提出多到數不清的概念。 p. 174
進行腦力激盪時，應該鼓勵參與者，對於它人提出的概念加以變異，或結合他人的概念，以萌發更多概念。 p. 175
真正照規則進行的腦力激盪會議，我印象中只有一次，多年前在水果公司的時候，但討論的主題早就忘了 XD
11 運用右腦
腦力激盪的變異之一即是腦力繪圖 (braindrawing)。腦力繪圖和腦力書寫有許多相似之處，但參與者不使用文字而使用圖。每個參與者都自行開始繪圖，然後傳交給其他人。每個人就他人的圖加油添醋，能激發或被激發創意概念。 p. 184
12 專案的名稱
專案的每一個名字 —— 不論是作業名稱或正式名稱 —— 都是語意曖昧的危險來源，因此選擇名稱務必慎重。選擇專案名稱時，你將發現，對於這項專案的要求，與你選擇的名稱，具有密切關聯。 p. 192
當然也有反向的例子，刻意選不相關的名稱不讓團隊以外的人猜測專案內容。
聽到一個名詞，聽者就會重建這個名稱的圖像，因此每一個聽者心中的圖像，不可能與原使命者心中的圖像相同。 p. 197
13 調和衝突
發生衝突的時刻，你需要另一種工具：一個技術良好的協調者 (facilitator)。技術高超的協調者，不僅能處理衝突，還能將衝突轉化為新可能性的來源。 p. 201
協調者的首要工作為，判斷衝突是否重要。重要的衝突於此時，與這個專案有關，而且與團隊成員有關。 p. 201
如果協調者詢問他們，爭論的內容是否與此時此事有關；通常他們會冷靜下來，另外找時間地點解決他們的舊仇。 p. 203
在團隊成員還沒有形成派系之前，先進行聯誼。更好的方法是在專案開始之際，安排以建立團隊合作為目的的活動。 p. 205
開會時會場中只有同一層級的人，即可避免這種衝突。這個想法真是大錯特錯。齊聚不同層級的人在一起討論，是解決層級衝突最有效的方法。 p. 206
最常見的重要衝突類型之一，就是「個性衝突」。這種衝突不僅存在於兩個人之間，也存在於兩組人之間；最通常的形式為，每個與會者都選邊站。 p. 208
有時候，沒有技術專業知識反而更好。如果協調者具有專案的技術專業知識，很容易捲入衝突或選邊站 —— 許多重要的衝突都戴著技術衝突的假面具。 p. 213
第四部 釐清客戶的期望
14 功能
功能就像是動詞，而產品是主詞，功能表示產品能執行的行為。 p. 217
另一個常常被忽略的現象為，對於某功能的描述暗示了特定解決方案。... (中略) ... 如果我們以「指出現在到幾樓」取代「顯示現在到幾樓」，將使設計者不囿限於視覺顯示。 p. 227
「至善者，善之敵。」試圖將產品的某個面相做到完美 —— 不論是成本、速度、或尺寸 —— 很可能會犧牲掉創新所帶來的「比完美更好」的解決方案。 p. 230
15 特性
產品特性 (attributes) 即是客戶期望產品具有的特色；可以想像成是形容詞或副詞。兩項產品可能具有完全相同的功能，但不同的特性卻使他們成為迥然不同的商品。 p. 233
不論你曾服務過多少客戶，下一個客戶總是不一樣。 p. 234
基於事實上的需要，你必須努力刪除必須具備以及期望具備的特性，以去除對於客戶沒有實質價值的特性。如果你不這樣做，設計費用將達天文數字，因此設計者常憑直覺或偷偷刪除千百個特性。 p. 242
16 限制
限制級是對於某項必須具備的特性 (M) 的強制指示。每一項限制都滿足之後，設計出來的產品才能被接受。因此，每一項限制都必須清楚界定，使參與者能客觀審查產品是否符合這項限制。 p. 246
限制線即是疆界線，以界定一個封閉空間，稱為解決方案空間 (solution space)。任何解決方案都必須符合限制，因此任何解決方案都必須在解決方案空間內。 p. 247
如果解決方案空間內並沒有可能的解決空間，你必須放寬其中一項限制。如果你沒有能力做到這一點，就必須放棄這個專案。於需求要件作業階段放棄專案，雖然令人沮喪，但還有更糟的，即是在實作完成之後才放棄專案。 p. 255
我們萬萬不可認為，限制對於設計不利，或認為限制對設計者有心理上的不良影響。... (中略) ... 如果限制過於嚴苛，解決方案了無新意；如果限制過於寬鬆，解決方案不是解決方案 —— 因為產品無法落在真正的解決方案空間之中。 p. 258
17 偏好
偏好 (preferences) 即是選擇性地較喜歡某一項特性。只要是可滿足每一項限制的成果，都是可接受的解決方案；但某項可接受的解決方案比其他方案更受到喜愛。偏好使設計者得以比較各種可接受的解決方案，並選出較好的一個。 p. 265
客戶才能有偏好，設計者沒有。 p. 266
基準本身不重要，重要的是「訂定基準」的過程。訂定度量每一項偏好的衡量基準非常重要，因為這個思考過程可以幫助每一個人確實了解，自己到底偏好什麼。 p. 267
唯有客戶的恐懼或期望的強度，能判定是限制或偏好。 p. 268
許多開發案因為無法區分，進度表究竟是限制還是偏好，因而飽受驚嚇。如果團隊誤認以為最後期限是一項限制，於是因為趕工犧牲了品質。 p. 269
缺乏了偏好，設計者會在找到第一個可被接受 (符合所有限制) 的解決方案就停步，因為他們欠缺指引，以引導他們去找到客戶認為「較好」的方案。 p. 280
18 期望
每一個有經驗的設計者都知道，失望與滿意的差別不在於產品本身，而在於產品是否符合客戶的期望 (expectations)。 p. 283
將各個期望歸類為可能現在達成、遲至修正版達成、絕對不可能達成，將導致許多不同的解決方案。如果你不開誠佈公進行分類，將錯失許多解決方案。 p. 293
多數人寧可事前獲知壞消息，而不是到最後一刻才覺得受騙。不相信的話，試試你自己的感受。 p. 293
當我們逐一考量各項期望之後，將會增加若干新的可能性。同時，其他可能性將轉化為限制，使設計者和客戶都確認並同意，哪些項目無法達成 —— 並說明理由。否則的話，客戶會誤以為他們的期望將達成。... (中略) ... 如果你設置限制時並未說明理由，將會導致這張期望表不可能再更動。 p. 294
理性使用原則的最終源頭是法律。法律問題有時確實是設計的障礙。如果某個成員認為法律上確實有問題，那就尋求法律意見。 p. 297
第五部 大幅提升成功機率
19 判斷語意曖昧的基準
實驗對象估計製造成本的比值，可以做為語意曖昧基準 (ambiguity metric) —— 可使我們獲臻準確數值的度量。當然，一個準確的基準可不會非常精確，但比沒有任何度量標準好太多。 p. 303
這邊不確定「準確」和「精確」的原文是什麼。從文章的脈絡，準確是你可以達到一個數字，而不是一個不知所以的概念，例如預估一個 task 要 5 小時，但這 5 小時可能不是最後真正的時數，因此不精確。總之，我只是想說，這也是為什麼敏捷還是希望做預估，透過預估才會有討論。
設計工作就是去除語意曖昧的程序。根據這個定義，設計工作應該按照下列步驟進行：創造一個近似設計，測試語意曖昧，去除已發現的語意曖昧，再測試這個新的近似設計。最後，測試的結果認為近似設計已非常接近，於是設計工作完成。 p. 304
即便受調查對象的背景不同，調查結果卻相當一致，不必然表示並無語意曖昧之處。 p. 308
運用調查統計方法揭露語意曖昧，還有一個重點必須注意：唯有受調查者獨立估價，調查統計結果才有效。如果公司總裁先估價，而且公告週知，然後要求員工公開估價，其結果當然是假象地向總裁的估價值收斂。 p. 309
20 技術審查
需求要件文件必須進行審查。由未參與製作的人審查需求要件文件，即是正式技術審查。由製作需求要件的成員於製作團隊內部進行審查，即是非正式技術審查。 p. 314
兩種審查方式的另一項差異是，參與審查者的目的不同。非正式審查固然是發掘問題的極佳方式，但自我審查卻不容易發現自己的錯誤和錯誤假設。 p. 315
若是將爭點表製作成解決方案表，將會徹底破壞審查程序。審查會議的功能只在於指出爭點；解決爭點則是需求要件製作者的工作。由製作單位解決爭點，比由審查會議解決爭點，前者顯然效果更好。 p. 318
「香草審查法」(vanilla review) 非常有效率，因為可以視個案調整審查方式。也就是因為這個特性，必須由一個技術熟練的協調者主持。 p. 320
沒有人喜歡被批評。而且，技術審查會很容易使人相信，別人批評的就是你，而不是你的工作成果。 p. 324
說真的，就事論事有時真的很難，一不小心用字遣詞稍有不適，就會引起誤會。例如：「有考慮 X 發生時，要怎麼處理？」和「當 X 發生時，系統的應對措施是什麼？」這兩句，哪個聽起來比較舒服？有人覺得一樣，有人就可能覺得前面那句，像是在批評你沒有考慮到 X 的狀況。
21 測試滿意度
避免使用者不滿意的最簡單方法，即是在設計過程中，不停地測試使用者滿意度。設計者也可能是使用者，因此使用者滿意度測試 (user satisfaction test) 可以是設計者彼此之間的溝通工具，也可以是客戶、終端使用者與設計者之間的溝通工具。 p. 327
滿意度測試的最重要目的，不是絕對分數，而是能夠彰顯滿意度的變化。因此，滿意度測試表最重要的兩個是向為變化和意見。 p. 330
不要忽視使用者滿意度測試表上的「感覺」。如果沒有感覺，沒有人會要求開發新產品。 p. 334
使用者滿意度測試的另一項優點為，可以持續使用，而且於產品製程後仍可持續使用。這時測試的結果，可以做為度量使用者學習使用產品的效率，以及產品運作的良窳。 p. 336
如果產品是漸進式 (incrementally) 開發的，產品良窳的最佳評量就是產品本身，方法是觀察已開發之產品的使用情形。 p. 337
敏捷的說法也是類似的，可用的軟體是最主要的進度量測方法。
22 測試案例
由於人類的不完美特質，測試的方法是愈多愈好。令人訝異的是，對某些人而言，測試需求要件最有效的方法是使用測試案例 (test case) —— 很像那些用以測試整套系統的方式。 p. 341
若有人自信滿滿地說：「正常人不會那樣做。」這將是需求要件作業最嚴重的敗筆，並將引起許多法律訴訟。 p. 345
因為這句話有點暗示某些人不是正常人。
黑箱案例測試的結果，可成為日後測試系統和產品的基礎。明白這點之後，或許我們會想延緩黑箱測試，而且延緩至正式的產品測試小組成立之後。這是一個錯誤的想法。黑箱測試作業不可以延緩；因為你一但開始思考完成產品設計的機械式作業，黑箱測試即失去效能。 p. 350
簡單說，就變成白箱了。
相反地，你應該在界定問題階段，就進行黑箱測試；而不是在提出解決方案階段，才進行黑箱測試。也就是在你不必承諾可以達成什麼的時候，盡力先了解客戶想要的是什麼。 p. 351
23 研究現有產品
亞里斯多德 (Aristotle) 曾說：「同一個概念出現在世界上，並非一次或兩次，而是無數次。」經過幾千年，情況仍然一樣，很少「新」產品是全然新的。 p. 355
在現實生活中，人們注意到新產品的第一件事情是，它是否遺漏了人們原本期望它應具有的功能。 p. 357
所以，運用現有產品進行需求要件測試的第一個項目為：檢查是否遺漏任何功能。並非所有遺漏的功能都必須補足；有些功能我們並不希望新產品具有。但我們必須做好準備，解釋為什麼這些功能被省略了，以及沒有這些功能，使用者應該如何做。 p. 357
24 意見合致
選擇其中一根枝枒，即使減少問題的語意曖昧，並朝解決方案更接近一步。但除非這些決策是眾人意見合致 (agreements) 的結果，否則將只是夢想。 p. 365
即便所有的決策都是正確的，也不一定能正確引導嗣後的作為。尤其是假設和強迫形成的條件，並非由開發者直接掌控。這些條件能決定開發的成敗。假設和強迫是開發案能否依時程有效完成的風險。 p. 371
總而言之，如果選擇、強迫和假設，沒有經過每一個參與者的了解和認同，就是失敗的需求要件作業。因此，在需求要件進入下一個階段之前，所有相關單位都必須了解和接受需求要件作業的成果。 p. 372
簽名也是一種測試。如果有人猶豫不肯簽名，不要強迫他們，而要和他們一起探索造成他們猶豫的原因。通常你將發現，會有另一個假設必須記錄下來。 p. 373
25 結束
需求要件作業階段結束於意見合致，但產品完成之前，需求要件作業永不完工，但某個時點，你認為已有足夠的一致意見，就可以冒險進入設計階段。 p. 376
凍結需求要件的觀念其實是一種妄想，用來抵制對於需求要件作業結束的恐懼。除非確知有再溝通的可能，我們無法放心地結束需求要件作業。所以，需求要件作業的最後一個步驟為：雙方同意繼續溝通。 p. 379
竭誠歡迎改變需求，甚至已處開發後期亦然。
或許工程師會丟掉飯碗，但這就是專業人士應該遵守的原則 —— 切勿答應你明知無法達成的事。 p. 382
從求學時代開始，像是軟體工程或是軟體設計，都有不少的篇幅討論如何收集跟分析需求，並轉化成設計，最後寫成軟體。但論點大都是比較從工程的角度出發。但實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
