讀《有效需求分析》

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

本書特點

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

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

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

我們常見的問題

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

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

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

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

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

什麼是需求

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

方案不是需求

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

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

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

• 為什麼會有這樣一個項目，是因為同行業都有？還是因為内部管理需要？
• 這個系統是哪些角色的人用？能解決他們什麼問題？
• 沒有這個系統的時候現在是怎麼來解決這些問題的？
• 使用者使用這功能的頻率是多少？這功能如果做砸了，對誰影響最大？

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

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

• 在某某功能子產品添加一種按鈕類型；
• 在某某地方需要多一種搜尋條件的配置。

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

是以每每收到這種“需求”時，會馬上跟項目的同僚反複确認客戶到底想要什麼，了解到真實背景後，才能結合産品的功能給出合适的解決方案。

幹系人

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

識别幹系人有幾個重要的判斷标準：

• 是否是關鍵部門複雜人？
• 是否對項目有一票否決權？
• 系統上線是否對大量的使用者産生負面影響？比如：工作模式改變等
• 識别出的人員是否與項目有直接關系？

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

• 同一類如果有多個幹系人，需要選出最有代表性的一個；
• 不同幹系人之間是否有利益沖突；
• 幹系人的專業背景、興趣愛好（友善日後溝通）；
• 不同的幹系人在各自角色上希望項目能解決什麼問題？
• 對項目的落地有什麼擔心？

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

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

非功能性需求

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

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

• 費控系統對計算的準确性要求高，接口需要做幂等處理等等；
• 客戶是集團性質的企業，而且系統是全員使用，并發量大，性能上有較高的要求；
• 一些合資企業，系統需要進行多語言支援，可能還會進行跨地域部署；
• 事業機關、政府機構對 UI 層面會有獨到的見解；
• 公檢法司的項目中會對安全性要求比較高，包括可能有些資料列需要加密。

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

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

• 客戶希望上線的時間節點？
• 如果功能較多，能不能進行分期傳遞？
• 客戶有沒有明确的技術上的要求，比如不能使用 Windows 部署，或者開發語言隻能使用 Java？
• 有沒有曆史系統需要做資料遷移？如果有需要達到什麼樣的目标，是整體切換還是需要雙系統并存一段時間進行逐漸替換？
• 是否需要和第三方系統進行對接？如果需要，需要知道第三方系統的接口人資訊以及接口規範。