需求蔓延，常見但不正常，教你如何破
摘要：需求蔓延是一種很常見的現象，設計階段把需求框架想明白，其他方面基本就是人和人之間的問題了，這就需要軟技能去消滅Gap，減少需求蔓延。
本文分享自華為雲社群《如何避免敏捷開發中的需求蔓延》，作者：敏捷的小智。
需求蔓延是指產品需求範圍已經規劃好的情況下，後續發生了變化。
比如：A團隊要做一款辦公聊天軟體，用於公司內部的日常業務溝通；按照產品設計的初衷，只要能聊天、發文檔就OK了，但在多方要求下，產品逐漸增加了直播、朋友圈等非必要性功能，這就屬於需求蔓延。
需求蔓延往往會讓團隊加班加點，疲於交付，更糟糕的是版本上線沒幾天，常用功能問題一堆，新增小功能沒啥人用。
需求蔓延的原因
為什麼會需求蔓延呢？
有人將需求蔓延的原因歸於敏捷開發的“弱文件化”和“擁抱變化”，這點筆者並不贊同，因為需求蔓延在傳統研發模式中也很常見。
為了解需求蔓延的根本原因，筆者和身邊幾個產品經理朋友討論了一波，大概總結了如下幾個原因：
• 上級領導或者甲方爸爸強勢指派工作，產品經理壓不住，只能硬著頭皮把一些非必要性的需求放入管道，造成需求蔓延；
• 產品經理缺乏需求鑑別能力，在設計產品時遺漏了重要需求，導致開發階段加入了很多必要性需求，同時夾帶著非必要性需求，也就是需求蔓延；
• 產品經理只是按照使用者的描述進行需求規劃，沒有更進一步挖掘使用者的真實訴求，導致很多時候都在做無用功，這也屬於需求蔓延。
如何避免需求蔓延？
識別產品的重要使用者
破案片裡常常有這麼個場景：警察把案件相關人員的照片貼在牆上，隨著牆上照片的增多，案件的中各方關係逐漸清晰，最後真相浮出水面。做產品也是一樣的——提出產品需求的人來自多個部門，全面的識別出產品相關的重要使用者，瞭解他們的需求和期望，可以避免需求在規劃過程中出現的紕漏。
識別使用者群體的方法可以先看是否有使用者組織相關的料，通過資料去識別；或者通過影響地圖、腦暴等方式去識別。然後通過權益利益方格，從使用者群體中提煉出重要的、對產品交付有較大影響的使用者，不同型別的使用者管理策略可參考下圖。
產品成功與否不是開發團隊決定的，而是使用者決定的。儘早的識別出產品的重要使用者群體，並通過軟技能與其搞好關係，雙方合作一段時間後，對方通常會在某些需求或功能上做出一定妥協，從根本上減少需求蔓延，甚至還能提升產品經理/專案經理自身話語權，產品交付會更加順利。反之，如果識別錯了重要使用者，則會事倍功半，需求蔓延基本上是板上釘釘的事情。
提前規劃產品骨架，按優先順序交付需求
敏捷開發中，除了識別清楚需求的來源，做好需求規劃也是一個避免需求蔓延的方法。
敏捷開發不像瀑布開發——在設計階段就將產品功能詳細的羅列出來，敏捷開發為了應對變化，採用了迭代的方式進行需求規劃，這使得很多人產生了誤解——誤以為敏捷沒有一個需求全景規劃。
敏捷使用迭代的方式進行需求規劃，在初期會通過使用者故事地圖、MVP等方式對產品的主幹功能進行規劃，相當於構建了產品的骨架，在每個迭代基於當前要做的需求，進行細化拆分，比如下圖（以華為雲DevCloud“規劃”功能為例），先通過思維導圖的形式將產品的各項功能脈絡梳理出來，每個模組具體細節功能在需要開發的時候進行拆分即可。
除了做好規劃，排列需求優先順序也有助於減少需求蔓延，團隊要將精力集中在高優先順序的需求交付，以保證做出的交付始終是有高價值的，至於低優先順序需求，可以放緩交付節奏甚至移出需求管道。同樣開發人員也應避免在低優先順序的需求上過度交付，浪費資源。
頻繁與使用者交流，瞭解真實訴求
有時候一個人說出來的，和他真正想表達的，完全是兩個意思，比如倆人見面寒暄一句“吃了麼”，大家都知道這不是要請客吃飯，實際想表達的意思就是“你好”。現實生產中這種例子也很常見，使用者提了很多很複雜的訴求，可能使用者想要的並不是他提出來的，而是自己沒想好到底要啥，或者沒想好通過什麼途徑去實現自己的訴求，索性想到啥就提出啥，這時候使用者說啥，開發團隊就做啥，後期就容易引發需求蔓延。
產品經理/專案經理應該去加強與使用者交流溝通的頻率，同時探索使用者的真實或最主要的訴求，來應對需求蔓延。
通過Scrum的評審會議，定期和使用者對產品功能進行評審，也屬於頻繁與使用者交流。評審會議上，通過演示產品，讓使用者去思考這到底是不是自己想要的，不是的話，我想要什麼？是的話，接下來要做什麼怎麼做，同時產品經理也要對使用者的反饋建議進行消化吸收，挖掘使用者訴求，並定期找使用者對接澄清，做到雙方資訊對稱，避免被使用者牽著鼻子走，最後需求蔓延。
總結
需求蔓延是一種很常見的現象，設計階段把需求框架想明白，其他方面基本就是人和人之間的問題了，這就需要軟技能去消滅Gap，減少需求蔓延。