前言
如果你不瞭解自己所說的事，即便你遣詞用字精確，也毫無意義。 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
從求學時代開始，像是軟體工程或是軟體設計，都有不少的篇幅討論如何收集跟分析需求，並轉化成設計，最後寫成軟體。但論點大都是比較從工程的角度出發。但實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
