扫码阅读
手机扫码阅读

如何应对需求变更?

65 2024-01-27

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

大爷 = 客户

服务员 = 小白产品经理

大厨 = 软件开发人员

【餐厅】

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

“服务员,给我来份宫保鸡丁!”

“好嘞!”

——这叫原始需求

(思考:如果你是产品经理,拿到这个原始需求会怎么做?)

【餐厅】

大厨做到一半。

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

“不放肉怎么做啊?”

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

“好的,您稍等”

——中途需求变更

(思考:如果你是产品经理,接到这个需求变更应该怎么做?)

【厨房】

大厨:“你大爷,我肉都回锅了”

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

大厨:“行你大爷!”

然而还是一点点挑出来了

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

【餐厅】

“服务员,菜里能给我加点腐竹吗?”

“行,这个应该简单。”

——低估改动成本

【厨房】

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

服务员:“啊,你怎么不早说?”

大厨:“我怎么知道他要往宫保鸡丁里放腐竹?!”

然而还是去泡腐竹了

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

【餐厅】

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

“您不是刚说不要肉吗”

“现在又想要了”

“...好的,您稍等”

——某一功能点摇摆不定

【厨房】

大厨:“真想揍你!菜都炒过火了你让我放肉?还好肉我没扔”

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

大厨:“你就不能拒绝他啊?啊?”

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

——甲方是大爷

【餐厅】

“服务员!服务员!”

“来了来了,你好?”

“怎么这么半天啊?”

“稍等我给您催催啊”

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

【厨房】

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

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

【餐厅】

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

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

“行...您稍等”

——甲方催活

【厨房】

大厨:“我晕,中途改需求又想按期交付,逗我玩呢?”

服务员:“那我问问,要不让他们换个菜?”

大厨:“再换我就死了”

——开发人员开始和产品经理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%的原始需求被抛弃。

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzAwNDI4NzIwMg==&mid=2457450221&idx=1&sn=9cf496f297da4b49cb3fc873c5ffe9c9&chksm=8ca32960bbd4a07603a63f531ad7d01ac0484231b3a684f3e78eb1572c6ea83b167e0af0e8e9#rd