最近在一個技術群里看到張逸大佬強力推薦一本關于需求分析的書《有效需求分析》，于是在 Kindle 上下單了，讀完后有一種相見恨晚的感覺。

本書特點

從書中的一些案例可以看出，作者擅長 ToB 軟件的需求分析，如果您是從事的 ToB 軟件的相關工作，那閱讀本書時會有更多的共鳴。

書中有大量的案例，閱讀起來不僅不枯燥，反倒覺得挺有意思，特別是一些日常生活中例子，能引發我們更多的思考。

每一個章節都有能落地的產物輸出，所有的產物整合在一起就是完整的需求文檔，可以讓你不僅知道一些理論，還知道怎么落地。

我們常見的問題

1、辛辛苦苦開發的系統，跟客戶演示的時候達不到客戶的預期；

2、上線后，客戶反復提出“變更”，從客戶視角來看是功能沒有按要求完成，從開發的視角感覺客戶在百般刁難；

3、邊界難以控制，已經按照“要求”完成了，客戶還不斷提出新的東西。

讀完這本書可以立即解決這些問題嗎？答案肯定是不能，但能給我們帶來啟發和思考，能讓我們在解決這些問題的路上往前邁進一步。

書中的內容不少，本文只是我結合自己的認知把覺得重要的點展開來說說。

什么是需求

什么是需求？書中給出了一個非常精煉的回答：現實和期望之間的差距。就是中間這個差距需要我們去思考、調研，這是一個迭代的過程，直到最后達到期望甚至超過期望，如果用了一些錯誤的方法，或者被客戶牽著鼻子走，最后結果可能還不如現實。

方案不是需求

開篇例舉的一個生活中的小例子充分說明了什么是需求，什么是方案：

晚上小孩吵著說要吃餅干，最后給了點面包，小孩吃完就乖乖睡著了，在這里吃餅干是方案，需求是小孩的肚子餓了，當沒有餅干時，可以使用第二種方案，給他吃面包也可以解決這個需求問題。

如果客戶的接口人稍微懂點技術，在做需求調研時就很容易提出方案級的需求，這時就需要警惕了，需要用一些問題來深挖背后的真實需求，比如：

• 為什么會有這樣一個項目，是因為同行業都有？還是因為內部管理需要？

• 這個系統是哪些角色的人用？能解決他們什么問題？

• 沒有這個系統的時候現在是怎么來解決這些問題的？

• 用戶使用這功能的頻率是多少？這功能如果做砸了，對誰影響最大？

如果能挖到真實的需求，就可以根據情況來制定最優方案了。如果我們“完美”地滿足了客戶提出的“方案級需求”，最終的結果未必能讓客戶滿意，客戶通常善于發現問題，提出問題，但給出的方案往往不能完美解決問題。

在公司的內部其實也存在著這種問題，比如項目團隊的同事在遇到產品滿足不了的功能時，需要給產品提需求，經常看到的需求描述是：

• 在某某功能模塊添加一種按鈕類型；

• 在某某地方需要多一種搜索條件的配置。

這些都是方案，而不是需求，項目的同事根據自己的理解和認知完成了從需求到方案的轉換，而這個方案很多時候并不是最優。

所以每每收到這種“需求”時，會馬上跟項目的同事反復確認客戶到底想要什么，了解到真實背景后，才能結合產品的功能給出合適的解決方案。

干系人

任何企業準備上一套系統有各種各樣的原因，可能是為了提高生產效率、提高協同辦公效率，也可能是為了做一些政績。所以針對不同的場景，我們首先需要找出這個系統的相關干系人。

識別干系人有幾個重要的判斷標準：

• 是否是關鍵部門復雜人？

• 是否對項目有一票否決權？

• 系統上線是否對大量的使用者產生負面影響？比如：工作模式改變等

• 識別出的人員是否與項目有直接關系？

如果能夠準確的識別關鍵關系人，還需要對關系人進行分析：

• 同一類如果有多個干系人，需要選出最有代表性的一個；

• 不同干系人之間是否有利益沖突；

• 干系人的專業背景、興趣愛好（方便日后溝通）；

• 不同的干系人在各自角色上希望項目能解決什么問題？

• 對項目的落地有什么擔心？

做項目不光是要做好事，關鍵還要能搞定人，能讓重點干系人感受到系統的價值，項目就容易成功。

我認為項目的前期最核心的就是上面兩個步驟：挖出核心訴求和找出重點干系人。剩下的就是分解需求進行開發實現了。不同的團隊對需求分解和開發實現肯定都有適合自己的方式和方法，具體可以去閱讀本書，下面說說在項目需求調研過程中經常會忽略的非功能性需求。

非功能性需求

非功能性需求通常指，安全性、性能、擴展性、穩定性等等，這些非常重要，但也是最容易被我們忽視掉的。

非功能性需求針對不同的客戶或系統會有不同的側重點，比如：

• 費控系統對計算的準確性要求高，接口需要做冪等處理等等；

• 客戶是集團性質的企業，而且系統是全員使用，并發量大，性能上有較高的要求；

• 一些合資企業，系統需要進行多語言支持，可能還會進行跨地域部署；

• 事業單位、政府機構對 UI 層面會有獨到的見解；

• 公檢法司的項目中會對安全性要求比較高，包括可能有些數據列需要加密。

這些非功能性的需求在調研階段應該和功能性需求一起同步進行，根據客戶的特征進行分析和識別，最終作為開發交付的一個檢查項進行檢查。

上面列舉的都是和系統本身相關的一些要求，除此之外，還有很多的外在因素也是在前期調研時就應該考慮的，比如：

• 客戶希望上線的時間節點？

• 如果功能較多，能不能進行分期交付？

• 客戶有沒有明確的技術上的要求，比如不能使用 Windows 部署，或者開發語言只能使用 Java？

• 有沒有歷史系統需要做數據遷移？如果有需要達到什么樣的目標，是整體切換還是需要雙系統并存一段時間進行逐步替換？

• 是否需要和第三方系統進行對接？如果需要，需要知道第三方系統的接口人信息以及接口規范。

現在各種各樣的書籍琳瑯滿目，感興趣的書買了，就有機會去閱讀，這是我一直以來的一個觀點，做需求每個項目負責人都有自己的方法，但多讀書學習一些方法和技巧，沒準哪天就能用上了。再說了，多讀書，往上可以提升我們的格局和眼界，往下也能夯實和固化我們的能力。

希望本文對您有所幫助！

總結

以上是生活随笔為你收集整理的读《有效需求分析》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。