需求蔓延是指产品需求范围已经规划好的情况下，后续发生了变化。

比如：A团队要做一款办公聊天软件，用于公司内部的日常业务沟通；按照产品设计的初衷，只要能聊天、发文档就OK了，但在多方要求下，产品逐渐增加了直播、朋友圈等非必要性功能，这就属于需求蔓延。

需求蔓延往往会让团队加班加点，疲于交付，更糟糕的是版本上线没几天，常用功能问题一堆，新增小功能没啥人用。

需求蔓延的原因

为什么会需求蔓延呢？

有人将需求蔓延的原因归于敏捷开发的“弱文档化”和“拥抱变化”，这点笔者并不赞同，因为需求蔓延在传统研发模式中也很常见。

为了解需求蔓延的根本原因，笔者和身边几个产品经理朋友讨论了一波，大概总结了如下几个原因：

• 上级领导或者甲方爸爸强势指派工作，产品经理压不住，只能硬着头皮把一些非必要性的需求放入管道，造成需求蔓延；

• 产品经理缺乏需求鉴别能力，在设计产品时遗漏了重要需求，导致开发阶段加入了很多必要性需求，同时夹带着非必要性需求，也就是需求蔓延；

• 产品经理只是按照用户的描述进行需求规划，没有更进一步挖掘用户的真实诉求，导致很多时候都在做无用功，这也属于需求蔓延。

如何避免需求蔓延？

识别产品的重要用户

破案片里常常有这么个场景：警察把案件相关人员的照片贴在墙上，随着墙上照片的增多，案件的中各方关系逐渐清晰，最后真相浮出水面。做产品也是一样的——提出产品需求的人来自多个部门，全面的识别出产品相关的重要用户，了解他们的需求和期望，可以避免需求在规划过程中出现的纰漏。

识别用户群体的方法可以先看是否有用户组织相关的料，通过资料去识别；或者通过影响地图、脑暴等方式去识别。然后通过权益利益方格，从用户群体中提炼出重要的、对产品交付有较大影响的用户，不同类型的用户管理策略可参考下图。

产品成功与否不是开发团队决定的，而是用户决定的。尽早的识别出产品的重要用户群体，并通过软技能与其搞好关系，双方合作一段时间后，对方通常会在某些需求或功能上做出一定妥协，从根本上减少需求蔓延，甚至还能提升产品经理/项目经理自身话语权，产品交付会更加顺利。反之，如果识别错了重要用户，则会事倍功半，需求蔓延基本上是板上钉钉的事情。

提前规划产品骨架，按优先级交付需求

敏捷开发中，除了识别清楚需求的来源，做好需求规划也是一个避免需求蔓延的方法。

敏捷开发不像瀑布开发——在设计阶段就将产品功能详细的罗列出来，敏捷开发为了应对变化，采用了迭代的方式进行需求规划，这使得很多人产生了误解——误以为敏捷没有一个需求全景规划。

敏捷使用迭代的方式进行需求规划，在初期会通过用户故事地图、MVP等方式对产品的主干功能进行规划，相当于构建了产品的骨架，在每个迭代基于当前要做的需求，进行细化拆分，比如下图（以华为云DevCloud “规划”功能为例），先通过思维导图的形式将产品的各项功能脉络梳理出来，每个模块具体细节功能在需要开发的时候进行拆分即可。

除了做好规划，排列需求优先级也有助于减少需求蔓延，团队要将精力集中在高优先级的需求交付，以保证做出的交付始终是有高价值的，至于低优先级需求，可以放缓交付节奏甚至移出需求管道。同样开发人员也应避免在低优先级的需求上过度交付，浪费资源。

频繁与用户交流，了解真实诉求

有时候一个人说出来的，和他真正想表达的，完全是两个意思，比如俩人见面寒暄一句“吃了么”，大家都知道这不是要请客吃饭，实际想表达的意思就是“你好”。现实生产中这种例子也很常见，用户提了很多很复杂的诉求，可能用户想要的并不是他提出来的，而是自己没想好到底要啥，或者没想好通过什么途径去实现自己的诉求，索性想到啥就提出啥，这时候用户说啥，开发团队就做啥，后期就容易引发需求蔓延。

产品经理/项目经理应该去加强与用户交流沟通的频率，同时探索用户的真实或最主要的诉求，来应对需求蔓延。

通过Scrum的评审会议，定期和用户对产品功能进行评审，也属于频繁与用户交流。评审会议上，通过演示产品，让用户去思考这到底是不是自己想要的，不是的话，我想要什么？是的话，接下来要做什么怎么做，同时产品经理也要对用户的反馈建议进行消化吸收，挖掘用户诉求，并定期找用户对接澄清，做到双方信息对称，避免被用户牵着鼻子走，最后需求蔓延。

总结

需求蔓延是一种很常见的现象，设计阶段把需求框架想明白，其他方面基本就是人和人之间的问题了，这就需要软技能去消灭Gap，减少需求蔓延。