最近在一個技術羣裏看到張逸大佬強力推薦一本關於需求分析的書《有效需求分析》，於是在 Kindle 上下單了，讀完後有一種相見恨晚的感覺。
本書特點
從書中的一些案例可以看出，作者擅長 ToB 軟件的需求分析，如果您是從事的 ToB 軟件的相關工作，那閱讀本書時會有更多的共鳴。
書中有大量的案例，閱讀起來不僅不枯燥，反倒覺得挺有意思，特別是一些日常生活中例子，能引發我們更多的思考。
每一個章節都有能落地的產物輸出，所有的產物整合在一起就是完整的需求文檔，可以讓你不僅知道一些理論，還知道怎麼落地。
我們常見的問題
1、辛辛苦苦開發的系統，跟客戶演示的時候達不到客戶的預期；
2、上線後，客戶反覆提出“變更”，從客戶視角來看是功能沒有按要求完成，從開發的視角感覺客戶在百般刁難；
3、邊界難以控制，已經按照“要求”完成了，客戶還不斷提出新的東西。
讀完這本書可以立即解決這些問題嗎？答案肯定是不能，但能給我們帶來啓發和思考，能讓我們在解決這些問題的路上往前邁進一步。
書中的內容不少，本文只是我結合自己的認知把覺得重要的點展開來說說。
什麼是需求
什麼是需求？書中給出了一個非常精煉的回答：現實和期望之間的差距。就是中間這個差距需要我們去思考、調研，這是一個迭代的過程，直到最後達到期望甚至超過期望，如果用了一些錯誤的方法，或者被客戶牽着鼻子走，最後結果可能還不如現實。
方案不是需求
開篇例舉的一個生活中的小例子充分說明了什麼是需求，什麼是方案：
晚上小孩吵着說要喫餅乾，最後給了點麪包，小孩喫完就乖乖睡着了，在這裏喫餅乾是方案，需求是小孩的肚子餓了，當沒有餅乾時，可以使用第二種方案，給他吃麪包也可以解決這個需求問題。
如果客戶的接口人稍微懂點技術，在做需求調研時就很容易提出方案級的需求，這時就需要警惕了，需要用一些問題來深挖背後的真是需求，比如：
- 爲什麼會有這樣一個項目，是因爲同行業都有？還是因爲內部管理需要？
- 這個系統是哪些角色的人用？能解決他們什麼問題？
- 沒有這個系統的時候現在是怎麼來解決這些問題的？
- 用戶使用這功能的頻率是多少？這功能如果做砸了，對誰影響最大？
如果能挖到真實的需求，就可以根據情況來制定最優方案了。如果我們“完美”地滿足了客戶提出的“方案級需求”，最終的結果未必能讓客戶滿意，客戶通常善於發現問題，提出問題，但給出的方案往往不能完美解決問題。
在公司的內部其實也存在着這種問題，比如項目團隊的同事在遇到產品滿足不了的功能時，需要給產品提需求，經常看到的需求描述是：
- 在某某功能模塊添加一種按鈕類型；
- 在某某地方需要多一種搜索條件的配置。
這些都是方案，而不是需求，項目的同事根據自己的理解和認知完成了從需求到方案的轉換，而這個方案很多時候並不是最優。
所以每每收到這種“需求”時，會馬上跟項目的同事反覆確認客戶到底想要什麼，瞭解到真實背景後，才能結合產品的功能給出合適的解決方案。
干係人
任何企業準備上一套系統有各種各樣的原因，可能是爲了提高生產效率、提高協同辦公效率，也可能是爲了做一些政績。所以針對不同的場景，我們首先需要找出這個系統的相關干係人。
識別干係人有幾個重要的判斷標準：
- 是否是關鍵部門複雜人？
- 是否對項目有一票否決權？
- 系統上線是否對大量的使用者產生負面影響？比如：工作模式改變等
- 識別出的人員是否與項目有直接關係？
如果能夠準確的識別關鍵關係人，還需要對關係人進行分析：
- 同一類如果有多個干係人，需要選出最有代表性的一個；
- 不同干係人之間是否有利益衝突；
- 干係人的專業背景、興趣愛好（方便日後溝通）；
- 不同的干係人在各自角色上希望項目能解決什麼問題？
- 對項目的落地有什麼擔心？
做項目不光是要做好事，關鍵還要能搞定人，能讓重點干係人感受到系統的價值，項目就容易成功。
我認爲項目的前期最核心的就是上面兩個步驟：挖出核心訴求和找出重點干係人。剩下的就是分解需求進行開發實現了。不同的團隊對需求分解和開發實現肯定都有適合自己的方式和方法，具體可以去閱讀本書，下面說說在項目需求調研過程中經常會忽略的非功能性需求。
非功能性需求
非功能性需求通常指，安全性、性能、擴展性、穩定性等等，這些非常重要，但也是最容易被我們忽視掉的。
非功能性需求針對不同的客戶或系統會有不同的側重點，比如：
- 費控系統對計算的準確性要求高，接口需要做冪等處理等等；
- 客戶是集團性質的企業，而且系統是全員使用，併發量大，性能上有較高的要求；
- 一些合資企業，系統需要進行多語言支持，可能還會進行跨地域部署；
- 事業單位、政府機構對 UI 層面會有獨到的見解；
- 公檢法司的項目中會對安全性要求比較高，包括可能有些數據列需要加密。
這些非功能性的需求在調研階段應該和功能性需求一起同步進行，根據客戶的特徵進行分析和識別，最終作爲開發交付的一個檢查項進行檢查。
上面列舉的都是和系統本身相關的一些要求，除此之外，還有很多的外在因素也是在前期調研時就應該考慮的，比如：
- 客戶希望上線的時間節點？
- 如果功能較多，能不能進行分期交付？
- 客戶有沒有明確的技術上的要求，比如不能使用 Windows 部署，或者開發語言只能使用 Java？
- 有沒有歷史系統需要做數據遷移？如果有需要達到什麼樣的目標，是整體切換還是需要雙系統並存一段時間進行逐步替換？
- 是否需要和第三方系統進行對接？如果需要，需要知道第三方系統的接口人信息以及接口規範。
現在各種各樣的書籍琳琅滿目，感興趣的書買了，就有機會去閱讀，這是我一直以來的一個觀點，做需求每個項目負責人都有自己的方法，但多讀書學習一些方法和技巧，沒準哪天就能用上了。再說了，多讀書，往上可以提升我們的格局和眼界，往下也能夯實和固化我們的能力。
希望本文對您有所幫助！
本篇文章由一文多發平臺ArtiPub自動發佈