域名频道资讯站身为产品经理，由于业务的繁杂性，经常会苦恼于一个问题——背锅，如何做到让自己不背锅呢？同为产品经理，作者为大家总结了以下经验，给大家提供一些参考建议。
前言
作为产品经理，背锅算是过来人，写在这里无非是想给自己一个总结，让自己以后的工作能尽量少出差错，同时给刚入行的产品一个善意的温馨提示。
所谓甩锅，调侃而已，并非不负责任，我一直认为，当大家都会甩锅的时候，会降低错误的发生概率，当然，我这里有一个大前提就是，如果的确是自己的锅，烫手也要接着。
以下言语之中，如果伤害到了其他岗位伙伴的情感，那只能说声抱歉，都是为了工作，我这里只是自己的总结，但愿你能见谅。
一、产品
- 自己没有权利决定的事，永远不要自己决定，要和老大确定好，最好有书面确定。这个不是为了甩锅，老大的锅得背着，就是为了让自己心里舒服点，同时也得让老大知道自己在背锅。
- 多个人负责同一个产品迭代时，要注明哪些是自己的需求，哪些是同事的需求，涉及到数据分析以及埋点，自己搞自己的不要一个人大包大榄。
- 嘴上说的需求永远不要相信。没有放在需求池里的需求，都不叫需求，凡是需求必有书面的记录。
- 自己做需求时，功能上最好别创新，看看BAT，看看MTD，社会认知已经形成，抄着来不会错，他们都没有的需求，就看看竞品，毕竟有人已经试水，创新留给体验创新，流程创新与模式创新。
二、测试
- 最好不要看测试用例，异常情况你永远不会考虑的有测试详细，如果测试拿测试用例找你，无法推脱了，那就一定要仔细看，还原到各种场景，最后要问一下他写测试用例的各种场景的复现几率，然后，产品还要再说明自己需求的各种场景。如果测试用例真的出现了自己之前没有考虑到的问题，及时补充到需求文档，并同步开发。
- 改任何需求都必须与测试确认，最好有书面文档，条件允许该需求测试，开发都在场。
- 产品验收的问题，只验收自己的需求的流程与逻辑，不要遇见bug，整理说明，最好有书面文档，产品上线后概不负责。
- 最好不要跟进bug的修改，那是测试的事，把控结果和进度就好了
三、开发
- 把需求写清，如果有更改，一定第一时间同步所有人。
- 与开发交流需求问题，最好用文字，因为很有可能开发普通话不太好或者开发表达不清自己的意思，产品会理解错，没法用文字的情况下，交流最后，一定要把自己理解的开发的意思，从自己嘴里再说出一遍，让开发再去确认。
- 做埋点需求时，无论是客户端，h5埋点还是服务器埋点都必须在需求里写清。不要口头告诉。
- 尽量了解开发的实现需求逻辑，但是要假装不知道，和开发沟通需求就说场景，别探讨实现逻辑，因为产品不太懂，开发会挖坑，两三句就给你整懵逼了。除了你真的是一个技术型产品。
- 各种前端与客户端的实现逻辑很简单，要尽量搞清楚，但是要装不清楚，搞清楚是出于对于排期以及实现的可能性为目的，装糊涂是为了让开发提高自己的创造力。
- 安卓与ios实现逻辑尽量统一，否则再次迭代遇到困难几率会增高，展示统一不了勉强就接受吧。
- 做需求时，尽量不要发现问题就改问题，要从根源解决，产品思维是网状的，前端开发思维是点状的，很有可能你改了这块，开发就真的改了，和原来逻辑冲突，你不知道，开发也不知道，上线就该有用户反馈了。
四、数据分析采集师
- 要什么数据同样书面通知，不要只考虑pv，uv，那个太简单，符合你定义的条件的数值，要说场景，别跟他探讨怎么取数据，他实在做不了，就自己去数据库看看有没有相映字段，或者找开发聊聊。
- 数据采集师每天都需要配合别人的工作，所以尽量催着自己的需求
五、运营
- 产品运营不分家，最好和运营搞好关系，但是对于运营活动，运营想法可能会很多，实现不了的要跟他说清楚，自己必要定义活动，配合运营去搞事情，他做主，你画图就可以了。然后哪里什么逻辑一定要口头与书面全告诉运营。
六、UI设计师
- 最好设计文案想好，让他直接看需求文档，这样他会了解设计图出现在哪减少沟通成本。
- 自己需求里最好颜色区分一下你要表达的内容，降低点沟通成本
- 自己抄的需求，让设计也去抄吧，不会出啥大差错。
- 设计文案提前想好，要不然被喷死。
结尾：
欢迎广大产品伙伴说说自己的背锅经历，背一次锅就学习了一次，大家一起进步。不喜欢的就别喷了，留点口水需求评审的时候用吧！
本文素材来自互联网
