第338期：【需求分析】需求蔓延全方位剖析

概述：字数：1487。耗时：3.5分钟。适合人群：资深产品经理，UX，项目经理。本篇主要介绍了需求蔓延的7种原因。并且介绍了应对需求蔓延的9种办法。

产品研发过程，更适用于自研产品，每个版本的需求都是自己提的。

项目交付过程，更适用于“标准化产品”对客的“定制化交付”，需求是客户提的，我们要在有限的时间内完成这些需求内容。

01为什么会出现需求蔓延

1无法闭环业务：原来的方案有漏洞，而双方都没有及时察觉，在进行需求分析时发现了。

2花小钱办大事：甲方通过一些模棱两可的要求先把乙方招进来，在正式实施时再提出各种各样的特色化场景和诉求。

3拿标过度承诺：在售前阶段为了拿标，做出一些超纲的许诺为自己增加中标的可能性。

4偏好了解不够：不同的客户在管理政策、实施政策上的要求也是不一致的。

5双方认知偏差：在需求分析阶段发现，双方对于统一问题理解角度和思考方式不同。6配套调研不足：现在很少有完全独立的系统建设，平台的构建，都需要和多个关联方进行对接、交互。

7新政策分歧大：从提出需求，到走完售前流程可能已经过去了很久。此时市场上的新政策、新动态都可能会对原有的需求产生较大的冲击。

02怎样看待需求蔓延

首先，蔓延几乎不可避免，我们要做好充足的心理准备。需求蔓延也不全都是弊端，从产品成熟度的角度来看，面对不同的客户诉求，产生不同的应用场景，本身对产品的迭代发展也有补充。

03如何应对需求蔓延

1情绪上要先接纳：人都是感性的动物，当我们被情绪影响之后，会做出很多不可控的错误决定。而且也许原本在客观条件下能够解决的问题，带上情绪之后也就很难解决。

2打铁还需自身硬：通过自己的专业性快速获得对方的信任，在对方提出一些漫无边际的想法时，能够敏锐的觉察并适当引导，这些都是对我们极大的考验。

3先解决首要目标：关键性问题优先解决，非关键性问题是否可以往后安排；而且每个功能在实施时都有多种解决方案，对于非关键场景的蔓延需求，我们也可以采用相对简单的实现方式。

4协商需求的置换：蔓延的需求工作量为100人天，我们可以在原始合同中找一些80人天左右的非关键功能，进行置换。当然如果你可以置换出120人天的功能，那我愿奉你为最强。

5于客户沟通情感：非正式沟通时向客户诉苦，起码让客户从感情上认可我们多出来的工作量，最不济也能为后期的合作赚点感情加成。

6可借外力助内功：或者客户A始终坚持要这样做，我们是否可以通过客户A的领导、或者A的关联部门来配合，阐述其中的难点与风险等等，从而逐渐达成目标。

7做好沟通及同步：和领导同步，和项目组同步，和客户同步。定期、高频汇报因为蔓延将产生的风险，汇报我们的解决方案，汇报整体进度等等。

8避免费力不讨好：加班加点把超纲的范围做完了，但是由于进度、质量、或者完整性等问题，依然得不到客户的认可。或者当客户的不满传到公司、传到领导耳边，也很可能得不到内部的认可。

9争取攒个新需求：团队既有新的合同额，工期又能适当往后缓一缓。但前提是我们要对这些需求有充足的理解，别在实践的过程中被人问住了，届时尴尬的可不仅仅是自己。

04怎样尽量避免蔓延的产生

1售前阶段与客户的目标、过程，努力对齐

通过一次次的售前交流，尽量使得客户与我们对于产品/项目的场景、关键流程达成一致。

2售前到实施之间的交接要把握关键

针对交接所遇到的问题，制定了交接规范。在交接规范中提到了一定要将这些内容和实施团队的负责人、需求分析人员写清楚、讲清楚。

3让产品或方案更完善

一个成熟的产品或者成熟的方案，几乎把客户想到的问题都解决了，那也就不会存在需求蔓延的问题。

05产品研发过程的需求蔓延

我们的需求池是来自于各方角色，因此每个版本中的需求合理性，或冲突性，或完整性是不太好保障的。产品团队针对需求池的维护、筛选、以及每个迭代版本内容的完整性分析，都是至关重要的。

读后感：需求蔓延的情况在B端软件尤为突出，要么用户没有想好需求到底是啥？很容易把团队带入深坑，而且这个坑还避免不了，那么骆驼的选择索性跳下去。不入虎穴焉得虎子。

Powered by Froala Editor