上次去選書來讀時，沒看到有興趣的新書，於是到處亂找，挑到了這本書。

仔細讀了之後，覺得這是意外的驚喜。

這本書值得讀一次以上，這是傻蛋的感想。

比較對象呢，可以和Ｐｅｏｐｌｅｗａｒｅ和人月神話比較看看吧，都可以算是和資訊軟體專案管理有關的，只是面向各自不同。

這本書是談需求的，傻蛋工作經驗也算蠻多了，看過大量不能算成功的專案，基本上，都是從需求這一環就掛點了，然後，各種掙扎無濟於事。

技術能力好，沒用，管理方法再細緻，沒用，需求不對，商業模式與整個運作的走向就不對，後面越是用力，通常只會帶來更多的麻煩與壓力。

實際上，最難的是做好需求分析工作，後面的步驟，都是有所根據的，相對來說就是具體的，可以有方法可以套用，可以設法做好。

反而一開始的需求，常常，就是老闆的一時興起，沒有想得很清楚，於是就開啟一個專案那樣，很容易就草率的決定了需求，然後接著就各種不順了。

需求分析真的很重要，以前沒看過這本書，真的可以說是，運氣不好喔。

話雖如此，這本書的翻譯，傻蛋覺得卡卡的。

特別是ｒｅｑｕｉｒｅｍｅｎｔ，需求，特別翻譯成需求要件，就是感覺不是很順。

用粗體來對這個需要強調的需求做加重應該比較合適吧，當然這是傻蛋自己的看法啦。

不過這本書如果不看翻譯版本，對英文不夠好的人來說應該壓力也蠻大的就是了。

這本書的風格是，稍微有點好笑的那種吧，不是那種特別正經的風格，這種書如果讀原文，那就累了。

傻蛋不滿意的就是需求要件，而這個需求要件整本書到處都是，所以就覺得差了點，其實已經算不錯了。

書裡面用來說明需求分析確認作業的幾個案例，都相當刻意與好笑，超級粉筆專案啊，電梯資訊系統啊，一種交通工具的設計，都很有特色，不會讓人打瞌睡。

能把觀念說得清楚，還讓整個風格活潑有趣，給原作者一個讚喔！

那來說說傻蛋從這本書的閱讀得到的一些心得吧。

語意曖昧是個很常見的問題，如果不把它當一回事，你的需求分析肯定一蹋糊塗。

如果你不想把需求搞清楚，那你很容易就會傾向於使用曖昧的語意。

然後，把真正困難的部分，用蟑螂必殺器那樣的概念，推給別人。

就是那個，咻，碰，蟑螂就被解決了，決定這件事的人，往往不是需要實現那個蟑螂必殺器的人，到底怎麼具體讓蟑螂被咻，碰的解決掉，是別人的事。

一個專案要成功，要能成立，如果關鍵難點是一個什麼的必殺器，然後提出專案的人不想去注意這些細節，只想找個好凹的人推過去，這樣的專案，大概率是要做死的吧。

關鍵問題需要被放大，需要被謹慎的分解，做腦力激盪，並充分的研究與討論，以找出確實可行的方案，這種情況下，是不允許曖昧的定義的。

好，這是傻蛋的吐嘈而已。

需求分析，重要的是讓眾人意見和致，大家能有共識，能朝相同的目標一起努力前進。

所以不要心存僥倖，總想要忽略糊弄最複雜困難的部分，而是要把問題攤開來看，務必讓大家都清楚關鍵的點是什麼，將如何實現。

這本說有很多那種，一步一步的檢查步驟，或許還稱不上必殺技，但也是相當的實用。

可以拿來設計ＳＯＰ，用來當檢查表的草案或標準流程的參考框架。

每一個章節的心得與建議，大多很適合拿來當自我檢查表喔。

隨便抓個例子，進行需求分析作業時，常犯的錯誤是我們給客戶需要的東西，而不是客戶想要的東西。

我們是如此的自以為是，客戶當然不會喜歡我們的解決方案，是吧？

當然，這本書主題很多，傻蛋現在也很懶，全部寫完搞不好比這本書還厚。

就寫傻蛋對這本書核心觀念的解讀吧。

減少需求曖昧，讓需求變具體，可以增加可控性。

但，需求分析的終極目標，並不是把所有模糊都消滅乾淨，讓專案可以用可控制如預期的方式進行到底而已。

需求分析作業的目標還是要創造價值，是要找出更多可能性，找到有價值的想法與機會，這一點至少和有效率的確實完成任務一樣重要，甚至，更重要。

如果整個專案能創造的價值不高，就算管理得再精緻，最多也就那樣而已。

如果為了更細緻的管理而扼殺可能的機會，反而是捨本逐末。

避免語意曖昧與逃避現實的心存僥倖，並不意謂只要做好這些可以有技巧的步驟與檢查表的細節都做好，專案就會創造最大的價值。

不要扼殺創意與可能性，這一點，很重要，最好的解決方案，常常不適最專業，最聰明的，而是看到燈下黑，啊哈何不那樣做就好，那樣不受控制的跑出來的。

有些行為則是比較值得警惕的。

需求應該公開透明的討論，而不應以偷渡的方式加進去。

成功偷渡，偷偷的添加了自己想要，又不想被別人挑戰的想法，當下可能有種我贏了得感覺，但被發現的時候，得到的往往是憤怒喔！

重點是符合客戶的期望，而不是自己的期望，畢竟沒有買單的客戶會想被當成笨蛋。

分析功能時，可分為顯著，隱藏，附帶三種類型，透過分類法，設法找到更多隱藏功能。

對於功能裡暗示解決方案的字詞，要設法轉化為問句，找出更多隱藏功能，而不是陳述解決方案的形式。

充分討論分析功能之後，再把需盡力達成的功能整理出來。

功能之後是分析特性。

功能的特性。

可以分類為必須，客戶想要，與設計者認為可忽略的三類。

配合特性，對功能的掌握會更具體。

功能與特性都確定下來後，要來決定限制。

限制越多越明確，越容易得到具體可執行作法。

沒有限制，很可能會導致無法實現的專案。

不過限制固然有益，但，限制會讓解決方案的解空間變小。

過度的限制，可能整個解決方案就是無解。

安全可行與擴大可能的解空間需要抓到平衡，絕對安全的設計往往沒多大價值。

另外，限制反而可以帶來設計的自由，限制搭配標準化，反而會更靈活。

喔喔，那，限制到底是什麼？

那個蠢方法老闆或客戶絕對不會接受，這就是具體的限制啦。

對產品的功能，特性，限制都有充分的掌握後，接著要釐清的是偏好。

產品專案的價值，在於滿足客戶的期望的程度，所以，需要掌握偏好。

可以設法對偏好做設計，讓偏好可量化，以方面製作成圖表，好讓解決方案的好壞，可以不用全憑直覺感覺那樣武斷的決定，以輔助需求決策的品質。

最後就是整理出期望表了。

這一套作業程序下來，對於需求分析如何滿足客戶的期望這件事，就有了一個框架做法可以當基礎了。

而實際上，大多數的情況，需求的解讀都是靠感覺，靠不知道怎麼評價的小聰明吧，反正最後成王敗寇，贏家放的屁都是香的。

最後對需求做決策時，決策可以分為三種，選擇，假設與強迫。

選擇是根據有效的需求分析，是綜合各種情況下主動做出的對整體最有利的選擇。

假設則是資訊不足或因為作業錯誤，只能草率的不肯定的定義。

強迫則是不可抗力的限制，不是從有效分析決策方法而來，而是由法律或其他不可抗力的因素而需要被迫接受。

假設更需要寫下來，因為假設意謂風險，設計者要保護自己，對於假設就更需要得到書面確認。

正式書面紀錄非常重要，而且不只是具體需求內容，還要記錄當初被列為假設或限制的理由。

因為隨著時空環境的變化，以前的限制，或許已不再是限制，反而成為機會，若沒有清楚記錄下來，莫名所以的限制，往往會繼續發揮限制的作用。

正式的需求文件一定要有客戶簽名背書，畢竟口頭上的需求共識沒有意義，因為都只是說說的而已，事情有變時，大家都可以不認帳。

好啦，這本書確實是很有方法的，傻蛋只是很草率隨便的摘要一下而已。

很多精華部分是被忽略的，有興趣的讀者可以自行發掘吧。

光是回顧並整理的過程，傻蛋都覺得有一些收穫的說。

把大辣辣的想法具體轉化為可行的產品方案，這個設計的工作，第一步的需求分析是很重要的步驟。

如果不擅長這個步驟的技巧，那麼，在發揮創造力的工作上，我們將不具有競爭力，只能在變化很小的領域裡面，做些代工或專案研發之類工作，能分到的市場的餅，那會十分有限的喔！