http://dev.csdn.net/article/26/26992.shtm
http://dev.csdn.net/article/27/27354.shtm
http://dev.csdn.net/article/27/27376.shtm
http://dev.csdn.net/article/27/27380.shtm
http://dev.csdn.net/article/27/27601.shtm
羊的門
作者：章柏幸
[email protected]
7我實實在在地告訴你們，我就是羊的門。
8凡在我以先來的，都是賊，是強盜，羊卻不聽他們。
9我就是門，凡從我進來的，必然得救，並且出入得草吃。
10盜賊來，無非要偷竊、殺害、毀壞；我來了，是要叫羊得生命，並且得的更豐盛。
12若是僱工，不是牧人，羊也不是他自己的，他看見狼來，就撇下羊逃走。狼抓住羊，趕散了羊羣。
13僱工逃走，因他是僱工，並不顧念羊。
——聖經·新約·約翰福音·第10章
“我從很小就開始對‘人們如何思考’產生了濃厚的興趣；那時我還是一個小男孩，世界上僅有的計算機被人們稱爲‘巨型大腦’；我當時就想，如果我搞清楚了這些巨型大腦的‘思想’，我或許就可以更深入地瞭解人們是如何思考的。”——傑拉爾德·溫伯格。
在看到這個題目的時候，讀者朋友可能會想起幾年前李佩甫的一部同名小說。這裏說的和那本小說看起來沒什麼關聯，但是又彷彿有着莫大的聯繫。在我改寫這部分文稿的時候，腦海中總會時不時浮現出盜賊、羊、僱工、狼、牧羊人的圖景，我發現，我們在這裏討論的內容所遇到的問題和耶穌所遇到的責難一樣難以處理；而我們所做的事業，正是在幫助那些心地善良而又不知天堂之路的迷羊找到正確的回家之路；這就是羊的門。
下面2個小節，介紹一下本文的主要目的和關注點。
《探索需求》是Donald C. Gause和Gerald M. Weinberg合作的一本探索軟件開發項目需求部分的書。本文的目的是爲了用一種更爲適合中國人的方式來表述書中第一部分的觀點。在項目管理者的眼裏，世界上的一切問題都可以歸結爲項目。項目從開始到結束一般會有很多階段，而“需求分析”階段就是用來搞清楚“我們在這個項目中需要解決什麼問題”的。
這本書的關注點就在“需求分析”階段。雖然這個階段的書籍和論文已經很多了，但是經驗表明，我們還是有必要閱讀這本書，因爲這本書中還有很多別的書中沒有提出過的有用的觀點。《探索需求》的第一部分就是要講清楚爲什麼需要這本書或這本書中的一些技巧和觀點。這也是本文的重點。
簡而言之，需求分析階段需要經歷兩個步驟：
1、提出問題的人說一些話，以告訴幫助他解決問題的人他要幹什麼。
2、解決問題的人和提出問題的人進行溝通，以確證這個問題的細節。
第一步就是“問題陳述”，這和法庭上指控方、被指控方的案情陳述有點類似。
第二步就是“探索需求”，這和法庭上的雙方律師不斷地分析對方以及詢問證人有點類似。這裏律師就是需求分析員。
只有律師把事情來龍去脈用合乎法律的方法表述清楚之後，法官才能夠正確斷案。也就是說，只有需求分析員把問題的關鍵分析清楚之後，開發者才能夠做出正確的產品。
下面舉出的這個例子說明了一個觀點，即：如果你說清楚了你的需要，那麼你就很可能得到它；如果你沒有說清楚你的需要，那你就很可能得不到它。當然這個觀點很簡單易懂，也就是說這個例子可以略過不讀。
| 我們要求五個小組甲、乙、丙、丁、戊在幾乎相同的“問題陳述”下進行程序開發，說“幾乎相同”的意思就是其中有且只有一個句子各不相同，分別如下： 小組 要求 甲 開發時間儘可能少 乙 源代碼行數儘可能少 丙 佔用內存儘可能少 丁 程序的可讀性儘可能高 戊 程序輸出儘可能清楚 最後的結果就是，每個小組開發出來的程序都滿足了這句特殊的要求，而沒有滿足那些沒有被要求去做的。我們常常聽到一些購買軟件的人抱怨軟件開發商沒能開發出他們真正想要的東西，那麼這裏反過來可以這麼認爲，並不是開發商不能開發出來，而是他們不知道要開發出什麼，這裏面的問題就是：開發商沒有好好地調查好需求，或者是購買者沒有好好地講清楚需求。這裏我們不追究誰的責任，關鍵是我們確證了“你要你就說，你不說我怎麼知道你要呢（參見《大話西遊》，唐僧語）”的真理。 |
經驗表明，上述例子在全世界的軟件開發商中都有發生。尤其需要指出的是，“問題陳述”和“人們真正想要的東西”之間的差距不僅僅在軟件業頻頻發生；而是，只要有人需要解決別人的問題，只要有人需要別人爲他設計和生產產品，只要存在某種供需關係；這種差距就存在，就需要有人來解決這個差距問題。
高斯和溫伯格，軟件界的兩個泰斗級的人物，爲了解決這個差距問題，已經花費了60多年的時間了。而這本書中的內容，正是對這些問題的心得。
1 賊和強盜
作者：章柏幸
8凡在我以先來的，都是賊，是強盜，羊卻不聽他們。
我們已經知道了需求分析的必要性，這也就意味着我們認爲現今的需求過程尚不完善。這種不完善很大程度上體現在“問題陳述”和“人們真正想要的東西”之間的差距上，或者說，“問題陳述”沒有能夠陳述清楚“人們真正想要的東西”。
這裏我們引進2個詞語：歧義、含混性。
| 此處，歧義的意思是指我們得到的“問題陳述”導致了多種理解，以至於我們不能確定哪一種理解才能夠真正說明“問題”。含混性是一種更爲晦澀的表述，它的意思是“問題陳述”含混不清，甚至無法表達明確的意義。 |
在過去幾年，軟件過程和軟件工程流行的時代，很多人已經被時尚所左右，言必稱自動化，開口即軟件工程，彷彿所有的開發問題都已經解決。更有甚者，有人還認爲需求分析中的歧義的根源是因爲“人”的參與。他們宣稱“人”的不確定性導致了“陳述”的不確定性，由此導致了“人”提出的“問題陳述”的歧義。並且，他們認爲只要排除掉需求分析過程中的人的因素，然後用一種嚴格論證、高度自動化的、規範的方法論來進行分析，就能夠消除這種歧義了。那麼，或許我們可以反問一下，這種分析是否也應該“剔除”具有嚴重不確定性的“顧客”呢，因爲我們實在不能不把顧客當人看待的。
實際上，上節中比較極端的觀點是對CASE、CAD等工具的一種病態的理解。工具能夠幫助人們工作，但是卻不能夠完全替代人。我們不妨來考察一個如何殺死蟑螂的項目。
不聽使喚的蟑螂有人提出可以用一種自動化的方式殺死蟑螂，步驟如下：1、 讓蟑螂靜止站立在砧板中間 2、 用蟑螂拍對準蟑螂猛拍一下 3、 把砧板、蟑螂拍上的髒東西洗乾淨 這種自動化方式和CASE或CAD工具所謂的自動化過程同出一轍，在一個CASE文檔中，CASE工具也由三個步驟組成： 1、 分析並設計出明確的需求規格說明書 2、 建立功能點和源代碼（及文檔）一一對應的數據字典 3、 將需求規格說明書轉化爲源代碼和文檔 於是有人會說，自動化殺死蟑螂的方式純粹是搞笑，因爲沒有哪一隻蟑螂會乖乖地待在砧板中間，就算它碰巧站在了砧板中間，它也不會乖乖地一動不動等待你的拍子。這個理由恰好也是我們認爲的CASE之類的自動化工具離不開“人”的因素的理由。因爲我們沒有辦法用自動化工具分析出明確的需求規格說明書，也不能用它來保證這一需求規格說明書永不改變。 |
【拾人牙慧】
自動化方法乾的是“大事情”。40年前需要很多個星期才能完成的工作量，今天只需要一個小時就能夠搞定。而且，由於自動化工具的發展，我們還開始挑戰那些在以前想都不敢想的系統。然而，隨着工具的進步，軟件產品在可用性方面的口碑卻並沒有多少提高。
對於那些需求明確、陳述無歧義、一定程度上模式化了的內容，自動化方法非常擅長；但是也還有一些涉及到人性心理方面的棘手問題卻無法用這些方法來解決。換句話說，只要是有規律的、統一的開發過程，自動化方法非常擅長；而在不同項目或產品之間的差異和個性化，則需要更細緻的分析。
| 我們不妨做一個簡單的計算。 規模爲S的項目中有P%的問題爲公共問題，有Q%（Q＋P＝100）的問題爲個性問題。 在時間T1時，我們每解決一個公共問題需要投入T，每解決一個個性問題需要投入M。解決個性問題在整個項目中所佔的投入爲：R1＝M×Q／（T×P＋M×Q）。 在時間T2時，我們每解決一個公共問題需要投入t，每解決一個個性問題需要投入m。解決個性問題在整個項目中所佔的投入爲：R2＝m×Q／（t×P＋m×Q）。 從T1到T2，自動化水平提高了，於是有T>>t，公共問題和個性問題的比例變化很小，而且對於每個個性問題的投入也變化很小，即有M≈m。從而可以得到R1< 這表明，隨着自動化水平的急劇提高，我們在個性問題方面的投入比例也急劇提高。 |
個性問題，亦即是人性方面的因素反而隨着自動化程度提高而愈顯得重要了。這一特徵在那些具有多年開發經驗的人們當中早已成爲了共識。也就是說，經驗豐富的專家們在技術任務上的投入少了，而在人性因素方面的投入更多了。在那些小型的顯而易見的問題上，他們完全放心交給別人去做了；而在那些看起來永遠不會結束的問題上，他們被深深地吸引了。
【呀呀學語】
語言是我們表達思想的工具，也是某種文化的載體。在開發系統方法中，我們也有語言，那就是符號系統。相信所有人都遇到過因爲語言不通而產生的交流障礙；同樣，在符號系統上，我們也遇到了交流障礙。
語言文字所傳遞的信息包括“內涵”和“外延”兩部分。人們在說話傳遞信息時，往往會附加上各種語態、表情、動作作爲對其所說語音的外延；甚至我們可以認爲，因爲我們來自各個不同的省份縣市，各種不同的方言鄉音也傳遞了豐富的外延。
於是，對於同樣的事件或需求，我相信沒有任何兩個人的描述是完全一致的。承認這一點對於我們直面需求分析的困難會有很大的幫助。
我們這裏給出優秀符號系統的兩個重要要求（當然這僅僅是衆多要求中的兩個），以幫助我們將來使用這些符號。例如說，首先符號系統要能夠比較全面地表述我們所遇到的絕大部分問題；其次爲了適合產品開發的過程化，符號系統的表述結果要比較容易保存和修訂。這也是對一個優秀的CASE和CAD工具的基本要求：在任何時候都可以保留並修改我們當前的結果。
【大同世界】
在未來的大同世界裏，人們都操兩種語言，一種是代表本民族特色的方言，另一種是所有人都能聽懂的世界語。這個世界語和現在語言界所謂的世界語大大不同，雖然後者的目標是成爲前者，這差距就像是共產主義和社會主義之間一樣大。
雖然大多數人都會認爲自己的母語是美妙而完美的，但不可否認每一種語言都有其優缺點。類似的，每一種符號系統也都有其自己的利弊。這裏我們引進一個概念：映射圖。
| 我們把用符號系統的基本符號組合而成的信息集合稱爲映射圖。這裏的“映射”取自於邏輯上的對應關係。大家可以把之近似地聯想成通過某種約定而建立的“需要表達的信息”和“符號單元”之間的對應關係。映射分爲1-1對應、1-n對應、n-1對應三種。由於自然界所存在的信息是高階的不可列無窮大，因此嚴格意義上的1-1對應是不存在的；反過來，嚴格意義上的1-1映射甚至可以說是毫無價值的。 在這裏，我們用映射圖來表示我們的符號系統的結果，映射圖可以是一種語音，也可以是一幅地圖，或者是圖文並茂的VCD；只要它滿足可再現、可修改、可保存，就可以。 |
質量好的映射圖必須是能夠讓所有相關人員都能夠理解的，就像是未來大同世界的世界語一樣。當然這僅僅是一種理想的奢望。實際上，每種語言或符號系統的支持者都會聲稱他們的東西是最好的，聽起來有點像是“王婆賣瓜”。這個時候人們一般會把其“瓜”的賣點放在“直觀性”或“易讀性”上，顯而易見，這是一種好的符號系統應該具備的條件。
但是，對於從小在北京長大的孩子，很自然會認爲普通話是直觀而易讀的；而對於在美國長大的孩子，則會認爲美式英語是最美最簡潔的。也就是說，對語言的培訓能夠增加在使用者角度上的“直觀性”和“易讀性”。這就像我們看技術文獻一樣，由於我們熟悉了大量的軟件最新詞彙，於是不會感到ISO、CMM之類的縮寫艱澀難懂；而第一次上網的人可能會認爲OICQ是“我愛重慶”的縮寫。
簡言之，前面說的意思就是符號系統本身是不可能完全“直觀”和“易讀”的。
如果，要讓所有相關人員都能夠理解某種符號系統，那麼，最直接的辦法就是培訓這些相關人員。下面的步驟可以測試一下當前的映射圖到底有多直觀：
1、把每一幅映射圖展示給那些不知道這種符號系統的人來看。這種方法能夠揭示出符號系統中不直觀的地方。當然，也有可能揭示的是這個映射圖中需要表達的那部分信息本身的不直觀。（對應到不同的語言，就相當於讓一個講閩南語的老鄉在上海某個論壇用家鄉話發言。）
2、讓每個人用自己熟悉的符號系統重新描述一遍對映射圖的理解，然後再讓一個理解這兩種符號系統的人來覈對。這樣可以揭示映射圖中的一些人爲的假設。（對應到不同的語言，就相當於每個人把所需要表達的意思用方言各自表達一遍，然後再讓通曉兩地方言的翻譯來糾正其中的偏差）
3、使用某種能夠把別的符號系統自動轉換成某種“標準”的符號系統的自動化工具。（對應到不同的語言，就相當於讓所有人都在發言之前學好普通話，再用普通話發言。）
上面講到了因爲不同的符號系統導致的對映射圖的理解的分歧，這就相當於由於語言不通而導致了交流障礙。最直接最常見的辦法就是推遲需求工作的進度，先讓大家都來學習這種語言（或符號系統）。但是，這也是不切合實際的，因爲這樣有可能還會讓大家失去對需求過程的興趣和衝動。經驗表明，把這些學習時間安排爲需求階段的一部分會好一些，因爲這時候我們可以一邊學習語言，一邊解決問題。
【雞同鴨講】
學過信息論的人都知道，完全的全通系統是不存在的。換句話說，就像我們前面說的，在需求工作中，嚴格意義上的1-1映射是不存在的。這一點對於務實的人們來說感觸最多。務實一詞適合用來形容軍人作戰時的狀態，這就像是某條軍規中所說：“在地圖和實際地形有出入的時候，要相信實際地形”。對於這一點，成語“紙上談兵”已經概括得很好了。
但是我們相信這個世界上還是有很多很多熱衷於“紙上談兵”的人。特別是在使用那些所謂先進的自動化工具的時候，他們往往會忘記人們實際所需而開始相信他們的所畫的諸如工作流圖之類的是真正的問題所在。下面這個例子是我在這個月遇到的一個真實案例，目的是說明“紙上談兵”的態度會帶來需求的偏差和歧義。
| 我們在幾個月前參與了一次投標，當然我們中標了。 作爲一個工程項目，涉及到投標內容的相關方包括甲方（買家）、乙方（賣方）和設計方。設計方在設計方案的草圖中選用了型號BX的產品，這一選型並沒有在招標過程中寫入技術說明書中，這是因爲設計方只關注型號BX的產品技術指標能夠滿足設計要求。 中標之後的正式合同中，考慮到性價比問題，乙方和設計方就產品技術指標問題進行了磋商，並達成了一致，最終選用了型號BY的產品，BY產品完全能夠滿足BX產品在該項目中設計需求，因此，而在正式的技術協議書並沒有出現BX和BY的任意字樣。 隨着項目的開展，甲方在驗收的那一天突然提出了乙方所供產品型號不符合要求的反饋，並表示要拒收產品。其理由是，這一投標是甲方整體項目中的一部分，而甲方對其它部分的招標和實施都是按照BX型號的產品設計的。 那麼，這份技術設計中的草圖是否應該作爲產品供貨的限制呢？其中作爲示意方式標註的產品型號是否具有合法的效力呢？或者說，設計方在寫上型號BX時是否已經使設計中“所表達的本意”與“設計圖紙”產生偏差了呢？ ――citizen2yy |
我這裏要說的是，例子中的問題很大程度上與設計方所採用的符號系統有關，而且如果我們三方能夠對“真正的要求”達成一個共識，事情就不會費那麼多的周折。
【誡條】
1、 在生活（或開發項目）當中，我們往往會遇到一些不明是由的旁人（非專業人員）橫加職責，這讓我們很鬱悶。很顯然，每個人都不可能和我們設計者一樣全盤投入到產品中來，但是他們卻不願意錯過每一絲繁華。當非專業人員不願意或者不屑於花時間來了解設計過程的時候，僱用一個明白事理而又口齒伶俐的調解人會比較有效，而符號系統及其產生的映射圖在產品設計中就扮演了這個調解人的角色。
2、 人們不願意參與設計過程的一個重要原因是現在的所謂“專業設計人員”的高高在上的姿態。千萬要注意顧客和旁人（實際上是決定事態結果的裁決者）僅僅是對開發過程不瞭解，他們在別的方面（比如說法律、業務等）卻是專家，這也是需要他們參與的原因。如果能夠建立一個大家融洽交流的環境，相信世界會更美好。
3、 一部分自動化過程的固執而忠實的擁躉認爲他們的“直觀”的符號系統很容易被別人看懂，就像一個在北京胡同里長大的5歲孩童堅信“普通話是最容易學懂的語言”一樣。改變這個孩子的簡單方法，是讓他去教一位外國小朋友怎麼說普通話；改變這些固執的傢伙的方法，是讓他們把符號系統向100個不同學歷、不同民族的聽衆解釋清楚。
4、 對於同一個需求過程中的兩批不同背景的專家，常常會傾向於說兩種不同的符號系統。那麼最好的辦法就是用兩種不同的符號系統都表述一遍。
5、 用一種大家都能聽懂的語言來作爲正式文檔的語言會比較有效，那麼在需求過程中也最好事先指定一種“大家都能理解的”符號系統作爲正式文檔。如果誰不懂的話，就讓他去學好了。
6、 不同母語之間的翻譯會有優劣之分，同樣不同符號系統之間的翻譯也有優劣。優劣的背後就是分歧，也就是歧義。需求過程經歷了從真正最終用戶——用戶代表——需求分析員——需求規格說明書這麼一長串的步驟，每一步都是一種翻譯，因此保證每一個步驟都是最優的就顯得格外重要了。
7、需要注意的是，需求過程並不完全是瀑布式的。隨着過程的深入，我們極有可能會像老牛一樣進行反芻。因此，我們的探索也會考慮到如何快捷地執行“撤銷”操作。
2 無非要偷竊、殺害、毀壞
作者：章柏幸
10盜賊來，無非要偷竊、殺害、毀壞；我來了，是要叫羊得生命，並且得的更豐盛。
無論什麼時候，如果人們僅僅使用那些忽略了人性因素的自動化工具，就絕不可能完美地描述需求。而且，含混性隨之而來，看起來整整齊齊的需求規格說明書可能會帶來各種各樣的解釋。
【節外生枝】
| 王二注意到世界上的眼疾患者越來越多，於是他跟我們的設計組織說：設計一種保護眼睛的產品。 三個月過去了，王二來要他的產品，但是他發現幾乎什麼都沒有得到。設計人員們還在爲產品的各種可能爭論不休。典型的產品方向有：各種眼鏡、眼罩、眼藥水、富含維生素的藥丸、眼保健操、掛在顯示器前的某種玻璃、視力表、科普小品文、皮尺、催眠曲…… 可惜的是，王二真正的想法是要讓他那位種植專業戶的王五同志擁有一種新的素菜品種，這種素菜包含和豐富的鐵元素和磷元素，多吃的話有利於眼部健康。 ----citizen2yy |
如果王二僅僅把他的需求陳述侷限在“設計一種保護眼睛的產品”，估計是會錯過素菜的種植季節的。
另一個例子，有人說“設計一種方案，用於保護一小羣居民不受環境侵擾”。 《探索需求》中給出了三種不同的方案：
| | |
方案1：小土房 | 方案2：城堡 | 方案3：太空站 |
很顯然，這三種方案確實提供了對需求陳述的有效的解決方案，但是這種天馬行空的發揮也讓我們大吃了一驚。不用說，這種差異都根源於需求陳述的含混性。
含混性的意思前面已經解釋過，這裏我們做一點稍深入的分析。我們認爲，含混性有多種形式，就剛纔的例子來看，我們至少找到了3個不得要領的地方。
（1）表意不全。也就是說，這種需求陳述缺少很多必要的產品性質描述。例如，對於這種方案的使用方法、耐用性、成本等都沒有提到；對這種產品的大小、形狀、重量、壽命等也沒有提到；對於這種東西可能應該包含的功能、所處的物理環境、文化氛圍等等等等都沒有提到；我們甚至連裏面的“一小羣居民”到底是一小羣人還是幾隻狗，或者是一大窩小白鼠都不清楚。
（2）表意不清。用詞含糊是含混性的重要來源。比如說，“小”是一個含糊的詞語，對姚明來說，2米高的傢伙都是小個子；而對日本人來說，1米70的男子都已經是他們中的大個子了。還有，“羣”也是含糊的詞語，它暗示這些居民之間有某種關係，但是我們還是搞不靈清到底是什麼關係。甚至“建築物”一詞也含糊不清，因此有了前面的幾種方案。
（3）理解者自以爲是。幾乎世界上所有的人都擁有他們對某些認識上的成見，而視那些不同看法爲偏激或是鑽牛角尖。人性的弱點讓他們自以爲是地代表了大部分人的意見，從而把自己的偏見當成了共識，最終陷入真正的誤解。例如在陳述中我們根本沒有看到 “建築物”一詞，但是在不經意之中進入了我們的討論，甚至還成爲設計的基本條件了。於是，我們天馬行空的想象力被侷促在一個小盒子裏面，再也想不出什麼創新的、無需建築而又能保護他們的方案了。你看，我們可以用屏蔽罩來防止輻射侵擾，可以用畫着骷髏頭的警告來防止外人誤入，甚至可以用鍛鍊來保持身體不受病菌侵擾，用遷徙來躲避氣候變遷。
需求中的含混性，在“有過去的開發人員”（參見周華健《有過去的人》）眼裏，無疑就是開發過程中需求不斷擴展、進度不斷延期、質量不斷下降、可控性不斷落空的罪魁禍首。它是魔鬼，來自地獄，欲知更多分析，參見第3章《地獄》。
【殃及池魚】
前面我們總是在稀裏糊塗地向你介紹一些我們認爲的真理，這裏給出一點經驗數據，也好證明我們不是空口白話。
《軟件工程經濟學》的作者Barry W. Beohm同志通過對63個軟件開發項目的研究，得出了下面的表格，不妨一讀，右邊的是表格對應的柱狀圖，不妨一看。
|
爲了修正一個錯誤，所要付出的成本 |
|
儘管上面的表格已經能夠生動地說明：對於任何一個錯誤，如果能夠在需求階段發現它，那將是多麼地節約成本啊！但是，專家說了，這些數字還是很保守的，因爲Beohm同志研究的項目都已經完成了，也就是說這些數據中還沒有包括至少1/3的沒有完成的項目，而這些夭折的項目很大程度上都應該“歸功於”需求分析。
| 20世紀70年代生產的Ford Pinto車，沒有考慮任何追尾事件（需求表意不全），把燃油槽座架螺栓放在屁股上，這一設計非常“科學”。結果呢？現實中頻頻發生的追尾事件，這給Pinto帶來巨大的威脅，於是，Ford汽車公司花了1億美金來打官司和召回已售出的汽車。別看1億元還不會讓Ford汽車倒閉，可是又有多少家庭因爲這該死的Pinto而倒閉呢？ Johns-Manville公司本來是Johns和Manville合夥的公司，他們在新產品開發中發現石棉非常適合做建材。當該公司把所有資源都投入到石棉建材，準備大發橫財的時候，卻引發了大量的客戶起訴，據一家流行病研究公司統計，這樣的起訴大約有5萬多起，大多數是因爲石棉會對人類裸露的皮膚帶來流行病（需求表意不全、理解者自以爲是）。最後，公司爲此背上了20億美元的債務，破產了。Johns也逃跑了，現在公司改名爲Manville公司。 |
這２個故事告訴我們，如果需求工作沒做好，有可能損失１億美金，也有可能損失20億美金，而且破產。
【混沌初開】
幾十年來的經驗表明，那些錯誤的、失敗的或災難性的項目讓投資者付出了巨大的代價，而這些項目中的大部分都起源於含混的需求。本書的目的就是爲了向讀者介紹一些成功應用於抑制含混性的探索需求的工具。多數持有某種信仰的人或理想主義者會認爲，這個世界上存在着完全確定的東西；當他們籌建一個項目的時候，就把項目要求看成了確實存在的標準。現在，我們接下來他們提出的項目，那麼，這一項目要求就成爲了我們獲得的需求陳述；不幸的是，這一需求陳述在絕大多數情況下是含混的。
| 世界上最偉大的兩個物理學家，牛頓和愛因斯坦，在他們人生的最後階段不約而同地轉向了對第一推動的研究。第一推動對於深究“科學”意義的思想家尤爲重要。科學本身，是一種無法自圓其說的學說；這不同於信仰，根本就無需自圓其說。於是與信仰相關的傳說，比如盤古開天闢地、比如上帝造人，都將創世之初解釋爲一種確定的過程。而科學不然，他們需要有逐步論證的依據、可以證僞的預測、以及看起來有些道理的假設。 ――citizen2yy |
雖然我們在很多時候祈禱上蒼的保佑，但在具體實踐和委託別人做事的時候，我們總會希望所用的方法是科學的。於是，對於那個存在於理想主義者心中（或者是天堂）的需求陳述，也最好遵守一些科學的準則。
這裏我們就要說明，需求探索過程是一個漸進的、可以逐步測量的過程。而我們的假設就是，我們的所有相關人員當中，的確相信存在着某種明確的需求，並且大家願意一起來找到它們。
| 古人觀察到宇宙起源於一個巨大的蛋，所謂太初之時，混沌未開；古今中外的人們都叫這個初始狀態爲“混沌”。我們不妨來看一下盤古先生是怎麼來找到開天闢地的這道分界線的。天地有別，我們要把天從地分離出去。如果我們確實找到了地平線，就表示我們擁有了完美的需求描述。 |
|
天和地之間的這條線就是我們所需要的需求描述。
|
| 左邊的圖說明了對需求的探索過程，這其實是很簡單的迭代和逐步逼近，卻往往被我們的需求分析員所忽視。盤古開闢天地是一板斧一板斧來的，需求探索也是從含糊不清的描述逐步走向詳盡明確的表達的。 左邊圖中黑色區域代表那些我們想要的內容卻沒有要求，或我們要求了並不想要的。通過再三使用需求工具，我們縮小了這部分區域，並越來越接近於我們不多不少想要的內容。 |
每一個新蛋都代表需求過程中的一個階段，每一次中間的切分都是對真實需求線的一次更好的近似，可惜的是，這種過程永遠都是近似。我們的探索，就是努力使的這種近似誤差儘可能地小。
前面說了好幾次“探索”了，這種探索就象是“歷險”，這裏給出探索的步驟，以清楚我們今後的過程：
1. 向某個方向移動。
2. 看看在那裏發現了什麼。
3. 記錄所發現的東西。
4. 有目的地分析所發現的東西。
5. 通過對所發現的東西的分析和記錄來選擇下一個方向。
6. 跳回到第1步，繼續探索。
【誡條】
1、 我們不喜歡含混性的原因是含混性需要成本；我們認爲含混性發現得越早越好，是因爲越早發現成本越低。
2、 時刻反省自己，反省自己在需求過程中的含混性，反省自己被這種含混性所帶來的困擾。如果你發現產品並不完全如你所想，你可以問問自己：“是什麼需求讓我們製造了這樣垃圾的產品？”
3 地獄
作者：章柏幸
9我就是門，凡從我進來的，必然得救，並且出入得草吃。
如是我聞，罪惡各不相同，其來源也各不相同。爲了找出含混性的來源，我們需要經過一次含混性的實驗。所謂天機不可泄漏，所以敬請讀者循序閱讀本章。
下面，就讓我們到人間走一遭。
【撒旦的誘惑】
有這麼一個研討會，演講者是Donald C. Gause教授。主題是：“收斂設計過程，對含混性的思考”。
| Gause仔細地檢查了幻燈片放映機調節裝置，接着他頭也不擡地開始其獨特的分析，說：“這個時候，它當然是好的。”然後他輕輕彈開他的第一頁幻燈片直接把它放在演講臺背後的放映屏上。 這個時候熒屏上的圖像並沒有右邊的圖片那麼清楚，Gause看也不看幻燈片就說：“呵呵，這張幻燈片是用來聚焦的。” | |
一會兒工夫，Gause就換上了下一張幻燈片，這張幻燈片是下面這個樣子。
| |
然後，演講就正式開始了。Gause說，“今天我們來討論收斂設計的問題，這是一個過程，通過這次研討會，我們能夠明顯地有意識地識別、定義並儘可能有效地消除含混性。”
這個時候，Gause才注意到幻燈片焦距有點兒沒對準。他熟練地把幻燈片調得非常清楚。然後繼續開始他的演講。演講中的例子我們在這裏不作描述，因爲那是我們在下一章中將要介紹的，這個例子的確非常有趣而又具有針對性；美國大學中傳統的Seminar式交流使這後續的討論非常愉快。
說着說着，Gause引進了一些設計的模糊理論，論題開始變得有點艱澀，這時，中間休息時間到了。
【定力】
在開始這一小節之前，我們希望讀者能夠想象自己正在那個Seminar中沉浸於對設計過程的討論，以及對那個模糊設計理論的思考。
然後，我們各就各位，開始加入了下一半的討論。這時候，Gause先生說：
“下面的問題，請大家獨立回答，並在自己的記事本上記下你們的最精確的、最嚴格的、最負責的估計，同時提醒大家一定要根據自己的第一印象獨立回答！”
讀者朋友，我們也不妨靜下心來看看屏幕上到底是什麼問題。幻燈片上的問題是：
How many points were in the star that was used as a focus slide for this representation?
考慮到這個例子的特殊意義，我們保留Gause先生在真正的演講中所用的英語，看不懂英語的讀者，可以把問題理解爲：“這次講演中用於聚焦的幻燈片中的星星有多少個點？”
這似乎是在考驗我們的定力，讓我們想起那個“說遍了公交車每一站上站下站人數而最後問總共停靠了幾站”的問題。
不過這時候Gause又翻開了一張新的幻燈片，並說：
“這一問題包含了世界上需要設計的全部內容。例如說，你的回答可能會影響到某個關鍵的設計問題。或者說，某件重要事件發生了，但你卻沒有在它發生的時候意識到它的重要性。於是所有人都必須儘可能詳細地再現那些重要信息。現在，請寫下你對剛纔屏幕上提出的問題的回答。”
好的，真正的定力考驗到了。爲了親身體驗這一過程的全貌，請大家不要回頭看前面的圖片以及本頁中的那個英文問題，僅僅是根據記憶，按順序每次回答一個問題。
| 千萬注意，回答時一定要注意逐個回答，答完第一個再去回答第二個…… |
1. 你認爲剛纔那個英文問題的答案是什麼？
2. 如果有100個人和你一樣來回答第1個問題，大家可能會寫下多少種不同的答案？
3. 如果你認爲可能有多個答案，可能會有哪些大致的答案呢？
4. 發揮你的回憶能力，逐字寫下在問題1中你認爲你所回答的問題。
5. 有100個人和你一樣會回到第4個問題，即寫下他們所認爲的那個英文問題，你認爲他們所寫下問題的有些什麼差別，也把它記下來。
當您回答完這5個題目的時候，我們的定力測驗到此結束。這好像是已經過了一個非常漫長的過程，或許您已經迫不及待地想要看下一章中的那個關於收斂設計過程的實際案例，或者你很想回頭看一下前面的幻燈片或問題。那就不妨向後或向前看一下。然後再來看我們的人間正道。
3 地獄-2
作者：章柏幸
【人間道】
上述5個問題同樣被髮給了參加研討會的人們。
本節我們討論前3個問題。請思考這3個問題的共同特性。
我們知道，每個人都會對事物產生某種第一感覺，有時候也稱爲是直覺，這種直覺一方面來自於觀察，另一方面則是來自於經驗。經驗對於我們判斷的影響很大程度上是不自覺的。而這3個問題，實際上是強化了你對自己直覺的信任；也就是說，這3個問題的答案使你確信你自己的答案，就像是一再地在向你詢問：確定嗎？真的確定了？不再改了？（中國中央電視臺，《開心詞典》欄目，王小丫語）
經過3個問題的定力考驗，我們能夠相信你的判斷是發自內心的。如果我們根據你和研討會成員的回答把你們分成幾組，你一定會認爲你自己是站在正確答案這一組的。
問題1：對於那個在屏幕上提出的問題你認爲答案是什麼？
答案只有你知道。
問題2：如果有100個人和你一樣來回答第1個問題，大家可能會寫下多少種不同的答案？
問題3：如果你認爲可能有多個答案，可能會有哪些大致的答案呢？
你的答案也只有你知道。但是，根據100個真實參與者的實際回答，我們得到了18種不同的答案。這時候，你可能就迷糊了，而且你開始懷疑對第3個問題的回答了。
| 實際回答如左表所示，一共是從1開始到正無窮大共18種答案。 我們觀察得到，對於左邊的答案，可以劃分成幾個區間，每個區間都有一定人數的支持者，因此我們做了一個簡單的整理，變成了如下的列表：
很明顯，我們整理之後出現了幾類大致的答案。而你一定和現場的參與者一樣，會驚訝於這之中的某些答案。我們的經驗告訴我們，這些重大的差異來自四種可能：觀察錯誤、回憶錯誤、理解錯誤、問題描述的含混性。 |
下面簡單分析一下這些差異的來源，以能讓讀者能夠接受這種差異存在的合理性。
| 觀察錯誤和回憶錯誤。不可否認，每個人的觀察能力和關注點都會有所差異，因此，任意兩個人都不一定會看到完全一致的東西（觀察錯誤），或者完全一致地記住他們所看見的東西（回憶錯誤）。如果我們意識到這2類錯誤，我們就能理解和我們處於同一類但是稍有誤差的其它觀察者了。畢竟那張幻燈片才放了不超過1分鐘，而且在這之前從未被強調過，幾乎沒有人會認爲那個破星星會是本次研討會的主角。 理解錯誤。剛纔說到，我們可能會驚訝於那些與我們的回答截然不同的答案，這很大程度上是因爲彼此對問題含義的理解不同。我們詢問了回答這些答案的一部分參與者，分析如下：認爲答案是0～2的回答者認爲Gause先生問的是那個7角星星裏面的兩個黑點。認爲答案是5～9的回答者認爲Gause先生問的是那個大7角星有幾個角頂點。認爲答案是13～16的回答者則把7角星的內外角頂點都算在內了。認爲答案是正無窮大的回答者則認爲每條線段上都包含了無窮多個點。 問題描述的含混性。還有兩類人好像無法用理解錯誤來解釋，實際上認爲答案是21～32的回答者認爲Gause先生問的是第二張幻燈片中的星星個數。很顯然，他們認爲那個聚焦幻燈片是第二張。 |
不僅如此，由於作弊、參與者之間的交流、對上述分類結果思考之後再對答案的修改等等因素，還會改變回答者的答案。這些改變應該是來自於對問題的理解，而不是改變了回憶或提高了觀察力。
【道可道，非常道】
按照我們前面的說法，與會者的答案的差異大致有4中可能來源。而且看起來我們都能夠理解前面三種來源，即觀察、回憶和理解錯誤，因爲這三項來源都與觀察者自己有關，本着嚴於待人、寬於待人的原則，我們的確需要着重地強調第四個含混性來源，也就是：
| 問題描述的含混性 |
這一來源在上節中被一筆帶過了，因爲這實在不是凡人所能夠搞明白的。我們這裏也僅僅是根據研討會的現場結果，給大家展示這一來源的五花八門。第4、5個問題如下：
問題4、發揮你的回憶能力，逐字寫下在問題1中你認爲你所回答的問題。
答案只有你知道。不過現在要把這個答案拿出來，以作它用。
問題5、有100個人和你一樣會回到第4個問題，即寫下他們所認爲的那個英文問題，你認爲他們所寫下問題的有些什麼差別，也把它記下來。
很顯然，由於我們在回答問題的時候，已經看不到幻燈片上的問題，也看不到那張所謂用於聚焦的幻燈片，因此我們的回答很大程度上會依賴於問題本身的明確程度。如果我們看到的問題是“What’s your mother’s name?”或是“你媽貴姓？”之類的問題，我相信除非是你完完全全心不在焉，否則即使是過了1個星期，你一樣能夠清楚地回憶起這個問題。但是現在地結果卻並不那麼明確了。
前面說過，我們中的大多數總是把自己定位在掌握了真理那一羣人裏面的。也就是說，我們相信我們自己的判斷和記憶。因此，我們很容易會認爲我們自己和別的參與者一樣，都是在討論同一個問題。這個時候，我們會很自信地寫下問題4和問題5的回答，並相信自己最多會記錯兩個單詞。
然而結果卻讓我們大吃一驚。我們列出了實際收集的問題4的一共24種回答：
| 序號 | 答案 （英文） | 答案 （中文） |
| 1 | How many points did the star have? | 這個星星有多少個點（頂點）？ |
| 2 | How many points were there in the first slide? | 第一張幻燈片中有多少個點？ |
| 3 | How many points did the star have in the first slide? | 第一張幻燈片中的星星有多少個點（頂點）？ |
| 4 | How many points were on the star that was used as a focus slide? | 在那個用作聚焦幻燈片的星星上有多少個點？ |
| 5 | How many points were on the star in the first slide of this presentation? | 在這次展示中的第一張幻燈片中的星星上有多少個點？ |
| 6 | How many points were in the focus star at the beginning of this presentation? | 在這次展示開始的聚焦星星中有多少個點（頂點）？ |
| 7 | How many points were on the star that was used for focusing? | 用於聚焦的星星上有多少個點？ |
| 8 | How many points did the star used for focusing at the beginning of the presentation have? | 在展示開始的時候用於聚焦的星星有多少個點（頂點）？ |
| 9 | How many points (external) are on the star I used to focus? | 我用於聚焦的星星上（外部）有多少個點？ |
| 10 | How many points were there on each star on the slide used for focusing? | 在用於聚焦的幻燈片上的每個星星上有多少個點？ |
| 11 | How many points did the star have that was used as a focus slide? | 用作聚焦幻燈片的星星有多少個點（頂點）？ |
| 12 | How many points were on the star that was used to focus at the start of the class? | 在課程開始時用於聚焦的星星上有多少個點（頂點）？ |
| 13 | What was the number of points on the star slide that was used to focus on? | 用於聚焦的星星幻燈片上點的數目是什麼？ |
| 14 | How many points were in the focus slide star? | 在聚焦幻燈片星星中有多少個點？ |
| 15 | How many points in the picture of the star, used as a slide? | 用作幻燈片的那張星星圖片中有多少個點？ |
| 16 | How many points were there in the star on the slide? | 在幻燈片上的星星中有多少個點（頂點）？ |
| 17 | How many points were shown on the test star? | 在測試星星上出示了多少個點？ |
| 18 | How many points are on the star slide used to focus at the beginning of the slide presentation? | 在幻燈片展示開始時用於聚焦的星星幻燈片上有多少個點（頂點）？ |
| 19 | How many points did the star shown at the start of the presentation have? | 在展示開始時展示的星星有多少個點（頂點）？ |
| 20 | Determine how many points were present in the star shown earlier in the slide presentation? | 確定在幻燈片展示的早期出示的星星中呈現的點數？ |
| 21 | How many points were there in the original foil which was used to focus the foil? | 用於聚焦葉形圖的原始葉形圖中有多少個點？ |
| 22 | How many points were on the star that was shown at the beginning of the lecture? | 在演講開始時出示的星星上有多少個點？ |
| 23 | How many points were on the focus slide? | 在聚焦幻燈片上有多少個點？ |
| 24 | How many points were on the star shown as the first slide? | 在第一張幻燈片中出示的星星上有多少個點？ |
| How many points were in the star that was used as a focus slide for this representation? | ||
我們在上表的最後一行重新寫上了幻燈片上真正的問題，很顯然，這一個真正的問題已經讓100多個參與者摸不着頭腦了。如果，這樣的問題描述出現在需求規格說明書當中；如果，我們的設計人員、客戶、編程人員、銷售人員在實際工作中不是一詞一句地記熟了所有條款，這樣的24個答案隨時會出現在真實的項目中。
我們在這個問題上找到了很多含混不清的詞語，而且確實是這些看起來非常瑣細的細節，給問題帶來了截然不同的理解、回憶等等；這種問題描述的含混性實際上已成爲成功項目和災難性項目之間的分水嶺。
【誡條】
1、 撒旦總是在你最不留神的時候誘惑你。含混性也總是在你最不留神的時候出現，並且，這種含混性最不容易被發現，也會給設計開發帶來最大的災難。
2、 觀察錯誤、回憶錯誤、理解錯誤是最常見的含混性來源。我們有很多種找到它們的方法，實際上，更重要的是意識到它們存在的風險，並採取行動。
3、 問題描述中的含混性是最難於處理的來源，它也是前述3種錯誤的誘因。由於這些含混性將是開發成敗的關鍵，因此給我們的需求工作提出了非常苛刻的要求，而本文後續介紹的經驗和工具，正是爲這一工作所設計的。
4、 找出含混性來源的辦法推薦如下：
a) 對參與者進行需求文檔某些部分的解釋進行提問，並把相近結果歸成一類。
b) 通過詢問每一類中的人們的想法來分析對每一類的理解。
c) 同一類內部的差異來自於觀察錯誤和回憶錯誤。
d) 爲了辨識各類之間的差別，可以請參與者回憶那個他們認爲的被問的問題，當然不能給他們再看一遍。這個種方法能夠找出解釋錯誤。
e) 通過對觀察、回憶、解釋錯誤的分析，找出問題描述中易犯上述錯誤的地方，修改它，或者做一些詳細的註記。
4 逃跑的僱工
作者：章柏幸
[email protected]
12若是僱工，不是牧人，羊也不是他自己的，他看見狼來，就撇下羊逃走。狼抓住羊，趕散了羊羣。
13僱工逃走，因他是僱工，並不顧念羊。
人往往如此；當你瞭解、學會、掌握、熟練了一種工具之後，就很難接受別的類似工具；而對於那些本質上並不類似的工具，人們也會自然地產生排斥心理，會說，“你的功能我們的工具一樣可以實現。”
有頭腦的人，是不會僅僅侷限於一兩種工具的，因爲他們知道，每一種工具都有它的針對性和侷限性。古話“術業有專攻”也是這個道理。那麼，爲了很好地搞定我們的項目（產品）開發，我們一樣需要有專門的工具和技術；針對於需求分析中的某些關鍵點，我們還需要對之進行更深入的研究。目前市面上有很多很多的項目管理的工具、方法以及軟件，是否只要使用好它們我們就能一路順風了呢？
我們認爲，掌握各種各樣的工具是很不錯的主意；而且，如果你想很好地做好需求工作，最好能很好地把握直接的提問、面對面的觀察和談判技巧。但是，出於對工具侷限性的擔心，我不得不提醒讀者再次注意人類思想的複雜性和含混性。我們常常會看到一些理想主義的需求分析員編制各種各樣的表格和調查問卷，然後根據表格裏面的文字和數據來撰寫他們的需求規格說明書；這一節就是要說明這種死板的方法是不能夠完全正確地獲得需求的。
【盡心盡責】
《探索需求》一書中提出探索過程是對決策樹從根節點到葉子節點的一次遍歷，我在這裏做一個簡單的解釋，在後面我們將作一個簡單的拓廣。
| 數學模型是一種對現實世界的抽象。比如，現實生活中的樹從樹根開始，在陽光的照耀下，按照主幹、分支、細枝、樹葉這麼一級一級地成長。由於數學家和程序員的工具的侷限性，即我們的打印紙和書寫習慣都是從左到右和從上到下的，於是我們得到的樹的數學模型變成了樹根在上，葉子在下的樣子了。這個樣子雖然很難看，但我相信讀者已經都能夠接受這種模型的，理由是我們從中學到大學已經對這種符號系統接受了一些培訓，這一點反過來說明了我們在第1章《賊和強盜》中關於符號系統和映射需要培訓的論點。 決策樹模型是對線性決策理論的一種數學模型，我們借來作爲對直接提問方式的輔助工具：它的根節點是對問題的第一個模糊的描述。每一個節點表示一次提問或決策，而到達的葉子節點則是最後的解決方案。很顯然，一棵正常的樹不會一根枝丫長到底；同樣，我們的直接提問也不可能一帆風順。每一個分枝的地方，都會出現多種分岔的選擇，而每一種選擇，都意味着放棄了另一個更爲廣闊的含混空間。 |
理想主義者認爲只要每一個選擇都由用戶判斷，每一個決策都經過用戶簽字，那麼他們的決策樹很快就能安全抵達葉子節點。（這種想法是要不得的，但這是後話，暫時不提。）我們暫且認同每個判斷的正確性和明確性，這於是給我們的決策帶來了嚴重的壓力，每一個分枝的地方都會有明確的用戶配合嗎？這是天真的想法。我們不可避免會加入我們自己的“經驗”，實際上是我們的假設。
首先需要說明的是，決策的次序非常重要。比如，如果客戶想要一輛綠色自行車，那麼如果給他一輛橙色自行車可能會比一個綠色卡車來得比較容易接受。因此，問題“它是什麼顏色的？”和問題“它是自行車還是卡車？”相比較而言應該問得較晚。次序的重要性還體現在它能夠減少我們爲錯誤決策減少修復誤差。
| 如果您學過信息理論，那麼我們就可以量化這種問題次序的價值。解決方案是一種逆天而行的行爲，它試圖通過人類的智慧，在局部地區實現反熱力學第二定律的走向。 我們的信息度量是這樣的：最初，含混的問題具有無窮多種可能性，其信息量爲零，其含混性爲無窮大，其信息熵也爲無窮大。每一個問題的回答，都能夠減少可能性，降低含混性，提高信息量，降低信息熵。針對每一個問題的重要程度，我們可以通過經驗或是客戶聯席會議來確定其量化的加權值，該加權值就是這個問題的價值，也可以看做是問題的信息量。根據最優編碼定理，我們可以得到每一個問題對應的Huffman碼值，這一Huffman碼值的長度就是我們應該對該問題的重視程度的度量。 |
下表列出了一個典型的設計案例中的直接問題問答，根據客戶對10個問題的回答，讀者心裏是否已經對需要解決的問題有了一個方案了呢？
| 序號 | 問題 | 回答 |
| 1 | 需要我們幹什麼？ | 設計一個運輸設備 |
| 2 | 有什麼時間限制？ | 在18個月之內完成 |
| 3 | 運輸什麼東西？ | 人 |
| 4 | 每次可以運輸多少人？ | 每次一個 |
| 5 | 動力來源是什麼？ | 乘客自己提供動力 |
| 6 | 在什麼樣的表面上運輸？ | 它應該在很硬的平坦地表上提供運輸 |
| 7 | 人應該被運輸到多遠？ | 超過2千米。 |
| 8 | 設備的行進速度？ | 至少每小時能行進400米。 |
| 9 | 故障率方面的指標怎樣？ | 每三千里的里程最多有一次故障。 故障發生時不能危及乘客的生命安全。 |
| 10 | 大概要多少成本？ | 分攤到每次使用的成本不超過200元。 |
【迷途羔羊】
經超過1000名專業系統設計者證實，上表中的對話是一個優秀的問題系列。我們很快可以作出我們需要產品的可能選擇：
1、 溜冰鞋。
2、 自行車。
3、 三輪車。
本來我們是很願意想到電瓶車的，但是由於問題5的答案讓我們放棄了這種安全綠色而快捷的交通工具。因此我們選擇了自行車作爲備選。
本來我們也是很願意想到滑翔機的，但是由於問題6的答案讓我們放棄了這種天空中翱翔的念頭。
很顯然，上述三種選擇都能夠滿足上述10個條件，我們注意到這三種運輸設備都有一個共同點，那就是都有輪子。爲了保證我們的設計能夠被客戶接受，我們把設計人員分成兩組：小輪子組和大輪子組。兩組設計人員都完成了創意精彩的解決方案。
小輪子組遞交了一種多功能溜溜鞋，它可以採用便捷的即插即用技術，溜溜鞋的底部安裝了一個牢固的插槽，它可以裝上冰刀、滾輪以及撬板等多種標準接口附加配件。設計人員還公佈了溜溜鞋標準插槽接入標準方案，擬在業界推廣。另外，額外的銷栓裝置能夠大大降低故障率。大輪子組遞交了一個緊湊的、不重的、可摺疊的三輪車，它可以放在步行者的旅行包中帶走。
下面是我們在客戶那裏展示樣品時的場景：
| 兩個客戶來觀看我們的樣品，他們對我們的創造讚不絕口，尤其是那個三輪車的輕便性。可是，其中一個問道：“請諸位解釋一下這種設備如何在艾格爾上的北坡用於救援登山者。” 我們呆在那裏了。你是否也呆在那裏了？ 客戶解釋說： 在他們的腦海裏那是一個登山者救援設備，他們兩人分別是梅隆鎮和比斯鎮的鎮長，由於兩鎮的經濟主要依賴於旅遊和特殊登山。爲了保持旅遊業的增長並確保登山的回頭客，村莊的正式導遊必須去救助那些被困在山坡上的登山者。然而，隨着人們對生命的重視，導遊們越來越不願意爲救助粗心的登山者而冒生命危險了，因此他們的隊伍越來越小。鎮長們認爲，除非有一個解決方案出現，否則村莊的經濟將會受到威脅。 因此，鎮長們需要一個營救設備，這樣他們就能讓所有登山者都可以嘗試去攀登垂直高度爲1500米高山峯北面。登山者不論在什麼時候因爲惡劣的天氣、精疲力竭、受傷、害怕或是供給不足等原因必須返回時，這個設備就可以投入使用，以着陸到硬的平坦地面上。這一設備可以在任何村莊租用，每次租用繳納一定押金，租用費用爲每次400元，這樣每次租用村莊就能獲得大約200元的毛利；當然，是用於挽救生命的。 |
很顯然，我們迷路已經很遠很遠了。
我們不妨回頭看看我們的道路，客戶很客觀很配合地回答了我們的直接提問，而我們在構建決策樹、探索解決方案時給方案添加了大量的假設。例如：
1． 有輪子的。
2． 在硬的表面運輸的水平運輸裝置。
3． 不會飛的。
4． 這種設備是緊湊的。
5． 設備的高輕便性。
6． 產品的銷量很大，因此單位生產成本很小。
或許我們可以記住：
僅憑經驗，並不能說明我們就能很好地把握“知識”與“需求”之間的關係。
【惡在人間】
前面的例子似乎有點刁難，但它能夠很好地模擬那些喜歡在一個小房間裏面設計項目中的含混性；這種情況往往會在剛從理想主義象牙塔裏面出來的人們中發生。許多實際案例中，含混性程度並不那麼明顯，但是分佈之廣卻有過之而無不及。
| 有一次，我們在對一個在線銀行系統的需求規格說明書的複審中，光在第8頁就發現了121個地方可以被不同的複審者用至少2種方法解釋的含混點。這僅僅是886頁需求規格說明書中的一頁。我們可以估計一下，這種需求中含混點大概會有886*121=107206個。如果我們的設計人員遵從這份需求來進行設計，那麼這些含混點都需要它們通過猜測來決策。那麼，我們每次猜中正確含義的概率又有多少呢？ ――溫伯格&高斯 |
我們說，我們需要一些額外的工具和技巧來降低含混性；這是因爲“我們常人並不擅長於發現我們已經忽略的東西”。這種心理學上的觀察結果實際上嚴重地困擾了我們這些設計者。例如說，我們無法用肉眼看到X射線，我們無法用自己的耳朵聽到超聲波，我們無法步行漫遊世界。
自然，我們不會因此爲上述不足感到不安；那麼，我們爲什麼要爲自己未能夠發現那些自然忽略的內容而內疚呢？正是因爲上述不足，人們發明了各種各樣的工具來獲得成功；同樣地，我們不妨也可以接受這些用於需求分析中降低含混性的工具和技術了。
這些工具和技術，我們可以在《探索需求》中找到；當然，如果我們願意的話，不妨關注一下這個系列文章的續集。
【誡條】
1、 分歧無處不在，設計者最容易自以爲是地認爲他們心目中的解決方案就是客戶想要的，而實際上這往往給客戶強加了很多假設。即使我們發現我們的解決方案遠超過客戶所知，千萬不要過度自滿，要麼去說服他們，要麼去尋找能接受你的方案的新客戶。
2、 直接提問時，可以使用決策樹。但是千萬注意對每一個問題的回答進行一次口頭的和書面的確認，即把客戶的回答寫出來給他們看，這可以鍛鍊你的文字表達力，也是降低含混性的技巧。
3、 有責任的需求工作者接受我們的思想，但是他們開展工作的困難不止來自於客戶，也會來自於他們的那些守舊的同事。我們必須說服這些人，最好的方法就是舉一些你們共有的失敗的例子。不過千萬注意不要讓對方難堪。
4、 理解並接受自己的侷限性，同樣也理解並接受客戶和同事的侷限性。