如何做到專案準時交付之需求管理
文章目錄
很多人可能都還不明白需求分析和需求管理之間的區別，通常我們說起來最多的都是需求溝通和需求分析，開會都是討論需求如何如何做，這其實是需求分析的過程如何如何，而與需求有關的其他活動提及的比較少。其實需求溝通和需求分析都只是需求管理過程中的兩個環節。
一個專案做了很久，人力投入越來越多，大家都像打了雞血一樣天天加班，但是感覺總是做不完，就像一個“無底洞”。想盡快完成這個專案的時候，總有新的需求要做。實際上，這裡涉及到一個需求管理的概念。專案中哪些該做，哪些應該先做，做到什麼程度，都是由需求管理的過程來決定的。
通常需求管理是對需求生命週期的管理，從需求的產生到需求的結束，過程可以劃分為以下幾個獨立的階段：
一、需求整理
與PO進行需求溝通，並對溝通的需求進行歸類整理，形成文件。這個過程需要對業務建立起一個概念模型，以便對其進行抽象描述。也會用到一些工具像markdown、思維導圖、原型設計的工具等。文件是一個梳理思路非常好的方式，在文件中把自己的想法書寫出來，配上流程圖、狀態圖、時序圖，即方便自己的積累又便於別人的理解。文件越詳盡、越清晰越好，最好的文件就是一個新人也能根據文件快速的理解方案並寫出程式碼。
二、需求初判
圍繞專案的業務核心，目的是找到實際要做的需求。需要在溝通需求時，對需求的實現方案、所耗成本和資源、預期效果、是否有實現同樣目標的低成本替代方案等，有一定的判斷力，即需求方案初判。
三、需求定義
根據需求溝通和需求分析的結果，進一步定義準確無誤的專案需求。需求定義的過程更多的是對需求進行準確的描述，從需求方的角度、功能操作流程的角度等方面，對分析出來的真實需求做出完整、無二義性的定義，準確理解PO意圖，澄清不明確點，讓其他相關人員能準確的理解需求。
四、需求分析
需求分析主要是明確需求執行的優先順序。在通過上述兩個過程後，會擋掉一些不合理或可以採取更輕的解決方案的需求，對於留下來的需求，需要記錄進需求池。在記錄進需求池的時候，需要對需求的優先順序進行排序標註，有兩種常見的排序方法。一種是基於四象限法則，另一種則是基於KANO模型。
- 在判斷需求是否重要時，可以參考如下：
- 先做，會造成問題和負面影響
- 後做，會產生正向的效應和影響
- 在判斷需求是否緊急，可以參考如下：
- 後做，錯誤會持續發生並造成嚴重影響
- 後做，短期內可控但長期會有糟糕的影響
- 先做，立刻能解決很多問題、產生正面的影響
- 先做，在一段時間後可以有良好的效果
五、需求評審
需求評審是各方對需求進行確認的重要環節。各方對需求進行確認的過程，達成統一認知和共識，使需求能夠推進實現落地。在需求評審的過程中，一定要說明清楚需求的背景、價值、意義，而不是純粹的需求講解，這樣有助於各方對需求的理解。
需求評審的重要性體現如下：
- 評審過程本身也是一個知識傳遞過程，產品經理、SM與評審人員一起討論使用者需求，這有助於評審人員獲得使用者需求的前期認識。
- 評審過程中可能發現不明確的或者遺漏的需求，這需要SM和產品經理進行二次需求分析和定義。
- 在確認了To-do List需求後，SM需要綜合該產品線的全域性需求優先順序情況，對該需求進行版本排期，並根據版本排期推算大致的可上線時間範圍。
- 評審過程中可能發現某些特殊需求，這時產品經理、SM和評審人員可以群策群力共同思考解決問題的方式。
- 當局者迷、旁觀者清。再有經驗的產品經理也可能犯錯，評審人員可以提出更合理或者更有建設性的想法供產品經理參考。
六、需求排期
需求評審完成之後，進入到設計開發階段。需求排期需要SM制定出需求實現的生產要素UI設計、前端開發、後端開發、測試各需要的時間以及並行分工的情況。
七、需求跟蹤
需求跟蹤是產品經理日常必須完成的工作。跟進需求的設計實現過程，保證需求的實現不打折扣，並隨時關注需求的變化。通過比較需求定義與後續工作成果之間的對應關係，建立與維護需求跟蹤列表，確保產品依據需求的定義進行開發。
- 正向跟蹤：檢查已安排的每個需求是否都能在後續的實現過程中有相對應的部分，確保沒有漏做的需求，並保證需求的實現程度和需求定義要求的一樣。這就需要每天都與後續的各個負責實現的人員進行確認。
- 逆向跟蹤：根據已有的互動設計稿、系統設計文件、測試用例文件等成果文件，反向檢查是否包含了所有已安排的需求。
八、需求變更
需求變更最考驗產品經理需求把控能力。當因為外部環境變化或者內部需求定義錯誤導致需求需要更改時，要做好變更的管控，防止因為變更而導致需求執行的過程無法進行下去。
總之，需求管理是一項十分重要的工作，在眾多失敗的專案中，專案的失敗主要是需求管理失敗導致的。因此，需求管理對產品能否最終實現產生至關重要的影響。