项目中如何避免团队成员相互甩锅？

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

“我们是谁”

“我们是产品经理”

“我们的日常是”

“撕逼、背锅、甩锅”

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

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

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

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

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

案例一：

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

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

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

1. 漏测的测试

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

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

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

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

1）正确

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

2）完备

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

3）无歧义

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

4）优先级

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

5）可验证

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

2. 低效的团队沟通

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

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

评审前：

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

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

图2-1  需求文档目录

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

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

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