为什么想打产品经理

3fbd1d416e4e4466d8c42bee8665ca7e_b.jpg

第一:现在很多产品经理不够专业。
就我接触的一些在提需求的时候比较业余,没有经过专业的学习和训练。比如说我在得到一个需求的时候,其实比较希望的是产品经理是基于自己的专业素养和经验做出的判断,最起码这么做是有比较充分的理由的,但是很多产品经理提需求都是先做做看,基本上就是在枚举各种方案,碰巧这个还不错就用这个了。
这么做的结果就是开发人员的工作量增加了很多,而且经常需要加班。从某种程度上来说是开发人员通过加班工作来为产品经理的不专业买单,所以开发人员不喜欢产品经理是很自然的。
第二:外行领导内行。
产品经理名字里带个经理,大部分情况下程序员也是按照他们的需求在工作,但是产品和开发其实是两个完全不同的行业,并没有太多相同点。
所以这就出现了外行领导内行的尴尬,两边互相不理解是太自然的事情了。
第三:部分程序员在甩锅。
程序员行业的水平也都是良莠不齐,部分程序员因为或能力或态度的问题无法完成自己的工作,反过来说需求不专业。
因为现在程序员行业已经形成了批判产品经理的风气,如果碰巧自己的产品经理再出现一些问题,这些人就很容易就忽视自己的问题,将责任都甩出去。
其实产品经理跟程序员之间哪有那么多深仇大恨,都是给人打工的,多少有点儿被媒体放大了。
理想的情况应该是 牛逼的产品经理+牛逼的程序员=牛逼的产品

现实情况大部分是 不合格的产品经理+勉强合格的程序员=日了狗的产品

特别是遇到这样的:
1、方案阶段,声音最大,左一个“体验不好”,右一个“没有意义”,甚至对UI评头论足“这个icon丑”、“这个分割线不对”
2、评审阶段,不关注细节,一眼望去,曰“就那么回事”,然后开始玩手机。
3、不看需求文档。UI+跳转+批注,可读性已经非常非常高了,反正就不看。
4、排期的时候,问之:能完成吗?答曰能,要不要给你再多争取点时间?人家一脸受到侮辱的表情。
5、开发阶段,不理解需求的问题就出来了,这个怎么能这样呢?那个设计得不对吧?这样子开发不出来!什么,竞品可以?反正我不行!好的,轻者改交互方式,重者推倒重来,当然延期是百分百的。
6、好吧,延期了,项目总结的时候,一句:你们的设计有问题,完美甩锅。
7、日常情况呢,改了个接口,就是不说,用户发现功能不好使了,问之,曰:“换接口了!”
8、就这样的开发,还是得哄着让着,因为人家写代码,是大爷。
9、这样的开发多吗?占全了的肯定不多,随便来个两条,就够产品喝一壶。
在知乎,话语权都是程序员把持,所以产品各种被喷,各种背锅。但现实的情况呢?有多少不靠谱的产品,同样有多少不靠谱的开发,靠谱不谱是个人的属性,而不是一个岗位的。

本来只是吐槽,忍不住多说两句。
无论是产品还是开发:
请重视需求评审!
请重视需求评审!
请重视需求评审!

什么是需求评审?
不是产品上去大概讲解一下功能点就结束了!
所有的操作逻辑!展示内容!交互方式!异常情况!都要说清楚!
这个icon什么情况什么颜色能点不能点都说清楚啊!
开发也不要听了就算了,提问题啊!特么的这个按钮什么时候能点什么时候不能点,点了要判断些什么,不同的情况会发生什么事,成功了怎么办,失败了怎么办,因为原因A失败的、原因B失败的是否一样,打破砂锅问到底啊!
如果不行,说啊!如果这么做代价太高,说啊!你有什么建议or意见,说啊!
评审就是拿来撕逼的啊!这个时候不撕还等到什么时候?等到开发到一半再撕逼吗?
就算看见开发点头如捣蒜,产品也不要微微一笑就走人了啊!让开发再给你讲一遍!他说不出来就是没理解!没理解就很有可能开发出来一个完全不一样的东西!
不要觉得一次评审就可以了!直到开发和产品对所有细节都达成一致才算结束好吗!不要觉得评审浪费时间!特么的开发到一半推倒重来才叫浪费时间!
评审结束确认清楚了,产品灵光一现突然想改个啥?下个版本再改!开发也老老实实按需求文档来!
特别是大版本,功能复杂时候,评审一定不能少!敏捷开发?敏捷也得把需求确认清楚再开发!
开发在评审阶段什么都发现不了?要么就是不认真,要么就是水平有限。
产品直接拿着个没细化的需求就来评审了?拒绝他,让他回炉重造。不然就是在浪费所有人的时间。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/354.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息