需求蔓延时，如何应对处置产品研发和交付的各种难题？

三个月前我总结了一篇如何对待需求变更的文章，其中提到控制变更和控制蔓延有很多类似的方法，但两者又有实质性的区别，所以今天将以需求蔓延为切入点整理产品研发、交付过程中需要面对和解决的难题。

首先我们把产品研发过程、项目交付过程区分开，因为不同的项目性质，蔓延产生的原因和应对策略也不尽相同。

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

当然需求来源会很多，比如领导的指示、用户的反馈、市场的动态、竞品的追赶等等，每个版本迭代之前，产品团队会在这一大汪需求池中捞出一些优先级高的，作为本次迭代的核心内容。

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

而且在项目启动前期还要经历多阶段的售前交流、商务搓谈，最终项目中标后根据招标文件中的主体内容进行详细的需求拆解和解决方案产出。

当然有些迭代优化项目不会有前期这么复杂的过程，但本质是类似的。

虽然项目构成和合作关系不同，但我们在项目初期的需求分析阶段，势必要面对需求蔓延的问题。以下内容我会以项目交付过程的蔓延为主。

毕竟作为乙方在面对各种甲方项目时产生的蔓延场景更复杂，影响也更大。

01、为什么会出现需求蔓延

1、原有范围存在无法闭环的业务场景

这是最直接的原因，原来的方案有漏洞，而双方都没有及时察觉，在真正进行需求分析时发现了。为了解决这个业务问题，自然而然需要增加新的功能、新的规则

2、客户想花小钱办大事

这个问题我是切身遇到过，后来复盘时突然发现，当初从售前阶段开始，就被客户牵着鼻子给套路了。

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

如果你碰到了这类客户，那只能：自求多福~

3、为了拿标而做的过度承诺

这类原因也比较常见，毕竟在售前阶段为了拿标，做出一些超纲的许诺为自己增加中标的可能性。

中了才有解决的可能性，不中一切都是0。

4、对甲方的偏好或政策要求了解不够

不同的客户在管理政策、实施政策上的要求也是不一致的。

比如同样的产品在A客户实施需要50个人月，在B客户实施之前，功能范围是一致的，但是实施时发现B有一套全局的业务规范要求，而这些业务规范的适配，需要额外增加10人月的工作量，这种需求蔓延即不好拒绝，又无法为平台带来新的场景积累。

真的是“食之无味，却绝不能弃”

5、售前阶段双方对部分功能的认知偏差

我遇到过一个很实际的例子，在售前阶段我们对“数据迁移”功能的理解，甲乙双方是不一致的，但是没有人发现，大家都在按照自己的思路沟通。

结果中标后在需求分析阶段发现，我们理解的“数据迁移”只是自己平台内部的用户数据。而客户理解的是多个旧系统的数据迁移和业务承接，两者在工作量上相差十几个人月。

因此我们不得不面对这个极大的需求蔓延问题，最终通过团队几个月高强度加班才解决。

6、关联方的调研不足

现在很少有完全独立的系统建设，平台的构建，都需要和多个关联方进行对接、交互。而这也增加了需求的不可控性。

毕竟谁也不知道这些关联方是否可以满足我们的对接要求，甚至于对方是否愿意配合我们。如果关联方不满足我们的对接要求，则针对实际场景的改造就需要大家一起商讨一个新的解决方案，而且在此过程，还可能会引申出更多的不可控因素。

因此在正式实施开始之前，这些未知的因素都可能导致后续的需求蔓延。

7、新政策或新市场的对齐

每个项目交付都有一定的周期性，尤其是涉及到面对流程较复杂的甲方。从提出需求，到走完售前流程可能已经过去了很久。

此时市场上的新政策、新动态都可能会对原有的需求产生较大的冲击。

02、怎样看待需求蔓延

首先，蔓延几乎不可避免，我们要做好充足的心理准备。

我遇到过很多需求人员，或者项目经理，要么在对方刚提出就烦躁崩溃，要么在商讨解决方案和应对策略时聒噪不安。当然这也包括我自己~

需求蔓延控制不好所产生的后果不言而喻。

轻则增加交付工作量，造成团队高强度加班、项目延期，项目成本不可控；重则因为蔓延的改造导致方案不完善，交付质量难以保证，从而产生严重的生产事故，对团队、对公司、对客户都会产生难以挽回的影响。

蔓延的需求，也可以反哺到产品中。

需求蔓延也不全都是弊端，从产品成熟度的角度来看，面对不同的客户诉求，产生不同的应用场景，本身对产品的迭代发展也有补充。即便是无法归并到产品标准版的特色化需求，也能提高我们在这个领域的业务经验。

虽然说具体问题具体分析，但是也有一些共性的问题、互通的方法能够对蔓延产生一些合理的处置效果，让我们一起来看看吧。

03、如何应对需求蔓延

1、情绪上要先接纳

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

而后基于不同的原因，再采取不同的策略。

2、打铁还需自身硬

很多蔓延的产生，都是因为产品本身的不完善，业务上的不专业，或是甲方的“伪需求”没有及时辨别，或是在对客的引导上有欠缺，或是客户对你的信任度不足。

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

当我们无法在第一时间控制住需求的蔓延时，那就尽快收拾心情，看看如何快速应对吧。

3、先解决首要目标，再梳理次要目标

蔓延出来的功能也有优先级，关键性问题（比如政策影响，比如MVP闭环缺失，比如不做会造成严重的生产事故等等）优先解决，非关键性问题是否可以往后安排？

而且每个功能在实施时都有多种解决方案，对于非关键场景的蔓延需求，我们也可以采用相对简单的实现方式，当然这些要基于我们对业务、流程的熟练程度，才能分析出更优的解决方案

4、商讨需求置换的可能性

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

5、会哭的孩子有奶吃

非正式沟通时向客户诉苦（前提是有一定的信任关系），起码让客户从感情上认可我们多出来的工作量，最不济也能为后期的合作赚点感情加成。

找领导诉苦，当无法控制变更时，尽量争取更多的资源来配合按时交付。

假如你不说，那就抗着呗~

6、可以借力打力

比如靠自己已经搞不定了，那是否可以借助领导或其他部门的力量旁敲侧击？

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

不要陷入思维怪圈，“曲线救国”也是救呀。

7、做好信息的及时同步

和领导同步，和项目组同步，和客户同步。定期、高频汇报因为蔓延将产生的风险，汇报我们的解决方案，汇报整体进度等等。而且一定要

留痕！留痕！留痕！

8、避免费力不讨好

很多时候，我们加班加点把超纲的范围做完了，但是由于进度、质量、或者完整性等问题，依然得不到客户的认可。

或者当客户的不满传到公司、传到领导耳边，也很可能得不到内部的认可。这时我们也会自我怀疑，更会觉得付出不值得。

所以我们要有一定的预知能力，在做之前做好心理准备，同时提前和客户、公司保持及时的沟通和汇报。

就算最后接锅，几个人一起接，总比一个人接好一点。这虽然有“五十步笑百步”之嫌，但是类似的问题谁能保证不会发生在自己身上呢？

9、争取攒个新需求

和领导一起，配合商务同事，看看是否可以把一些工作量确实很大，或者确实和原始需求关联度不高的蔓延攒一个新的优化合同提上来。

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

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

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

通过一次次的售前交流，尽量使得客户与我们对于产品/项目的场景、关键流程达成一致，这样客户才能预先把自己的想法说出来，而不是等到需求分析阶段再恍然大悟，然后发现和自己想的不一样。

但是这一点很难，本身售前阶段面对不同类型的客户关系和客户性格，很难做到目标对齐。但是不能因为难就不去做，前期多做一点点，后期可能会规避一个很大的坑。

之前我遇到过在售前交流阶段，无意中捕捉到甲方科技人员的一段话，发现涉及到我们关联方的对接方案在这里不适用，所以针对此问题又做了两次深入探讨。

最终甲方不仅认可了我们的实施方案，还在招标范围和工作量评估中做了一定程度的让步，从而为这个项目的如期交付提前扫清了一个很大的障碍。

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

今年上半年，针对我们售前和实施两个阶段之间交接所遇到的问题，制定了交接规范。在交接规范中提到了一定要将这些内容和实施团队的负责人、需求分析人员写清楚、讲清楚。

我们不仅不要打无准备的仗，更要打知己知彼准备充足的仗。

• 比如曾经许诺过的功能是什么，为什么，可以怎么做；
• 比如售前所预知的需求蔓延风险可能有哪些；
• 甲方的交付管理要求有哪些
• 关联方配合意愿情况是否存在风险等等内容；

后续的文章中我会单独进行总结。

通过售前与实施之间规范的交接及信息同步，让交付团队在面对需求蔓延时有充足的准备。

3、让产品或方案更完善

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

当然了，这种情况太理想化了。

可是这却是我们产品人要为之奋斗的目标，如果我们都没有这样的信念和决心，那这个产品势必不会走的长远。

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

最后简单分析一下自研产品中的需求蔓延问题，其实很多方式方法和上面的内容有相通之处。

因为我们的需求池是来自于各方角色，因此每个版本中的需求合理性，或冲突性，或完整性是不太好保障的。

而且即便是自研产品，也要对客负责、对交付团队负责、对市场负责，版本发布的节点也不能总是改来改去。

所以产品团队针对需求池的维护、筛选、以及每个迭代版本内容的完整性分析，都是至关重要的。

如果很多问题都是在开发做的时候才发现了功能缺失，临时修改不仅要面临加班、发版延期的风险，还可能无法构建完整的解决方案，发布之后的未知问题会对后续工作产生长远影响。

而且这些问题，则需要产品团队、研发团队、销售团队、交付团队、运营团队等多方好好battle一波。在这个过程中，产品团队难免会成为大家集体PUA的对象。

毕竟，是我们在提需求的时候没有分析清楚哇

06、写在最后

一旦涉及到和人打交道，就充满了变数。有限的文字终究不能覆盖无限的场景。希望今天的总结能够为有幸看到的你带来一点点帮助。及时总结，适度复盘，在实践中不断尝试新的方法，才能探索出一条适合自己的前行之路。

昨天的经验不一定适用于今天的问题，今天的收获不一定能面对明天的变化。但我们要坚信，自己所面对的困难没有解决不了的。

ps：以上内容全部基于自身的经验和经历，观点是否适用还请各位认真辨别

作者：不想延期，公众号：不想延期

本文作者 @不想延期

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！