这篇是需求变更三步曲中的最后一篇，和各位分享项目流程执行不到位引起的需求变更和应对方法。

1. 产品评审会，开成产品介绍会

产品评审会，是对产品原型的评审；如果是采用用户故事，产品评审会更像是用户故事和故事地图讨论会。

我们程序员写代码都清楚，不管我们多认真，自己验证再好，功能开发出来，测试都会测出很多问题，这个是必然的。所以，产品经理，不管再有经验，设计出来的产品原型，也一定是有很多遗落的、关系错误的、步骤缺失的、逻辑有问题的地方，所以产品评审会是必不可少的。

而产品评审会没有做，或者没有做好，在开发的过程中，产品经理经常改需求是肯定的。就像我们做的功能，没有经过测试工程师测试，由程序员自己测试或交叉测试后直接上线，运营过程中，总会时常蹦出一些问题一样。

产品评审会常见的错误有三种，而犯这些错误，产品原型的质量就没有保证，开发过程中改需求是必不可少的。

1） 没有给项目组预留评审时间

很多产品经理，原型设计出来之后，没有给项目组预留时间，就开始评审。比如明天上午要开评审会，今天晚上加班把原型设计赶出来。

这样会产生什么问题呢？参与评审的人，对产品的细节没有思考过，对功能的理解不深，他发现不了问题，也提不出意见。往往会出现两种情况：

一、把产品评审会开成产品介绍会，产品经理在上面介绍功能，大家听完就完事了。

二、把产品评审会开成需求讨论会，本来预计两个小时的会议，开一上午还没讨论清楚，下午还要再开一下午。

正常的操作是，原型设计出来后，至少要给项目组预留一天时间出来，让成员花时间去理解原型，提前找出问题，或者有疑问的地方。评审的时候把问题和疑问拿出来讨论。如果产品经理当场能解决最好，不然产品经理就记录下来，会后再思考，然后修改原型，下次评审再过这些问题。

一般中型的项目，第一次评审，我自己预评审下来，会有30-50个问题和疑问。如果评审的时候没有把这些解决掉，就算一半是问题，那体现在开发过程中，就会有一二十次的改需求。

2） 项目组没有全部参加评审

产品评审是整个项目组都要参加。而实际做项目的时候，运营团队、市场团队往往不参加，这就会带来一个问题，产品和研发团队玩得很high，觉得产品设计的很好，功能很强大。而经常听到运营人员在那里说，你们开发的这是什么鬼，让我们怎么运营，这神仙来都没有救。这个就是运营团队不参与评审的后果。

这个引起的问题，经常是版本上线之后，发现运营不了，或者活动上线了，运营不了。直接就是版本事故，至少也是运营团队KPI不达标的背锅侠。

3） 没有多次评审

产品评审正常要多次评审，因为在评审的过程中，会发现很多问题，项目成员会提很多意见，或者有些问题在会议上没有讨论出方案。这些都是需要产品经理会后去修改产品原型的。

修改完之后，还要过评审，因为他思考的不一定是对的，所以再拿出来评审，项目组对产品就会有个共识，开发的时候就不会偏。

解决方法：

一个有效的产品评审会，项目组成员对产品的理解基本上一致，产品上的问题，大部分都会被找出来，这样开发的时候，改需求就少了。

2. 产品没有统一验收标准

产品没有统一验收标准而产生的需求改动，这个一般会发生在项目的中后期。随着项目的进展，项目管理的难度逐渐增加，对标准的执行不到位，甚至根本就没有标准，这样产品设计慢慢就变样了。展现出来的主要有两种情况。

1） 产品有多套验收标准

产品经理设计完产品原型，在项目过程中，产品经理会有新的灵感出来，就会带来设计的变化，这时找程序员讨论新想法，确定了新方案；程序员在开发的过程中，会发现产品设计上的一些问题，与产品经理讨论，当下产品经理会与程序员确定一种方案。

但是这些情况，经常发生在口头上，比如产品经理和Android端讨论清楚，他可能同时会告诉IOS端要做相应的修改。但是他经常会忘了告诉后台和接口人员，甚至也没有改产品原型。于是后台和前端联调的时候，发现接口对不上，争吵一番之后，产品经理基本上被骂的狗血淋头。

大家以为事情就完事了，但是功能开发完成之后，测试工程师按产品原型设计的测试用例来测试，就一大堆问题。测试工程师可能还会去看下UI交互图，看自己是不是理解错了，结果发现产品设计没问题啊。接下来就是问题了，几方要争执很久才会发现问题出在哪里，但是时间都浪费了。

2）产品经理“偷偷”改需求

产品经理有时会有新的想法出来，或者对功能的步骤做了微调，就改了产品原型。因为已经过了产品评审，他自以为工程师会按新的原型来做开发，结果往往会出现各种问题。

1）新增加的内容，可能看似简单，但会影响发布时间。

2）接口开发往往会比较快，前端开发会比较慢。可能接口已经按之前的设计开发完了，而前端是按之后设计的版本开发，这样在联调的时候，就会出现两者都坚持自己是按原型来开发的，指责对方是错的，而往往没有发现各自坚持的原型是不一样的。

这里简单分享两种没有统一验收标准的情况。出现这类问题，靠程序员和产品经理吵到死都解决不了。而解决这类问题，是比较简单的，要通过项目的流程管理来解决。

解决方法：

制定产品需求修改规范。

至于制定什么规范，这个可以按团队的喜好来定。我分享一种用过的有效的方法。

我们之前团队有个产品经理，经常“偷偷”改需求，把研发搞得不胜其烦，后来技术老大就想了个办法：用GIT统一管理产品原型，只要是评审过的产品原型，就把修改权限回收回来。产品经理要修改可以，拉分支修改，修改的内容，在项目周会上过需求，大家同意修改，才可以把修改的内容合入到正式的产品原型中，这样项目组所有人都知道改了什么，而且相当于做了个简单的需求评审。

敏捷宣言第一条：个体与交互 胜过 过程和工具。遇到这种问题，最重要的是当下参与的个体都要参与到需求变更的交互中，才是一个有效的变更。如果产品经理每做一次改动，都把相关参与人拉在一起讨论，这个是很影响其它人工作的。这个方法，把这个时间延长到一周，减少了对其它人的影响，又确保了所有参与人员都参与到交互，是个比较有效的方法。

当然，会遇到当下必须处理的情况，这时还是需要把相关人员都拉在一起讨论，或者有讨论的结果，把大家拉一起共识这个改动。然后产品经理把这个改动更新到产品原型中，这样确保产品有统一的验收标准。

作者介绍

陈华祥

18年全栈工程师，8年集团公司CTO；

项目管理、职业成长、研发系统建设专家；

《艾米视频聊天》，装机量3亿，注册用户4000万；

腾讯学院《腾学汇》项目负责人；

锐思克网络创始人

项目管理、程序员职业成长企业内训讲师和教练；

《程序员职场第1课》、《职业规划：程序员百万年薪修炼之道》、《高级程序员进阶修炼》、《项目管理从入门到精通》，作者、讲师。