從需求到設計：如何設計出客戶想要的產品 Exploring Requirements: Quality Before Design ———————————– 作者： 唐納德．高斯，傑拉爾德．溫伯格/著 譯者：褚耐安 出版社：經濟新潮社 ISBN： 9789867889584

內容簡介
大約有90%的產品開發案是失敗的，其中30%並沒有開發出任何產品，其他的雖然有產品問世，但人們不喜歡，或從來不使用；即便使用了，也是毛病一大堆。

做好需求分析，是新產品成功的關鍵

暢銷書《你想通了嗎？》兩位作者又一傑作。他們總結與各大小企業合作60餘年的經驗，來探討新產品開發過程中，最困難的部分——如何設計出「高品質」的產品或系統。在本書裡「品質」的定義是：「符合客戶的需求」。

但是，為什麼有那麼多新產品專案會胎死腹中？……為什麼新東西要符合我們的需求這麼難？由此看來，客戶需求、品質、與客戶溝通、設計等等環節，都大有學問。而且，可能客戶「自己都說不清楚自己要什麼」。

因此，要做出客戶想要的產品或系統，不僅需要專案管理的技巧，還要先做好「客戶需求分析」，這就是本書的主題，內容包括：需求要件（requirements）、減少語意曖昧（ambiguity）、使用者參與、激發概念的會議、專案命名、調和衝突、客戶要什麼（功能、特性、限制、偏好、期望）、技術審查、測試使用者滿意度、黑箱測試等等。還有實際案例貫穿全書，以及豐富的心得分享與建議。書中提到的技巧，曾經成功運用於許多產品或系統──包括電腦硬體、電腦軟體、家具、建築物、書籍等。

本書對於新產品專案的所有利害關係人——團隊成員、客戶、使用者、還有必須綜觀全局掌控進度的經理人，都大有幫助。「工業設計」正在流行，本書可以幫助你有效帶領團隊，讓專案邁向成功！

作者簡介
唐納德．高斯（Donald C. Gause）和傑拉爾德．溫伯格（Gerald M. Weinberg）是國際知名的顧問，也同為美國計算機協會﹝ACM﹞的講師。他們長期合作各式各樣的計畫，還合著有《你想通了嗎？》（經濟新潮社出版）。

唐納德．高斯是紐約州立大學賓漢頓分校Thomas J. Watson工程學院的系統科學教授。他的研究重點是：複雜系統的設計與開發，以及大企業的創新。

傑拉爾德．溫伯格是美國軟體工程界大師級人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家，因對技術問題與人性問題所提出的創新思考法而為世人所推崇。1997年，溫伯格因其在軟體領域的傑出貢獻，入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J.-D. Warnier獎項中的「資訊科學類卓越獎」，此獎每年一度頒發給在資訊科學領域對理論與實際應用有傑出貢獻者。

溫伯格共寫了30幾本書，包括《顧問成功的祕密》、《領導的技術》（以上由經濟新潮社出版）、《程式設計的心理學（25週年紀念版）》、一共四冊的《溫伯格的軟體管理學》等。他的著作主要涵蓋兩個主題：人與技術的結合；人的思維模式、思維習慣與解決問題的方法。在西方國家，溫伯格擁有大量忠實的讀者群。溫伯格現為Weinberg and Weinberg顧問公司的負責人，他的網站是www.geraldmweinberg.com

我在看一本書的內文之前，一定會先對書名來思考該書背後蘊藏的內涵，本書的英文全名是：「Exploring Requirements: Quality Before Design」， 這讓我會聯想到：需求是什麼、為什麼要探索需求、哪時候需要探索需求、誰需要探索需求，需求的對象是誰、又該如何探索…；然後從副標題顯然可以知道，需求是在設計之前必要的階段，需求的品質，會影響到設計的好壞，它甚至是決定最終產品成敗的最要關鍵，因為畢竟，需求是直接貼近使用者端，是站在客戶的角度來看待產品的好用與否。

本書的兩位作者：Gause(高斯)、Weinberg(溫伯格)，前年我正巧買了他們合著的一本：「你想通了嗎？(Are Your Lights On)」，是探索表面浮現出的問題，其背後所蘊含的問題本質，再從根本進而找到解決方案(Solution)，寫得可真好。而在書局，尤其是在賣軟體叢書的書店，出現了多本溫伯格的著作，從「系統化思考」到「顧問成功的秘密」。我發現到，溫伯格早期雖然是從事電腦軟體系統的技術性開發，但他也瞭解技術所不能涵蓋的層面，所以進而研究與探索在人文方面的領域，後期的著作，已經是被歸類為企管與專案管理方面了。我個人非常欣賞溫伯格的寫作風格，更是讚嘆他在書中所表現出的智慧。利用一些淺顯易懂的幾個案例，來探討所討論的主題，再釐清該主題的本質，然後來找出一些方法與手段來解決問題。不像坊間一般專案管理的書籍，是偏向功法，沒有先釐清問題的本質，就直接往工具與方法來尋找，這會造成見樹不見林，那個根本就不見了，如此而會形成整體性的複雜；而本書則是兼具了心法與功法，先從需求的根本談起，然後利用一些簡單的對話案例，來探索各種技巧與方法，淺顯好懂，又能釐清需求的本質。

本書前言，一開始即引用馮紐曼的名言：「如果你不了解自己所說的事物，即使你遣詞用字精確，也毫無意義。」 如果設計產品的設計者並沒有試圖去瞭解使用者真正的需求與期望，或如何來引導顧客發掘出潛在的需求，那麼，無論你設計的多好，多麼有效率，問題是，沒有切中要點(顧客想要的)，一切都是枉然，這也就是我們為何要進行需求分析作業，這樣，我們才不至於設計出人們不想要的系統。 我覺得，需求就是一種目標導向的工作，若是設錯了靶，射擊者即使是神射手也是徒然的。「不值得做的事情，就不值得把它作好。」，我個人非常喜歡這句話，這句話可以延伸出太多的意義，如本書提到在探索需求的程序上：「產品不重要，重要的是過程。」/「文件不重要，重要的是建立文件這件事。」 我更是想延伸這句話為：「專案不重要，重要的是專案開發的過程。」嗯，不過這句話可是又要引起諸多專案管理者的抨擊與批判了。  從此句話也就帶出了本書的目的：「發現什麼並不重要，重要的是發現(探索)的過程。」這本書要討論的就是，在需求作業的程序，也就是開發過程中，人們試圖發掘什麼是人們想要(people attempt to discover what is desired)的過程。

本書內容大綱分為五大部分：先有一點共識；起步的方式；探索各種可能性；釐清客戶的期望；大幅提升成功機率。

先有一點共識，當然整個重點就在於 溝通 的議題，不只是設計團隊成員們之間的溝通，更是需要懂得如何與顧客溝通，以瞭解顧客真正的需求。光有工具與方法是不夠的，你真的需要釐清需求的本質為何。書中舉了一個有趣的例子，某一項產品，蟑螂必殺器，操作很簡單：把蟑螂放在底板上，用上蓋合下底板，壓死蟑螂，清除屍體。重點是，從來沒有人會用到最後一項的步驟，因為，沒有人可以把蟑螂放到底板上。這代表什麼意思呢？ 需求可不是固定不變，你不可能直接抓得到它，讓它們靜止不動。需求的探索作業是動態、持續不斷的過程，在這過程中，我們是透過一次次的釐清需求要件，將範圍逐步收斂，使結果接近我們想要的—也只包括我們想要的。同時我們也需要去除在需求文件上關於語意曖昧(ambiguity)的問題，因為如此會造成同一需求有多種的解讀，會容易引起誤解甚而衝突。而在需求溝通的會議上，客戶的參與是必要的，但可不要過份表現專業，高高在上，使得客戶有恐懼或防衛的心態；如果能營造出分享專業知識的氣氛，客戶將樂於參與設計工作。溝通的文件部分，除了文字的表達，「一圖勝過千言萬語。」利用圖形的表達，一直是人們擅長溝通的利器，只是要注意的是，圖形的表達最好能有標準化的語法(notation)，例如在軟體界通用的 UML(Unified Modeling Lanaguage)，即是國際標準的圖形語法。本部分最後一段即提及，如果你希望成為一個能力高強的需求分析設計者，最好嫻熟直接詢問法，以及直接觀察法，以及一般的問答技巧。設計者的重大錯誤之一，即是試圖給予客戶需要的東西，而不是給予客戶想要的東西。如果你覺得自己比客戶更瞭解客戶的需要，不可覺得自己比客戶聰明。相反地，你應該說服客戶，他們需要你認為他們需要的東西。

起步的方式這一部分，提到了，所有的釐清需求作業進行之前，都會先有某種初始程序：某人興起一個概念(idea)，想要設計或建構某個東西。無論這個概念由何而來，這個概念即是需要作業程序的起點。如果參與者在開始思考時無法協調一致，那麼在你還沒有獲得他們真正參與之前，你就會失去他們。所以對於客戶，你必須「因材施教」，如何對概念能有一致性的見解。顯然，提出開放式的問題、找對的人參與、舉辦有效率的會議，以及減少語意上的曖昧，都是好的開始。但是注意的是：我們最常見的起點或許是：還沒有陳述該解決的問題(也就是某人所感受到的和所期望的)，就開始思考解決方案。請注意這一點，在需求分析階段，重視的是 “What”，而不是 “How-to”；專注在使用者想要什麼，而不是急著找出如何解決的方案，因為，這很容易誤解的問題的本質，而耗費許多不必要的白工。

第三部分是關於到探索各種可能性。為取得一致性共通的概念，溫伯格提出了「探索螺旋(Spiral of Exploration)」的方式。這太棒了！ 這與我個人在軟體專案的開發流程上，完全是相同的本質觀念，也就是，抵達終點並非是直線的前進，而是以目標為中心的螺旋路徑。走一點，遇到障礙，修正，再往前走．．． 這才會是最佳的實務，來逐步接近目標。這一部分也提到了工具的使用，不過，工具並不一定是指實體的工具，如瑞士刀，人類的大腦也是工具，例如，我們可以運用右腦創意、直覺與聯想的天賦，利用腦力激盪(brain-storm)的會議，來找出更多的概念。由於是工具的應用介紹，我倒不覺得書中所提出的方法是絕對有效必要的，例如，我就會利用心智圖(mindmap)的方式，運用大量關連的方法，來建構與整理以概念為中心的記憶樹；甚而，也可以多人腦力激盪，以遊戲的氣氛與心態，共同來完成需求主題的建構。還有，在「調和衝突」這章，溫伯格提出了人與人之間互動合作必然會引起的衝突，而衝突發生後，該如何調和。他提出了一個有趣的建議方案：若專案不可或缺的兩人呈現對立態勢，兩個都開除！ (道理很簡單，避免專案被這些自以為是關鍵人物的拿翹與勒索)。

第四部分是提到了客戶的期望。首先說明了關於功能的定義與該如何界定，如何掌握所有的功能需求，如何分辨 顯著(Evident)功能、隱藏(Hidden)功能、附帶(Frill)功能 等，然後又以每一章節來說明 特性、限制與偏好 等與功能相關連的因素。功能要完善，又要能凸顯功能的特性，但是又不可能無限延伸；如何來限制功能需求是在合理的解決方案空間內(solution space)；如何瞭解客戶的偏好，而不是設計者自己的偏好；然後，偏好與限制，有時又好像蠻模糊的，例如，完成系統設計的最後期限，對團隊而言，是項限制；對老闆而言，卻只是一項偏好，而且是溫和的偏好。

最後，大幅提升成功機率，這一部分提到關於測試的部分，是我非常感興趣的。我也發現到，以我擔任軟體架構師，一直力主推動的 “測試案例” 與 “功能測試”，又是與本書的內容是一致的，這可真開心。我是覺得，若是「以人為本」的系統開發，其本質道理是一致的，這絕對不可能會是主要以工具或程序就能達成的。測試案例(test case)，就是由使用者提出測試的劇本與數據，針對可量化一個個的功能，以黑箱(black box)的手法來測試，黑箱的概念只重視 “輸入” 與 “輸出”，這其實就是針對功能性的測試。界定需求要件時，可以運用黑箱概念：因為設計案在這個階段，解決方案確實是個黑箱。而設計工作即是將黑箱轉變為白箱，我們能清楚看見這個箱子如何運作。黑箱測試作業不可以延緩，應該在界定問題階段，就進行黑箱測試；而不是提出解決方案階段，才進行黑箱測試。也就是在你不必承諾可以達成什麼的時候，盡力先瞭解客戶想要的是什麼。還有特別要注意的是，測試案例的結果必須要請客戶簽名，否則未經簽名的文件只是沒有價值的紙頭，簽名能增加價值。最後一個章節，溫伯格總算提到了，這也讓我確認了需求的本質，也就是：任何一個真實世界中的專案，不論規劃如何完善，管理如何優良，都包含若干灌木枝芽；因為真實世界總是和我們的假設作對，憎惡灌木叢法的人，可能會想去創造完美的需求要件作業，他們正是創造「植物人」式需求要件作業的人。甚麼是灌木叢法？ 需求不明確，試行、修正，然後再試做… 直到認為滿意了，就停止。 溫伯格是認為，這種方法相當務實卻沒有主幹(主軸)，而是有一堆枝芽、許多葉片。在軟體開發的程序上，其實這種方法就是應用在 “反覆與漸增(I&I, Iteration and Incremental)” 的開發實務，只是以我個人在帶領團隊成員開發時，必然會先建立一個整體觀；以架構為中心。這也同時解決了灌木叢法缺乏了主幹的缺陷。 本書結尾的最後一節：繼續溝通。因為，瞭解需求本質的人都知道，凍結需求的觀念其實是一種妄想，用來抵制對於需求要件作業結束的恐懼。除非確知有再溝通的可能，我們無法放心地結束需求要件作業。所以，需求要件作業的最後一個步驟就是：雙方同意繼續溝通！

本書給我最後一個感想就是：客戶端與設計團隊不應該是衝突、對抗的(現實經常如此)，應該是要能 和解共生；同時，專業設計團隊要學會能 不卑不亢！ 不是對客戶卑躬屈膝，但也不需要表現得高高在上，保護自己。