产品在最终上线出现了问题，必然是由众多因素所致，所以才会出现团队甩锅现象的发生。出现问题不要紧，重要的是，产品经理可以通过哪些方法来避免团队之间甩锅现象的发生。

“我们是谁”

“我们是产品经理”

“我们的日常是”

“撕逼、背锅、甩锅”

“人在工位坐，锅从天上来”，作为苦逼的产品经理，必须要做好时刻背锅、接锅的准备。

“常在河边走，哪有不湿鞋”，其实，不仅仅是产品经理，只要身处职场中，总会有那么一两个锅砸来，轻则撕逼，重则大打出手，造成团队关系恶化，进而对团队工作产生不可逆的影响。

与其被动的“后发受制于人”，何不尝试“先发制人”。那么，作为团队“主心骨”的产品经理，我们怎样做可以尽量避免团队成员之间甩锅现象的发生，从源头遏制问题的产生呢？

通过“Case-Case”的方式重现问题，会更加明确的给我们一些实际的提示。下面我们一起跟着故事去思考，产品经理可以通过哪些方法来避免团队之间甩锅现象的发生。

雪崩时，没有一片雪花觉得自己有责任

案例一：

某童鞋在刚入坑时，负责了一个简单的数据产品，由于是数据产品，所以需求只是通过简单的口述，就进入了开发流程，结果出了上线事故。

事后复盘，分析原因，发现是由于Python与Java语言规则不同，导致了接口联调失败。测试认为已按照需求完成了测试，且代码功能正常，问题不在测试；其他两个接口开发也觉得自己的代码运行正常，问题在于上线前未进行联调，一时间三方各执一词，开启了“甩锅大战”。

那么，针对案例里的出现甩锅事件，我们又该如何避免呢？

1. 漏测的测试

案例中，上线任务是依照“产品-开发-测试-上线”流程开展的，出现了上线事故，多数时候，测试作为上线前的最后一道关卡，往往也会因为测试用例未覆盖到位，而成了直接责任人。

仔细的我们会发现，导致漏测最主要的原因就是需求没有说清楚，问题既然已经定位清楚了，那下一步就是“对症下药”了。

在工作中，我们经常会使用文档用来交流，因为其具有可传递性和完整性。因此，像这种技术上的对接，我们必须要有一个完整的文档对一些必要的细节进行记录和描述，减少沟通过程中信息的遗漏，使大家都可以接收到完整有效的信息，进而保证了沟通的有效性。

所以，一份完整且清晰的需求文档是开发环节必不可少的。好的需求文档，需要具备以下几点特征：

1）正确

用户的需求能够被正确的满足，且逻辑清晰无误的被表达。

2）完备

需求文档要尽可能完整且颗粒度较细的把所有场景、特殊情况、业务、产品、数据流逻辑都写清楚。

3）无歧义

文档里所有的用词、描述要精确，切不可出现“可能”、“大约”“在某种程度上”等模棱两可的表述，让开发人员去猜测我们的想法。

4）优先级

像画原型一样，一个产品必然由多个功能来满足，而多个功能等待开发时，就一定要注明优先级，告诉开发我们的重点是什么，而后是什么。

5）可验证

所有设计的功能，是在技术评估后，可以被准确实现，且测试验证无误的。

2. 低效的团队沟通

案例中，在产品上线失败后，由于相互甩锅而再一次引发了团队矛盾，上演了一场“甩锅大战”。究其根本原因，实则是开发过程中，团队出现了低效的沟通所致。

因此，一次有效的需求评审是至关重要的，因此，我们可以将需求评审分为三个阶段进行：

评审前：

1）准备并确定相关资料的接收对象，并提前下发

相关资料包括我们的需求文档、线框图、原型、相关数据等。

图2-1  需求文档目录

图2-2  需求文档思维导图

由产品经理主导，召开一次简单的需求评审会（强调下，再简单的需求，也是需要拉上团队成员开一次简短的需求评审的）。会议前，我们需要把需求文档、提纲、流程等提前1-2工作日通知到大家，使大家对会议目的、时长和需求有一个了解，以便做好评审会议前的准备工作。

2）小范围的沟通确认方案

产品的需求文档写好了，但是里面的功能和解决办法却不一定都可以实现，那我们在不确定的时候，就可以先去找开发私下沟通这块的内容，在会前提前讨论，达成一致意见。这样可以避免我们在评审时，因为一个功能点实现不了或不合理而被1000次暴击。

3）产品内部评审，降低被怼的风险

俗话说，“三个臭皮匠，能抵诸葛亮”，一个人的思维和能力往往是有限的，设计出来的产品也不可能做到面面具到。所以，在需求评审前，我们往往可以在产品内部进行一次小范围的评审，这样可以避免大部分需求不合理的地方，能直接有效的提升需求评审的效率，同时，也能增加团队对我们的信任感，减少被怼情况的发生。

评审中：

1）适当的强硬，在气势上压倒一切

在需求评审会议正式开始前，我们一定要做好准备，针对需求里面可能会被怼的地方，提前想好、做好应对策略，作为我们的态度强硬的底气。

2）明确目标，做好会议的主导者

产品经理作为需求评审会的发起者和组织者，在此次评审的目的上和方向上应具有足够清晰的认识和把控。比如讨论A功能能不能被实现时，话题突然变成了该功能要不要做的问题。此时，我们就要及时的把大家拉回来，告诉大家此时所有的需求都是已经确定了的，是必须要做的，我们只需要讨论出如何实现的问题就可以了。

时刻记住自己此次需求评审的目的和要达到的效果，即使在被多人手撕的时候，也不能动摇，才让大家跟着我们评审的目标走，明白要做哪些功能点。

3）果断出手，做好会议时间的控制者

本来一个小时的会议，硬是被开成了三个小时的长会，一场会议下，经常是汗流浃背，精神虚脱，这样的评审效果其实并不理想。

所以，我们产品经理要做好时间的控制者，如果遇到需求模棱两可的问题，并且已经超过了会议讨论时间，还没有商量出解决方案的情况时，此时便是按下暂停键的最好时机，切不可因小失大，过度纠结于局部。可以将问题确认后，记录下来，会后完善，必要的时候开二次评审也是OK的。

4）认真聆听，理智回应

人在接受到与自己认知不一样的看法和观点的时候，往往第一反应就是要打断别人，阐述自己的想法与之分辨。这样在会议中，很容易浪费时间，并且很能会产生争执，脱离会议主题。

因此，产品经理作为最作为先阐述需求和解决方案的一方，必然要面对这样的挑战。

选择认真聆听，而后对症下药，是一个尊重别人，又能获取表述机会的好方法。

通常在被别人打断了，我们先冷静下来，不妨认真听下别人的看法和观点，并在大脑中快速形成一个思维导图，迅速对比两个方案，并找出差异点。再针对两个方案的差异点，想出一个更好的解决方案。

这时，我们就可以把自己的理解复述给对方听，在获得对方的认可后，再抛出自己的疑惑，当发现对方显然没想到时，我们再引出自己的方案，获得台下掌声一片，岂不美哉！

当然，这样的临场反应能力不是一朝一夕就能练就出来的，需得“久经沙场”方可提升。不过，这只是应对之策，还是要提前准备充足，方可先发制人，才不会陷入被动的境地。

5）定好开发周期和人员，确定产品诞辰

在需求评审顺利的情况下，开发的工作量一般都能当场评估出来，会后就可直接安排上线时间了。

假如由于功能复杂，需要会后给出评估结果，那么就让大家会后统一评估后，再上报工作量。我们汇总后，在其结果上延后2-3个工作日即可给出线时间了。

又或是需求未评审清楚，需要二次评估时，那么我们就在下次会议上给出结果。注意两次需求评审会议不能间隔时间过长，时间久了，大家都会忘记最开始的需求。

评审后：

会后要在24小时之内输出会议纪要，从两方面概述本次会议内容，不需要详细记录每个过程，比如每个人说的每一句话。

1）已解决的

包含已解决的问题描述、解决方案、责任人、起止时间，可以用表格的形式列在文件里，一目了然。

2）待解决的

也可以用上述同样的方式记录下，发给大家。

RICA矩阵是呈现工作包、人、责任三者关系的管理工具，如下列图表，“什么人、做什么事、需要承担怎样的责任”，在网格化的管理下，项目中每个角色的职责变得都清晰、明了，易于管理，我们可以将其作为产品/项目管理的工具。

这样一来，既获得了大家对需求的一致意见，也确保了需求的可操作性和团队之间沟通的顺畅和有效性。

3. 未识别的风险

在项目中，团队成员都要有敢于质疑的精神。如果大家都能保持这样的警惕，那么案例中的问题，是否会有可能被避免掉呢？答案是肯定的。

所以，作为产品经理，我们首先要明确，风险识别是风险管理的一部分，是贯穿整个产品开发生命周期的，在生命周期的不同阶段，关注的风险点也是不一样的。

那么在实际开展工作中，我们该如何尽早识别风险呢？

在项目管理中，风险经常被分类为以下几种：

1）外部风险

主要来自于项目开发环境，比如社会环境、国家的政策法规的变化；自然环境的变化，如地震、水灾、火灾等的发生，会给项目带来风险。

2）组织风险

主要来自公司内部，如公司领导支持不到位，缺乏资金或外部资源；项目组中人员流动、内部部门壁垒等。

3）项目管理风险

常见有计划不到位、产品立项太草率，脱离用户和市场需求；产品经理、项目经理不懂得如何采用项目管理方法去管理风险等。

4）技术管理风险

需求评估时，对功能实现的技术评估不到位导致后面实际开发中出现很多技术难点、专利等技术壁垒带来的风险。

同样，对于产品管理来说，我们也可以用上面的方式来提前识别风险。

比如：

设计阶段

我们要关注：“是否会缺乏相关的技术专家对技术可行性的评估”，“产品的需求定义不清楚是否会造成后续不断进行变更”，“产品的目标客户不明确，开发出来的产品是否要对哪个市场和需求负责”等问题。

开发阶段

则要考虑：“需求够不够明确”，“公司管理层意见不统一，是否会突然停掉开发”，“团队角色定义不清楚，缺乏有经验的成员”等问题。

做好对常见问题的排查工作，以达到预识别风险的目的。

然后，就是要做好风险收集。作为风险识别的主要责任人，我们需要及时的收集到大家在产品开发过程中，提前识别出的问题，并将其登记在册。

最后

产品在最终上线出现了问题，必然是由众多因素所致，所以才会出现团队甩锅现象的发生。

出现问题不要紧，重要的是，聪明的我们要学会用“二八法则”，很好的分离出那20%的最主要原因，针对甩锅事件的具体问题，提出针对性的方案。

 

本文由 @产品小白@璿悦 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议