如何应对需求变更？

有个广为流传的段子，说的是一个发生在餐厅的惨案。

大爷 = 客户

服务员 = 小白产品经理

大厨 = 软件开发人员

【餐厅】

一个大爷来到悦客饭店，坐下来。

“服务员，给我来份宫保鸡丁！”

“好嘞！”

——这叫原始需求

（思考：如果你是产品经理，拿到这个原始需求会怎么做？）

【餐厅】

大厨做到一半。

“服务员，菜里不要放肉。”

“不放肉怎么做啊？”

“不放肉就行了，其它按正常程序做，不就行了，很难吗？”

“好的，您稍等”

——中途需求变更

（思考：如果你是产品经理，接到这个需求变更应该怎么做？）

【厨房】

大厨：“你大爷，我肉都回锅了”

服务员：“顾客非要要求的嘛，你把肉挑出来不就行了吗”

大厨：“行你大爷！”

然而还是一点点挑出来了

——需求改动太大，部分重构

【餐厅】

“服务员，菜里能给我加点腐竹吗？”

“行，这个应该简单。”

——低估改动成本

【厨房】

大厨：“你不知道腐竹得提前泡水？炒到一半才说？跟他说，想吃腐竹就多等半天”

服务员：“啊，你怎么不早说？”

大厨：“我怎么知道他要往宫保鸡丁里放腐竹？！”

然而还是去泡腐竹了

——新需求引入了新研发成本

【餐厅】

“服务员，还是把肉加回去吧”

“您不是刚说不要肉吗”

“现在又想要了”

“...好的，您稍等”

——某一功能点摇摆不定

【厨房】

大厨：“真想揍你！菜都炒过火了你让我放肉？还好肉我没扔”

服务员：“客户提的要求你揍我干嘛？”

大厨：“你就不能拒绝他啊？啊？”

服务员：“人家是客户嘛。”

——甲方是大爷

【餐厅】

“服务员！服务员！”

“来了来了，你好？”

“怎么这么半天啊？”

“稍等我给您催催啊”

——改动开始导致工期延误

【厨房】

大厨：“催什么催！腐竹没泡好，我还得重新放油，他要想吃老的也行，没法保质保量”

——开发人员要求重新排期

【餐厅】

服务员：“抱歉，加腐竹的话得多等半天，您别着急哈”

“我靠要等那么久？我现在就要吃，你们能快点吗？”

“行...您稍等”

——甲方催活

【厨房】

大厨：“我晕，中途改需求又想按期交付，逗我玩呢？”

服务员：“那我问问，要不让他们换个菜？”

大厨：“再换我就死了”

——开发人员开始和产品经理PK

【餐厅】

“服务员，这样吧，腐竹不要了，换成蒜苗能快点吗？对了，顺便加点番茄酱”

——因工期过长再次改动需求

【厨房】

大厨：“你不知道蒜苗也得焯水啊？！还有你让我怎么往热菜里放番茄酱啊？？”

服务员：“焯水也比等腐竹强吧，番茄酱往里一倒不就行了吗？很难吗？”

大厨：“腐竹我还得接着泡，万一这孙子一会又想要了呢。”

——频繁改动开始导致大量冗余

【餐厅】

“服务员，菜里加茄丁了没有？我去其它饭店吃可都是有茄丁的”

“好好好，您稍等，您稍等”

——奇葩需求

【厨房】

大厨：宫保鸡丁里放茄丁？？”

服务员：“茄丁炒好了扔里边不就行了吗？”

大厨：“那还能叫菜吗？哪个菜系的？”

服务员：“客户要，你就给炒了吧。”

大厨：“你顺道问问他腐竹还要不要，我这盆腐竹还占着地方呢不要我就扔了”

——奇葩你也得做

【餐厅】

“服务员，还要多久能好啊”

“很快，很快...”

“再给我来杯西瓜汁。”

“...好”

“我再等10分钟，还不好我就走了，反正还没给钱。”

“很快，很快...”

——黑暗前的最后黎明

10分钟后...

“咦，我上次吃的不是这个味啊？”

终于，大厨发疯似的拿着炒勺从厨房杀出来......

10分钟后...

"喂，120吗？悦客饭店有人受重伤...”

......

这个段子里，你可能会觉得这客户好奇葩，提的需求不合理，还总是改来改去，是客户的问题。

其实，这个服务员也存在很多问题。

如果把这个服务员看做产品经理的话，他不是一个合格的产品经理。

作为一名产品经理，要能够分析客户需求并给出合理的产品解决方案。

所以产品经理一方面要熟悉客户业务（这样才能正确的理解客户需求），另一方面要熟悉自家产品能力（这样才能给出正确的解决方案）。

而这个服务员他只是一个传话筒。由于他不了解客户业务，所以其对客户需求的理解仅仅停留在客户的口头表达上。由于不了解产品能力，也无法给出针对性的解决方案。

如果这个服务员（产品经理）会分析需求，能正确应对需求变更，就是另一个版本的故事了。

【另一个版本的故事】

一个大爷来到悦客饭店，坐下来。

“服务员，给我来份宫保鸡丁！”

“好嘞！您有什么忌口吗？” （进一步收集需求、还原需求）

“有，菜里不要放肉。”

“这宫保鸡丁不放肉可是不好做呀！能冒昧的问您一句，为什么不放肉么？” （探索需求，多问为什么）

“我身体不太好，血脂有点高，医生不让我吃肉。但我就爱吃宫保鸡丁的味道，所以请你们给我炒一道没有肉的宫保鸡丁”（获知客户的真实意图）

“哦，我明白了。那我推荐您尝试一下我们这里的宫保茄丁。这道菜保留了宫保的烹调方式，用茄丁替代了鸡丁做主料，无论是味道还是口感都和宫保鸡丁有九分相像。但作为一道纯素菜，茄子在低脂的同时，还能起到降低胆固醇的作用。价格上也比宫保鸡丁更实惠，您看您要不要试试看？” （能够根据对产品能力的理解，推荐更合理的解决方案）

“太好了！就给我来一个这个吧！”

做产品的人离不开三件事：生、死、需求变更。

产品人员都很讨厌需求变更。需求变更往往意味着麻烦，会引起计划调整、预算超支、加班、团队关系紧张......

频繁的需求变更甚至会导致项目的失败。

那我们能消除需求变更吗？

很遗憾的是，不能。

1、为什么无法消除需求变更？

通过对需求变更进行分类统计、原因分析，需求变更的原因可以分为两类：

a）内因

• 需求相关问题：需求收集不完整、需求遗漏、需求沟通失真等

• 解决方案不符合要求：客户提的需求是用解决方案描述的伪需求，产品经理没有进行需求挖掘，按照客户描述的解决方案做出来的产品没有解决客户的问题，最终导致需求变更。

b）外因

• 业务调整：公司战略转型、产品定位改变导致需求变更

• 外部环境的变化：市场变化、用户反馈、政策调整、行业监管导致的需求变更

针对内因，我们可以通过提高需求分析的技能来减少需求变更，但团队成员的能力往往参差不齐，无法根本杜绝。

针对外因，即使我们可以加强对变化的预测，但谁也无法准确预测未来，所以无法消除外因带来的需求变更。

所以，需求变更管理的目标是控制变更、减少变更带来的负面影响，而非消除变更。

既然需求变更无法避免，那我们改如何应对需求变更呢？

2、如何应对需求变更？

需求变更是IT行业的典型问题，业界内已经有了一些最佳实践，接下来分享几点最佳实践：

• 需求变更流程

• 变更管理工具

• 应对需求变更的策略

2.1 需求变更流程

在产品开发的过程中，需求的变更请求有多种需求来源，如图所示。

如果来自多种来源的需求变更都是直接找对应的开发人员直接处理，会带来混乱。

我们来看一个工作场景。

在项目例会上，项目经理老张问开发小王：“你那个联系人管理模块做得怎样了？什么时候能够提交？”

“联系人管理模块不能按计划完成，估计还需要多2星期时间。因为客户找我加了一个批量导入联系人的功能，我已经开始做了，做的过程中发现没我想象的那么简单”。

“我怎么都不知道这个事情？他直接找你加功能？”

“是啊。我觉得这个联系人管理模块是该有个批量导入联系人的功能，而且感觉也不难，我就同意了。“

“要让客户走需求变更流程啊！”

“客户嫌走流程麻烦，就直接找我了。”

“需求变更不是你一个人的事情，我们要评估对其他模块有没有影响、要安排测试人员测试、得调整项目计划，如果项目上线时间受影响的话还要跟客户、跟大老板沟通！”

“那以后有客户直接找我提需求的话，我让客户走需求变更流程，或者我来帮他提交需求变更申请。”

很多看似简单的需求变更实际上很复杂，带来的影响也是多方面的，需求变更如果是靠走后门，而不是走流程来管理，会给项目带来混乱，会导致项目质量出问题、项目计划被打乱。

需求变更要进行管理。所有需求变更必须走需求变更流程，要经过统一的入口，进行影响评估，经过变更控制委员会CCB审批后才能进行变更。

需求变更流程参考如下：

需求变更流程中有两个关键：变更控制委员会CCB、变更影响分析。

a）变更控制委员会CCB

CCB是负责需求变更管理的团队，主要职责是对需求变更进行变更影响分析，批准变更或驳回变更。

CCB是一个由多个不同角色组成的虚拟组织，常见的角色包括：产品经理、项目经理、开发代表、市场人员、客户代表、测试代表、技术支持、QA等。

如果每次需求变更审批这些角色都在的话，那成本很高，而且显得很官僚。在实际操作中，可以由产品经理或项目经理牵头，根据实际情况从中召集人选来审批，通常开发代表都是必须参加的。

在一个小型项目中，可能CCB中只有1-2个人就可以做出审批决策。

在一个大型项目（包含多个子项目）中，甚至可以有多个CCB，比如硬件子项目有子CCB，软件子项目有子CCB。

b）变更影响分析

重大变更显然要做变更影响分析。但一个看起来很不起眼的小变更背后可能藏着巨大的工作量，例如，对用户界面上的输入框的最大输入限制增加2个字节，看起来很简单，但可能涉及到接口的变更、数据库的变更、多个子系统的测试、联调。

所以，在答应客户说“好的，没问题！”之前，必须要做变更影响分析。

变更影响分析涉及到如下几个方面：

• 分析变更带来的影响，如，变更会影响哪些子系统与模块？是否会跟其他需求冲突？会影响性能或安全性吗？会影响市场营销、制造、培训、客服计划吗？

• 分析变更时需要修改的文件，包括项目计划、需求文档、原型文件、测试用例、需求跟踪矩阵、用户手册等。

• 分析变更带来的工作量，估算对项目排期和成本的影响。

2.2 需求变更工具

工欲善其事，必先利其器。需要用工具对需求变更进行记录、跟踪、统计分析。

简单的项目可以用Excel表格进行记录与管理。如下是需求变更管理表供参考。

其中“需求来源”、“变更原因”很重要，可以用来在后续进行统计分析。

如下是需求变更管理一览表，可以对整个项目的所有需求变更进行跟踪、管理。

也有很多专业的项目管理工具、需求管理工具、Bug管理工具可以进行需求变更管理。

下图是我以前用过的禅道项目管理系统。

可以在禅道中进行需求变更的记录与跟踪。

在禅道中可以对需求变更进行统计分析。

通过对需求变更的来源进行统计，找出变更次数最多的来源来做原因分析。

通过对需求变更的原因进行分类与统计，可以帮助我们意识到“我们错在哪里、哪里需要提升”，以及“变化点集中在哪里，有什么规律，在设计上怎么优化”。

例如，对历史项目的变更原因进行分类统计，发现很多变更与报表有关，则可以考虑引入报表引擎来解决。

2.3 应对需求变更的策略

前面提到，通过对需求变更进行分类统计、原因分析，需求变更的原因可以分为两类：

a）内因

• 需求相关问题：需求收集不完整、需求遗漏、需求沟通失真等

• 解决方案不符合要求：客户提的需求是用解决方案描述的伪需求，产品经理没有进行需求挖掘，按照客户描述的解决方案做出来的产品没有解决客户的问题，最终导致需求变更。

b）外因

• 业务调整：公司战略转型、产品定位改变导致需求变更

• 外部环境的变化：市场变化、用户反馈、政策调整、行业监管导致的需求变更

接下来针对典型的需求变更原因，分享一些应对策略。

a）需求收集不完整、需求遗漏

• 业务视角：给用户沟通确认的需求文档，不能从技术实现的视角来描述，因为很多用户不懂技术，应该从业务视角/用户视角进行描述，这样用户才能理解，才能发现需求遗漏。

• 原型法：一图胜千言。用图形的方式更直观，用户更容易理解，可以帮助用户发现需要遗漏，也可以减少需求沟通失真。

• 需求补充：通过需求分析方法（如场景分析法、360度分析法等，详见本文：需求分析课程）来补充细节需求。

b）解决方案不符合要求

• 需求挖掘：客户提的需求很多是用解决方案描述的伪需求，可以通过需求挖掘方法来找到深层次的需求，然后再设计解决方案。（详见本文：需求分析课程）

• 原型法：通过产品原型提早跟用户沟通确认，可以提早发现解决方案的问题，避免产品做完之后才发现。

• 场景分析法：客户想要的功能都有了，但是对产品细节不满意，可能因为细节需求没考虑到，可以用场景分析法来发现细节需求，从而改善产品细节。

c）业务调整/外部环境的变化

• 迭代开发：采用敏捷开发方法，把产品分成多个迭代来分批交付，当前迭代期需求冻结，有需求变更的话可以在下个迭代实现，如果一定要当前迭代中实现变更，要替换掉同等工作量的任务，避免对当前迭代的影响。

• 预留变更空间：变更总是会发生的，在预估工作量、制定项目计划时要有风险意识，通常要预留20%的缓冲区。

• 产品设计：设计灵活的软件架构，以便对需求变更进行快速响应；在产品架构设计时要根据经验，针对常见的变化点进行弹性设计，隔离变化点。

本文分享了需求变更流程、变更管理工具、应对需求变更的策略，希望能帮助你应对需求变更。

“这世界上唯一不变的就是变化”。

曾见过一个敏捷团队的需求统计，中途增加了40%的高优先级需求变更，有40%的原始需求被抛弃。

既然我们无法阻挡变化，让我们拥抱变化吧。