临时需求变更处理的两种好方法_客户需求临时变动-优快云博客

一、三次评审策略

由于专业知识不同，对事物认知体系不同总会产生出多多少少的沟通障碍。有些产品经理认为非常简单的改动，往往会导致程序员吐槽。在产品demo开发完成之后，也可能会因为bug不断而被产品经理吐槽，总之，产品经理与程序员的沟通已经在业界讨论了不下10年之久。

在笔者的公司，这种情况也经常发生，对于产品经理与程序员间的交流问题解决办法分为2个方面。

第一个方面是自我约束

自我约束是指双方在交流时每句话都需要谨言慎行，必须经过认真的思考之后才能阐述。

产品经理提需求前需要认真思考，程序员提出质疑时前也需要认真思考。双方都需要对自己的言论负责，只有经过认真思考后表达的观点才能减少冲突。

可惜的是，自我约束只是一个建议，或者说是一项要求，它很难用制度来规范化，所以也就自然不好管理。

第二个方面是通过制度来管理双方的交流问题

三次评审机制可以减少产品经理与程序员的沟通不畅，这个机制是笔者在公司中长期推动使用，并取得了良好的效果。

一般来讲，产品规划至少提前3个版本或更多，PRD至少提前2个版本。假设在产品1.3上线的时候，可以进行1.5版本PRD的评审与技术预估，v1.5版本的PRD需要进行三次评审。

第一次评审主要沟通需求，需要产品经理进行详尽的PRD讲解，开发工程师从技术角度可以提出各种问题。产品经理无法解答的要一一记录在案，会后继续思考完善。

第二次评审产品经理需要回答上次开发工程师提出的疑问或给出的修改建议，不做出修改的阐述坚持理由。

第三次评审需要解决所有问题，双方达成一致准备开发。三次评审机制必须在1.4版本上线前完成，而且每次需要谨慎对待，避免把责任推到下一次会议上。
在这里插入图片描述简而言之，“三次评审”是通过双方的多次对话，使沟通障碍降低到最小。三次评审之时间可以间隔很短，只是给双方预留时间来消化对方的信息，在经过自己的思考加工成自己的内容予以表达。

二、总裁特权策略

产品经理直接与老板沟通，经常听到的一句话就是“XXX，来一下，我这有个需求，这个版本马上就要”。产品经理此时肯定是十万头神兽在心头奔过，无论是否是敏捷开发，无论多么快速的产品迭代，临时加需求都会带来不可预估的工作量。如果功能简单还好，如果涉及复杂逻辑，那真是欲哭无泪。

笔者认为临时加需求本身是合理，谁叫你不是老板，但是这种任意更改的行为需要付出代价。所以，笔者在公司中有提倡建设了分级特权制度。

分级特权制度在于提前预留buffer给所要加的功能，不过并不是每个人都有。

在创业公司中，成为“CEO特权”，通常每一个月有3次机会可以增加需求：第一次免费使用，第二次使用扣除3000工资，第三次使用扣除5000工资，更多的变更原则上是可以拒绝的。

如果在大厂，由所在事业部总经理最终背锅。该制度在于让所有变更都具有代价，从而谨言慎行。在创业公司或中型公司中，该制度较好实现。由于与工资挂钩，在一些大厂并不容易实现。该制度实现并不容易，在笔者公司中也遇到层层阻力。但是制度就是用来约束人的，如果高层都不遵守，公司更难以成体系。

在产品经理的世界中，很有很多坑需要去躲避。不过以后你会感谢这些“坑”，它给你带来了谦卑，让你懂得做事留有余地，也让你懂得了忍耐克己。

跟进临时需求”、“具有项目协调和推动能力”，这是产品岗位介绍中经常出现的两句话。那么，那些临时需求和我们认识的一般需求有什么不同？如何有效的推进这类需求？这是我想和大家分享的两个地方。

临时需求的特点

临时需求有两个含义：

1、自己正在做的需求，因为产品内部或外界因素需要在原本功能需求中临时添加，有些甚至在需求封版后还要进行临时的一些“不太友好“的改动。

这类需求的特点有以下三个方面：明确、紧急、一般可控；

2、别人做了一半的需求，产品组内分工或临时调整后交给了你，状态不一，有些还在需求收集阶段，有些已经在开发状态了。

这类需求的特点是：懵逼、易背锅、还不好控制；

两类临时需求的介入与处理方法：

新增或需要改动的需求

先介绍下第一类：在自己的需求完成过程中，新增或需要改动的需求。

需求优先级

给这类临时需求排优先级要先思考两个问题：这个临时需求来源于谁，他或者他们的目的是什么？如果这个出现在我正常的进度中，会不会导致我核心功能受到影响或者整个项目delay？

我分享下我对需求的优先级简单快速的排序（采用否定的态度思考）：

NO.1 产品目标or公司商业目标：

我就尝试下不做、不加、不改对产品目标or相关商业目标是否有影响？如果影响到了整个公司的商业计划或者是产品的大目标，那么毫无疑问，优先级高高的。本版确实要加要改，研发兄弟们的一个月麻辣小龙虾我包了！

NO.2 对原始核心需求的影响：

我是不是只有不加这个临时的需求，才能确保我原有功能的完整上线、才能保证原有进度的正常或者提前完成。如果这个需求对我的原有功能影响太大，让我不能愉快的刷夜上线了。果断拒绝，下一版再见。

NO.3 对情感与后续影响的把握：

我不加这个临时需求是不会影响到我之后的工作安排与后续的需求实现，在完全的摸透需求方的需求后，是不是存在必须先有一再有二才能有三的关系链，因为自己挖的坑迟早自己是要跳的。。。以及市场运营等等的各位大大会不会对我有偏见，出去聚餐不带上我，导致不能好好工作了等等。

NO.X BOSS或者总监点名

该需求需要在本版或者什么版上线之类的，这部分的优先级请大家自行把握。站的角度不一样，思考的维度与层次不一，但是这部分我每次都是在据理力争后才被迫接受的，嗯。。。

需求实现难度

研发弟兄们对需求的态度不一，但是把握好以下几点还是可以在这个过程中找到平衡点的

讲道理：在思考优先级的时候因为都是从否定的角度上去考虑，我们实际上已经考虑了大部分研发兄弟们的疑惑。这个功能临时加了有用吗？不做不可以吗？万一让XX功能受到影响怎么办？这时候只需要开会的时候和他们一一解答下自己对该需求的认识与思路即可。
带节奏：在紧张刺激的需求过审会上，趁着气氛带下节奏，好了，那这个需求就过了。有什么疑问的话直接私聊我就行。
细整理：把临时需求会影响到的前后台逻辑与交互细节整理出来，即使是一个摁扭、一个交互样式或者是后台数据传输等，与测试碰个小会。确保临时需求的加入对原有需求不会产生影响，保证验收的时候不落不少。

当然，以上实现的难度与排期长短与麻辣小龙虾的口味与分量有关。

未完成需求

接下来重点介绍第二类：在自己正常的工作中，临时接到个未完成的需求。
需求详情

当部分完成的需求来的时候，大部分人一开始并不知道这个需求是干啥的，谁提的都不知道。但是在现实的场景中出现的频率又很高，尤其是在人员变动较大或者人手不足的团队。往往就是产品总监或者boss一句话：“xxx，你来跟下这个需求”，还没反应过来，然后你就一脸懵逼的被接下了。

想要快速了解这个未完成的需求，试试从以下4个问题出发：

1.为什么要做这个需求？

从需求的具体目标出发是了解一个新需求的快速方法之一。

交互类：这个功能是要提升用户体验还是诱导用户做一些事情；
运营类：这个需求是要配合一次拉新活动还是要确保留存率等的提高；
数据类：要配合完成用户画像还是进行数据监控；
后台类：解决了多年来吐槽的点还是提高了工作人员的效率。

其他等等。这部分可以与“前任产品”或者该需求主要需求方沟通。这里就发现留有MRD/BRD/PRD的好处了吧。

当然，要是在这个第一问题中可以把这个需求砍了，那也是极好的。

2.现在完成的进度怎么样了？

是在需求收集阶段还是在已经研发的阶段，是需要协调外部资源还是在上线最后验收的阶段。掌握这个未完成的需求的进度对产品经理来说十分必要。他可以有效的减少与各部门的沟通成本。

是在调研阶段那是很幸福的，相当于可以在掌握了上一个产品收集的资料后，自己从头做个需求。但是如果现在已经在需求封版正在开发的阶段，你频繁的去找需求方聊当初聊的需求而不知道看交付给研发的PRD。遇到强势的需求方，后面就会发现这是很吃力不讨好的行为。。。

总之一句话：拒绝闭眼睛干活！

3.开发有没有遇到困难点？

是否在需求实现的过程中遇到了困难，和研发的沟通极为重要，这部分你是新介入的产品，研发兄弟们是否在开发的过程中遇到了新的问题。是需求本身需要修改还是有疑惑的地方。

知道困难点在哪，紧急且不懂的细节要及时求助“前任”产品。

4.该需求的直接支持方又有哪些？

需求的直接支持方决定了你借力的难度与程度。临时介入的产品相对比较弱势，熟悉需求需要时间，项目组成员之间需要互相磨合等。所以遇到阻力有时候可以借助原始需求方的力量。

人多力量大，产品经理的影响力是需要慢慢积累的。吼吼。

与三方的配合

这里的三方指的是：需求方、相关研发负责人、其他相关的配合人员

需求方：
确认各需求方，并告知该需求的产品负责人已变更，同上所说，得到他们的支持。因为确认需求、改需求等都是要他们确认。
研发负责人：
告知研发兄弟们这个需求产品这块的负责人已经变更了，并详细了解需求实现的进度与技术难点有哪些，需要得到哪些部门等资源的支持。并确认该需求计划完成时间。
其他配合人员：
告知该需求产品负责人已变更，落实相关资源可支持人员。时刻保持紧密有效的沟通。