关于ZAKER 合作 加入

产品经理如何正确地“甩锅”?

身为产品经理,由于业务的繁杂性,经常会苦恼于一个问题——背锅,如何做到让自己不背锅呢?同为产品经理,作者为大家总结了以下经验,给大家提供一些参考建议。

前言

作为产品经理,背锅算是过来人,写在这里无非是想给自己一个总结,让自己以后的工作能尽量少出差错,同时给刚入行的产品一个善意的温馨提示。

所谓甩锅,调侃而已,并非不负责任,我一直认为,当大家都会甩锅的时候,会降低错误的发生概率,当然,我这里有一个大前提就是,如果的确是自己的锅,烫手也要接着。

以下言语之中,如果伤害到了其他岗位伙伴的情感,那只能说声抱歉,都是为了工作,我这里只是自己的总结,但愿你能见谅。

一、产品

自己没有权利决定的事,永远不要自己决定,要和老大确定好,最好有书面确定。这个不是为了甩锅,老大的锅得背着,就是为了让自己心里舒服点,同时也得让老大知道自己在背锅。

多个人负责同一个产品迭代时,要注明哪些是自己的需求,哪些是同事的需求,涉及到数据分析以及埋点,自己搞自己的不要一个人大包大榄。

嘴上说的需求永远不要相信。没有放在需求池里的需求,都不叫需求,凡是需求必有书面的记录。

自己做需求时,功能上最好别创新,看看 BAT,看看 MTD,社会认知已经形成,抄着来不会错,他们都没有的需求,就看看竞品,毕竟有人已经试水,创新留给体验创新,流程创新与模式创新。

二、测试

最好不要看测试用例,异常情况你永远不会考虑的有测试详细,如果测试拿测试用例找你,无法推脱了,那就一定要仔细看,还原到各种场景,最后要问一下他写测试用例的各种场景的复现几率,然后,产品还要再说明自己需求的各种场景。如果测试用例真的出现了自己之前没有考虑到的问题,及时补充到需求文档,并同步开发。

改任何需求都必须与测试确认,最好有书面文档,条件允许该需求测试,开发都在场。

产品验收的问题,只验收自己的需求的流程与逻辑,不要遇见 bug,整理说明,最好有书面文档,产品上线后概不负责。

最好不要跟进 bug 的修改,那是测试的事,把控结果和进度就好了

三、开发

把需求写清,如果有更改,一定第一时间同步所有人。

与开发交流需求问题,最好用文字,因为很有可能开发普通话不太好或者开发表达不清自己的意思,产品会理解错,没法用文字的情况下,交流最后,一定要把自己理解的开发的意思,从自己嘴里再说出一遍,让开发再去确认。

做埋点需求时,无论是客户端,h5 埋点还是服务器埋点都必须在需求里写清。不要口头告诉。

尽量了解开发的实现需求逻辑,但是要假装不知道,和开发沟通需求就说场景,别探讨实现逻辑,因为产品不太懂,开发会挖坑,两三句就给你整懵逼了。除了你真的是一个技术型产品。

各种前端与客户端的实现逻辑很简单,要尽量搞清楚,但是要装不清楚,搞清楚是出于对于排期以及实现的可能性为目的,装糊涂是为了让开发提高自己的创造力。

安卓与 ios 实现逻辑尽量统一,否则再次迭代遇到困难几率会增高,展示统一不了勉强就接受吧。

做需求时,尽量不要发现问题就改问题,要从根源解决,产品思维是网状的,前端开发思维是点状的,很有可能你改了这块,开发就真的改了,和原来逻辑冲突,你不知道,开发也不知道,上线就该有用户反馈了。

四、数据分析采集师

要什么数据同样书面通知,不要只考虑 pv,uv,那个太简单,符合你定义的条件的数值,要说场景,别跟他探讨怎么取数据,他实在做不了,就自己去数据库看看有没有相映字段,或者找开发聊聊。

数据采集师每天都需要配合别人的工作,所以尽量催着自己的需求

五、运营

产品运营不分家,最好和运营搞好关系,但是对于运营活动,运营想法可能会很多,实现不了的要跟他说清楚,自己必要定义活动,配合运营去搞事情,他做主,你画图就可以了。然后哪里什么逻辑一定要口头与书面全告诉运营。

六、UI 设计师

最好设计文案想好,让他直接看需求文档,这样他会了解设计图出现在哪减少沟通成本。

自己需求里最好颜色区分一下你要表达的内容,降低点沟通成本

自己抄的需求,让设计也去抄吧,不会出啥大差错。

设计文案提前想好,要不然被喷死。

结尾:

欢迎广大产品伙伴说说自己的背锅经历,背一次锅就学习了一次,大家一起进步。不喜欢的就别喷了,留点口水需求评审的时候用吧!

本文由 @产品汪汪汪 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

相关标签 闲鱼球鞋天猫
科技频道

科技频道

科技改变世界

订阅

觉得文章不错,微信扫描分享好友

扫码分享

热门推荐