本文是需求变更三部曲中的最后一篇，与大家分享项目过程执行不佳导致的需求变更以及相应的方法。
1.产品审查会议将作为产品介绍会举行。
产品评审会议是对产品原型的评审；如果使用用户故事，产品评审将更像是用户故事和故事地图研讨会。
我们程序员都知道，不管我们写代码的时候有多认真，不管我们自己验证的有多努力，功能开发出来的时候，很多问题都会被测试发现，这是不可避免的。所以产品经理，无论多么有经验，都要设计出很多缺失、关系错误、步骤缺失、逻辑问题的产品原型，所以产品评估必不可少。
但是产品评审会一直没做，或者说没做好。在开发过程中，产品经理经常改变需求是肯定的。就像我们做的这个功能，是程序员自己测试或者交叉测试后直接上线的，不需要测试工程师测试。在操作过程中，总会冒出一些问题。
产品评审会常见的错误有三种，但如果犯了这些错误，产品原型的质量就无法保证，需要在开发过程中更改需求。
1)没有给项目组预留评审时间。
很多产品经理，在原型设计完成后，没有给项目组预留时间，就开始评审。比如明天早上要开评审会，今天晚上加班赶样机设计。
这会造成什么问题？参与评审的人对产品的细节没有思考，对功能没有深入了解。他找不到任何问题，也提不出任何建议。通常有两种情况:
先把产品评审会变成产品介绍会，产品经理介绍功能，大家听完就完事了。
第二，把产品评审会变成需求讨论会，原本预计持续两个小时。一上午都没谈清楚，下午还要再谈一下午。
正常的操作是，原型设计出来之后，至少要预留一天的时间让项目组出来，让成员有时间了解原型，提前发现问题或疑问。复习的时候，把问题和疑问拿出来讨论。如果产品经理能当场解决问题最好，否则，产品经理会记下来，会后再思考，然后修改原型，下次再检讨这些问题。
中型项目，第一次复习，我自己预习，会有30-50个问题和疑问。如果在评审时没有解决这些问题，哪怕有一半是问题，也会反映到开发过程中，会有十几二十个变化。
2)项目团队没有全部参与评审。
产品评审是整个项目团队的参与。实际做项目的时候，运营团队和营销团队往往不参与，会带来一个问题。产品和RD团队玩的很high，觉得产品设计很好，功能很强大。经常听到运营商在那里说“你们开发的是什么鬼？怎么操作呢？这个仙女一直没救了。”这就是运营团队不参与评审的后果。
由此引发的问题往往是版本上线后发现无法运营，或者活动上线无法运营。是直接版本事故，或者至少是运营团队KPI不达标的背锅侠。
3)没有多重评论。
产品评审通常需要多次评审，因为在评审的过程中，会发现许多问题，项目成员会给出许多意见，或者有些问题没有在会议上讨论。这些都需要产品经理在会后修改产品原型。
修改完了还要评审，因为他认为的不一定对，所以他拿出来评审，项目组对产品就有共识，开发的时候就不会有偏差。
解决方法:
在一个有效的产品评审会议中，项目组成员对产品的认识基本一致，产品上的大部分问题都会被找出来，这样在开发的时候，修改的需求就会少一些。
2.产品没有统一的验收标准。
产品没有统一的验收标准，需求变更通常发生在项目的中后期。随着项目的进展，项目管理的难度逐渐增加，标准执行不到位，甚至根本没有标准，于是产品设计慢慢发生变化。主要有两种情况。
1)产品有多套验收标准。
产品经理设计出产品原型后，在项目的过程中，产品经理会有新的灵感，从而带来设计的改变。这时候程序员会讨论新的思路，确定新的方案；在开发过程中，程序员会发现产品设计中的一些问题，和产品经理讨论，现在产品经理会和程序员确定一个方案。
但是，这些情况往往发生在口头上。比如产品经理和Android有明确的讨论，他可能会同时告诉IOS做相应的改变。但他经常忘记告诉后台和界面人员，甚至不改变产品原型。所以在调试后端和前端的时候，发现接口不匹配。吵了一架，产品经理基本上被骂的头破血流。
大家都以为事情结束了，但是功能开发完成后，测试工程师按照产品原型设计的测试用例进行测试，出现了大量的问题。测试工程师也可能会看看UI交互图，看看是不是理解错了，结果证明产品设计没问题。然后就是问题了。几方争论了很久才发现问题出在哪里，时间浪费了。
2)产品经理“偷偷”改变需求
产品经理有时会提出新的想法，或者微调功能步骤，然后改变产品原型。因为他已经通过了产品评估，他认为工程师会按照新的原型来开发，结果往往会出现各种问题。
1)新增加的内容看似简单，但会影响发布时间。
2)界面开发往往更快，前端开发往往更慢。可能界面是按照之前的设计开发的，而前端是按照后来的设计版本开发的。就这样，在调试的时候，两个人都坚持自己是按照原型开发的，指责对方是错的，却往往发现不了各自的原型是不同的。
这里我简单分享两个没有统一验收标准的案例。这种问题，跟程序员和产品经理吵到死都解决不了。解决这类问题，比较简单，要通过项目的过程管理来解决。
解决方法:
制定产品需求修改规范。
至于制定什么规范，这个可以根据团队的喜好来定。我分享一个用过的有效的方法。
之前我们团队有个产品经理，经常“偷偷摸摸”改需求，让RD极其讨厌。后来技术老板想出了一个解决方案:用GIT统一管理产品原型，只要是经过审核的产品原型，就收回修改权限。产品经理需要修改可以修改的内容，分公司可以修改的内容。在项目周会上满足要求后，大家都同意修改，然后修改的内容就可以纳入正式的产品原型中了。这样项目组的每个人都知道修改了什么，相当于一个简单的需求评审。
第一个敏捷宣言:个人和交互比过程和工具更好。在遇到这类问题时，最重要的是所有参与的个体都要参与到需求变化的互动中，这才是有效的变化。如果每次产品经理做出改变，都会把相关的参与者召集起来讨论，会极大的影响其他人的工作。这种把这个时间延长到一周的方法，减少了对其他人的影响，保证了所有参与者都参与互动，是一种比较有效的方法。
当然，会有一些必须在此刻处理的情况。这个时候还是要把所有相关人员召集到一起讨论，或者有讨论的结果，这样才能把大家召集到一起，对这个变化达成共识。然后产品经理把这个变更更新到产品原型上，这样才能保证产品有一个统一的验收标准。
作者陈做了18年的全栈工程师，CTO集团公司八年了。项目管理、职业成长、RD体系建设方面的专家；艾米视频聊天，装机量3亿，注册用户4000万；腾讯学院腾学汇项目负责人；项目管理讲师兼教练，程序员专业成长，锐科网络创始人；第一课程序员职场，职业规划:程序员百万年薪培养之道，高级程序员培养，项目管理从初学者到精通，作者，讲师。
