從需求到設計：如何設計出客戶想要的產品（十週年紀念版） (電子書)

目錄

致台灣讀者／溫伯格
推薦序 從需求到設計，解析消費者的需求／陳禧冠
前言

第一部　先有一點共識

第一章　光有方法，還不夠
第二章　需求要件語意曖昧
第三章　語意曖昧的原因
第四章　直接詢問法的侷限

第二部　起步的方式

第五章　開始
第六章 開放式問題
第七章 找到對的人參與
第八章　有效率的會議
第九章 努力減少語意曖昧

第三部 探索各種可能性

第十章　激發概念的會議
第十一章 運用右腦
第十二章　專案的名稱
第十三章　調和衝突

第四部　釐清客戶的期望

第十四章　功能
第十五章 特性
第十六章　限制
第十七章　偏好
第十八章　期望

第五部　大幅提升成功機率

第十九章　判斷語意曖昧的基準
第二十章　技術審查
第二十一章 測試滿意度
第二十二章　測試案例
第二十三章 研究現有產品
第二十四章　意見合致
第二十五章　結束

參考書目
致謝

致台灣讀者 傑拉爾德‧溫伯格

最近，我很榮幸地得知，台灣的經濟新潮社要引進出版拙著的一系列中譯本。身為作者，知道自己的作品將要結識成千上萬的軟體工程師、經理人、測試人員、諮詢顧問，以及其他相信技術能為我們帶來更美好的新世界的人們，我感到非常驚喜。我特別高興我的書能在台灣出版，因為我有個外甥是一位中文學者，他曾旅居台灣，並告訴過我他的許多台灣經驗。

在我早期的職業生涯中，我寫過許多電腦和軟體方面的技術性書籍；但是，隨著經驗的增長，我發現，如果我們在技術應用和建構之時對於其人文面向沒有給予足夠的重視，技術就會變得毫無價值－－甚至是危險的。於是，我決定在我的作品中加入人文領域的內容，並希望讀者能注意到這個領域。

在這之後，我出版的第一本書是《程式設計的心理學》（The Psychology of Computer Programming）。這是一本研究軟體開發、測試和維護當中關於人的過程。該書現在已經是25週年紀念版了，這充分說明人們對於理解其工作中人文部分的渴求。

各國引進翻譯我的一系列作品，讓我有機會將這些選集當作是一個整體來思考，並發現其中一些共通的主題。自我有記憶開始，我就對於「人們如何思考」產生了濃厚的興趣；當我還很年輕時，全世界僅有的幾台電腦常常被人稱為「巨型大腦」（giant brains）。我當時就想，如果我搞清楚這些巨型大腦的「思考方式」，我或許就可以更深入地瞭解人們是如何思考的。這就是我為什麼一開始先成為一個電腦程式設計師，而後又與電腦共處了50年；我學到了許多關於人們如何思考的知識，但是目前所知的還遠遠不夠。

我對於思考的興趣都呈現在我的書裡，而在以下三本特別明顯：《系統化思考入門》（An Introduction to General Systems Thinking，這本書已是25週年紀念版了）；它的姊妹作《系統設計的一般原理》（General Principles of Systems Design，這本書是與我太太Dani合著的，她是一位人類學家）；還有一本就是《你想通了嗎？》（Are Your Lights On?: How to Figure Out What the Problem Really Is，這本書是與Donald Gause合著的）；一本《從需求到設計》（Exploring Requirements: Quality Before Design，也是和Donald Gause合著，談的是人們如何去思考他們在系統中的價值）。

我對於思考的興趣，很自然地延伸到如何去幫助別人清晰思考的方法上，於是我又寫了其他三本書：《顧問成功的祕密》（The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully）；《More Secrets of Consulting: The Consultant’s Tool Kit》；《The Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products》（這本書已是第三版了）。就在不久前，我寫了《溫伯格談寫作》（Weinberg on Writing: The Fieldstone Method）一書，幫助人們如何更清楚地傳達想法給別人。

隨著年齡的增長，我逐漸意識到清晰的思考並不是獲得技術成功的唯一要件。就算是思維最清楚的人，也還是需要一些道德和情感方面的領導能力，因此我寫了《領導者，該想什麼？》（Becoming a Technical Leader: An Organic Problem-Solving Approach）；隨後我又出版了四卷《溫伯格的軟體管理學》（Quality Software Management），其內容涵蓋了系統化思考（Systems Thinking）、第一級評量（First-Order Measurement）、全面關照的管理作為（Congruent Action）和擁抱變革（Anticipating Change），所有這些都是技術性專案獲得成功的關鍵。還有，我開始寫作一系列小說（第一本是《The Aremac Project》）是關於專案及其成員如何處理他們碰到的問題──根據我半個世紀的專案實務經驗所衍生出來的虛構故事。

在與各譯者的合作過程中，透過他們不同的文化視野來審視我的作品，我的思考和寫作功力都提升不少。我最希望的就是這些譯作同樣也能幫助你們──我的讀者朋友──讓你的專案、甚至你的整個人生更成功。最後，感謝你們的閱讀。

前言

　　產品開發的工作就是：將某人的想望（desires），轉化為能夠滿足這個想望的產品的過程。本書要討論的是需求要件作業程序（requirements process）──也就是開發過程中，人們試圖發掘什麼是人們想要的（people attempt to discover what is desired）的過程。

　　為了了解這個程序，讀者們必須注意五個關鍵詞：想望、產品、人、試圖、發掘。

　　首先，考量「想望」（desire）這個詞。有些讀者比較喜歡說成「試圖發掘什麼是人們需要的（needed）」。但是相對於人們想要的，我們更不知道如何找出人們的需要。此外，人們並非總是購買他們需要的東西，但總是想望他們所購買的東西，雖然想望是會改變的。我們發現，藉由釐清他們的想望，人們可以釐清他們真正需要的，以及不需要的是什麼。

　　「產品」（product）這個詞，我們指的是，可以滿足一套複雜想望的產品。想望複雜的原因之一是，它們是許多人的想望的集合。當我們製作一項可滿足自己想望的產品──譬如一個花園，或一個書架──通常不需要進行明確的探索需求作業。我們只需動手做出來，檢查一下，然後修改到我們自己滿意就行。

　　但「人」（people）可能包括許多不同的人。發掘他們究竟是哪些人，是需求要件作業的主要部分。如果參與的人很多──而且產品巨大──逐一發掘每個人的需求，顯然是一項冗長、昂貴、高風險的工作。

　　「試圖」（attempt）又是什麼呢？如果我們寫一本書，不是應該對其內容相當有把握嗎？不是應該保證它行得通嗎？我們曾經用這本書提到的需求要件作業技巧，協助客戶開發多種產品──電腦軟體、電腦硬體、汽車、家具、大樓、新的消費性產品、書籍、影片、組織架構、訓練課程，以及研究計畫。迄目前為止，還沒有客戶要求退費，但我們無法保證將來會不會有客戶要求退費，因為我們不知道如何使產品的開發程序，成為一門精確的技術。

　　許多客戶在與我們合作之前，都希望產品開發程序是一門精確的技術。這些客戶大都是電腦軟體業者──他們一直抱有不切實際的幻想，以為產品開發是一門精確的技術。所以我們引用馮紐曼的名言，以提醒業者注意：「如果你不了解自己所說的事物，即便你遣詞用字精確，也毫無意義。」

　　如果人們不知道自己的想望，沒有一種開發方法──不論這方法如何精確，如何聰明，如何有效率──可以滿足他們。這就是為什麼我們必須進行需求要件作業──這樣，我們才不至於設計出人們不想要的系統。

　　有效性永遠優先於效率。即便你相當重視效率，希望達成高效率的開發，你也要先剔除那些沒有人想要的產品的開發案。我們也可以換個方式表達：

　　不值得做的事，就不值得把它做好。

　　這句話引出「發掘」（discover）這個最重要的詞彙。本書的目的，即是協助讀者發掘真正值得做的事。

　　艾森豪（Dwight Eisenhower）曾說：「計畫書不重要；訂定計畫的過程才重要。」我們同意他的看法，並延伸這句話的意義至探索需求要件的程序上：

　　產品不重要，重要的是過程。

　　或是換一個方式表達：

　　發現什麼不重要，重要的是發現（探索）的過程。

　　這句話也適當詮釋了本書的書名Exploring Requirements。 　　譬如，資料字典（data dictionary）是保存資料定義的方法之一。這部字典是運用本書所提到的一些方法，千辛萬苦編製而成。事實上，幾乎沒有人讀過資料字典，或沒有任何人曾在探索需求的階段運用資料字典。或許有人憂心這個現象，但我們不憂心，因為我們相信：

　　文件不重要，重要的是建立文件這件事。

　　如果你觀察工程師們開發新系統的真實狀況，你將發現，探索需求的工作事實上就是建立一個團隊，而且成員們：

　　1.了解需求要件

　　2.（大多數都）貫徹始終參與專案

　　3.知道如何使團隊有效運作

　　我們相信，如果其中一個條件不符合，專案就很可能失敗。當然，導致專案失敗的原因還有很多，坊間也有許多書討論如何避開地雷。本書的重點在於，進行探索需求要件的程序時，下列三項很重要但被忽略的關於人的因素：

　　1.使所有團隊成員對於需求要件的了解一致

　　2.使成員希望以團隊的方式進行專案

　　3.使成員具備必要的技巧和工具，以團隊作業方式，有效地界定出需求要件

　　許多討論系統開發的書籍和文章，大都忽略這些主題，因此這本書可以用來補強你目前使用的探索需求要件程序，不論是正式或非正式的。本書大多數篇章都是獨立的，每章討論一項或數項工具或方法，可以強化你的需求要件作業。你可以從頭到尾讀一遍，也可以只讀你最需要加強的篇章。不論你用哪一種方式，本書都可以讓你更了解自己所說的事物。