希望这篇分享能给大家带来一些小启发，至少以后别人给你丢了个临时需求时，不会慌张，能够淡定高效的把它完成。

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

临时需求的特点

临时需求有两个含义：

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.该需求的直接支持方又有哪些？

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

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

与三方的配合

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

需求方：

确认各需求方，并告知该需求的产品负责人已变更，同上所说，得到他们的支持。因为确认需求、改需求等都是要他们确认。

研发负责人：

告知研发兄弟们这个需求产品这块的负责人已经变更了，并详细了解需求实现的进度与技术难点有哪些，需要得到哪些部门等资源的支持。并确认该需求计划完成时间。

其他配合人员：告知该需求产品负责人已变更，落实相关资源可支持人员。时刻保持紧密有效的沟通。

记录与反馈

这类未完成的临时需求除了正常的记录等以外，还需要特别注意的就是相关细节的反馈与记录。

• 时间：通常是指立项时间、排期等。这里还需要加上一些每次会议上约定的时间。避免互相伤害！
• 人员：因不熟悉团队相关人员，尤其要注意责任需要到人。避免跟丢！
• 反馈：与上级与以上三方进行进度的汇报，形式不限。确保互相监督！

PS：为了避免费时费力，项目还可能要无限delay，特别提醒大家注意这三块的记录与反馈

总结

希望这篇分享能给大家带来一些小启发，至少以后别人给你丢了个临时需求时，不会慌张，能够淡定高效的把它完成。当然，具备能够跟进临时需求和具有项目协调推动的能力要求远远不止这些。

以上仅是我一年多以来的经验与分享，如有错误，还请大家多多包涵。同时欢迎大家来一起讨论哈。

本文由 @奔跑的鸵鸟 原创发布于人人都是产品经理。未经许可，禁止转载。