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