這篇文章是軟件工程系列知識總結的第四篇，前面的幾篇文章聊了軟件工程的基礎理論和項目管理相關的知識。
這篇文章，我會將軟件工程中關於需求分析相關的知識進行總結梳理，並以自己理解的方式進行闡述。
需求分析在分析什麼
做技術的同學對於需求應該是既愛又恨，一方面軟件產品的源頭來自於需求，另一方面日常工作中面對需求的不明確和經常變更，只能無能狂怒。
日常的工作流中，需求分析和需求評審的結果往往決定了這個版本交付質量的好壞。
需求的來源有多種，有用戶建議、客訴工單，也有通過對市場調研和判斷，得出的一些結果需要進行驗證。
需求分析是一個過程，這個過程主要有如下三個步驟：
- 挖掘真實需求；
- 提出解決方案；
- 篩選驗證方案；
舉個例子：
用戶客訴：有用戶反饋某電商APP下單不方便，給了差評；
挖掘需求：用戶常用的支付方式是支付寶，但該APP暫不支持；
解決方案：應該支持多種支付渠道，比如支付寶、微信等支付渠道；
篩選驗證：調研活躍和潛在用戶使用佔比較多的支付渠道，按優先級去接入這些支付渠道；
產品需求的來源不是單一的，而是一系列的需求來解決用戶的痛點，不斷迭代不斷改進，從而做出更好的軟件產品。
完整的需求分析流程應該是一個閉環，整個過程需要迭代進行，如下圖：
收集需求：對需求進行收集整理（頭腦風暴、用戶調查、競品分析）；
分析需求：分析用戶需求，挖掘真實需求（表層是支付寶支付，深層是多支付渠道，底層是便捷的購物流程）；
需求評估：對需求進行評估，篩選掉不可行需求（成本、可行性、風險和收益、需求的緊急性和重要性優先級）；
需求設計：針對需求提出解決方案，變成產品設計方案（草圖、原型圖、MVP產品、演示Demo）；
驗證需求：驗證產品設計方案是否可行（產品驗收、灰度發佈、A/B測試）；
如何看待產品原型設計
日常工作中大家都會進行需求評審，這個時候最理想的情況是產品掏出原型圖和PRD告訴大家，這裏要什麼那裏是怎樣。
當然，有時候產品也會甩出一句話：“這個需求很簡單，怎麼實現我不管”。對於這種一句話需求，技術同學特別是研發和測試同學相信都很惱火。
不明確的需求和需求變更，是大家最不待見的情況，這些問題也會導致研發效率大大降低，進一步影響線上交付質量。
所以前期需求階段就確認好要做的事，後期大家的效率和交付質量往往都會比較好，這就有賴於做好產品原型設計。
原型設計簡單來說就是將抽象的需求具像化爲可視可見可理解的過程。
要做好原型設計，不單單是設計一個頁面，而是要綜合考慮很多因素。主要的考慮點有如下幾項：
- 頁面元素佈局；
- 功能交互邏輯；
- 用戶使用體驗；
產品原型設計的過程，可概括爲四個部分：
需求分析：挖掘真實用戶需求，評估原型設計方案；
原型設計：劃分原型功能模塊，梳理界面之間的交互邏輯；
流程梳理：畫產品使用流程圖，即通過流程圖將產品不同界面間的交互邏輯梳理清楚；
需求評審：大家比較熟悉的需求評審環節，就是集思廣益對產品原型和prd進行反饋調整；
技術同學培養產品意識
產品意識本質上是一種思維邏輯，即能否站在用戶和產品角度思考並解決問題。主要包含如下幾方面：
- 商業意識：即開發的軟件產品能否爲企業創造商業價值。技術本身是沒有直接價值的，技術的價值需要有一個依附物或者說承載品，這個物品就是軟件產品能創造的商業價值（我在和一些同學交流時也經常講到，技術本身不值錢，要依靠產品和業務的變現來體現技術的價值）。
- 用戶意識：即你研發的軟件產品是否滿足了用戶的真實需求，解決了用戶的底層痛點，產品使用的感受是否良好。簡單來說就是——在能用的基礎上是否好用。
- 數據意識：軟件產品最終要投入市場讓用戶使用，然後才能發現不足並且不斷迭代優化。無論是灰度發佈還是A/B測試，都需要收集數據來驗證產品。
技術同學要培養產品意識，可以從如下幾方面去實踐：
- 打破思維邊界：技術思維會關注技術實現和細節，產品思維關注用戶體驗、商業價值和爲什麼要某個功能；
- 改變原有習慣：日常工作和生活中，站在產品角度思考接觸到的物品，背後的價值、用戶體驗和使用場景等；
- 多實踐多覆盤：自己做個小產品或一個原型，找同事朋友試用獲取反饋，這樣輸出輸入來培養產品思維；
如何應對需求變更問題
需求變更在日常工作中特別常見，頻繁的需求變更會帶來很多問題，比如：
- 個人工作成就感降低；
- 需要經常加班趕工期；
- 軟件產品的交付質量下降；
- 架構臃腫代碼質量降低，很快會變成代碼“屎山”；
應對需求變更，常見的解決方案有如下幾種：
- 提升需求確定性，在需求分析和需求評審環節做好把控，減少源頭的不確定性；
- 增強需求管理手段，嚴格把控變更流程，讓需求變更流程更規範，提高變更成本；
- 通過快速迭代縮短版本週期，每版本僅交付部分需求，降低變更成本，快速響應變更；