如何避免敏捷開發中的需求蔓延

需求蔓延是指產品需求范圍已經規劃好的情況下，后續發生了變化。

比如：A團隊要做一款辦公聊天軟件，用于公司內部的日常業務溝通；按照產品設計的初衷，只要能聊天、發文檔就OK了，但在多方要求下，產品逐漸增加了直播、朋友圈等非必要性功能，這就屬于需求蔓延。

需求蔓延往往會讓團隊加班加點，疲于交付，更糟糕的是版本上線沒幾天，常用功能問題一堆，新增小功能沒啥人用。

需求蔓延的原因

為什么會需求蔓延呢？

有人將需求蔓延的原因歸于敏捷開發的“弱文檔化”和“擁抱變化”，這點筆者并不贊同，因為需求蔓延在傳統研發模式中也很常見。

為了解需求蔓延的根本原因，筆者和身邊幾個產品經理朋友討論了一波，大概總結了如下幾個原因：

? 上級領導或者甲方爸爸強勢指派工作，產品經理壓不住，只能硬著頭皮把一些非必要性的需求放入管道，造成需求蔓延；

? 產品經理缺乏需求鑒別能力，在設計產品時遺漏了重要需求，導致開發階段加入了很多必要性需求，同時夾帶著非必要性需求，也就是需求蔓延；

? 產品經理只是按照用戶的描述進行需求規劃，沒有更進一步挖掘用戶的真實訴求，導致很多時候都在做無用功，這也屬于需求蔓延。

如何避免需求蔓延？

識別產品的重要用戶

破案片里常常有這么個場景：警察把案件相關人員的照片貼在墻上，隨著墻上照片的增多，案件的中各方關系逐漸清晰，最后真相浮出水面。做產品也是一樣的——提出產品需求的人來自多個部門，全面的識別出產品相關的重要用戶，了解他們的需求和期望，可以避免需求在規劃過程中出現的紕漏。

識別用戶群體的方法可以先看是否有用戶組織相關的料，通過資料去識別；或者通過影響地圖、腦暴等方式去識別。然后通過權益利益方格，從用戶群體中提煉出重要的、對產品交付有較大影響的用戶，不同類型的用戶管理策略可參考下圖。

產品成功與否不是開發團隊決定的，而是用戶決定的。盡早的識別出產品的重要用戶群體，并通過軟技能與其搞好關系，雙方合作一段時間后，對方通常會在某些需求或功能上做出一定妥協，從根本上減少需求蔓延，甚至還能提升產品經理/項目經理自身話語權，產品交付會更加順利。反之，如果識別錯了重要用戶，則會事倍功半，需求蔓延基本上是板上釘釘的事情。

提前規劃產品骨架，按優先級交付需求

敏捷開發中，除了識別清楚需求的來源，做好需求規劃也是一個避免需求蔓延的方法。

敏捷開發不像瀑布開發——在設計階段就將產品功能詳細的羅列出來，敏捷開發為了應對變化，采用了迭代的方式進行需求規劃，這使得很多人產生了誤解——誤以為敏捷沒有一個需求全景規劃。

敏捷使用迭代的方式進行需求規劃，在初期會通過用戶故事地圖、MVP等方式對產品的主干功能進行規劃，相當于構建了產品的骨架，在每個迭代基于當前要做的需求，進行細化拆分，比如下圖（以華為云DevCloud “規劃”功能為例），先通過思維導圖的形式將產品的各項功能脈絡梳理出來，每個模塊具體細節功能在需要開發的時候進行拆分即可。

除了做好規劃，排列需求優先級也有助于減少需求蔓延，團隊要將精力集中在高優先級的需求交付，以保證做出的交付始終是有高價值的，至于低優先級需求，可以放緩交付節奏甚至移出需求管道。同樣開發人員也應避免在低優先級的需求上過度交付，浪費資源。

頻繁與用戶交流，了解真實訴求

有時候一個人說出來的，和他真正想表達的，完全是兩個意思，比如倆人見面寒暄一句“吃了么”，大家都知道這不是要請客吃飯，實際想表達的意思就是“你好”。現實生產中這種例子也很常見，用戶提了很多很復雜的訴求，可能用戶想要的并不是他提出來的，而是自己沒想好到底要啥，或者沒想好通過什么途徑去實現自己的訴求，索性想到啥就提出啥，這時候用戶說啥，開發團隊就做啥，后期就容易引發需求蔓延。

產品經理/項目經理應該去加強與用戶交流溝通的頻率，同時探索用戶的真實或最主要的訴求，來應對需求蔓延。

通過Scrum的評審會議，定期和用戶對產品功能進行評審，也屬于頻繁與用戶交流。評審會議上，通過演示產品，讓用戶去思考這到底是不是自己想要的，不是的話，我想要什么？是的話，接下來要做什么怎么做，同時產品經理也要對用戶的反饋建議進行消化吸收，挖掘用戶訴求，并定期找用戶對接澄清，做到雙方信息對稱，避免被用戶牽著鼻子走，最后需求蔓延。

總結

需求蔓延是一種很常見的現象，設計階段把需求框架想明白，其他方面基本就是人和人之間的問題了，這就需要軟技能去消滅Gap，減少需求蔓延。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。