开发人员最讨厌产品经理的哪些做法?

这个问题可以和另外两个问题一起看: 开发人员最喜欢产品经理的哪些优点: http://www.zhihu.com/question/19636894?…
关注者
2,180
被浏览
273,497

143 个回答

开始实施之前

【说不清需求价值】,技术问“为什么要做”的时候,支支吾吾,或者说“老板要的、运营要的”,成为了传话筒,是最Low的,相反,能有理有据的顶老板的产品经理,通常会在大家的眼中逼格满满;

【没想到功能细节】,表现为技术问细节(当然,是涉及业务的细节,不是技术实现细节)的时候,自己还没想过,现场想,被发现了,或者因为是接二手需求,并不知道、也没有去追溯这个需求的初衷;

【帮技术评估工作量】,特别是技术出身的产品经理容易犯这个错,潜台词就是“希望加活”,我评估过了,这些都能做掉的,不要给我偷懒;

【逼着技术团队承诺】,产品经理想的是,如果技术承诺了,但却做不到,这样自己就没责任了,但很多事情,在开始的时候是谁也不知道的,应该大家在一条船上同舟共济,这就是“接力跑”和“踢足球”在交棒/传球之后的区别;

实施过程中

【做了一半改需求】,scrum里的表现就是sprint内的非受迫需求变更,大家很难忍受的是产品经理自己没想清楚,而导致的劳动浪费,俗话说“没有变更就没有伤害”,碰到性子烈的就直接要干架了,当然,如果是外部市场变了,大家都可以理解;

【开发过程中消失】,你可以出差、可以开会,但是要能及时响应技术的问题,要不然,为了进度大家照着自己的想法做下去,验收的时候产品经理跑出来说“这不是我要的”,可不要怪没人理你;

【过度关注实现细节】,帮技术决定技术方案,也是技术出身的产品经理容易犯的错,越俎代庖了,会降低技术同学的积极性,渐渐的就完全打工心态了;

产品发布之后

【发布后没有反馈】,技术人员也需要从市场、用户那里获得反馈,从而知道自己做的事情产生了价值,提升成就感,做完发布,石沉大海,大家是不可能有owner感的;

【无节奏感】,让技术人员忙一阵闲一阵,发布之后再忙着研究接下来做什么,让技术人员在干死干活的高强度之后突然不知道做什么,几天后又开始要赶进度;

全过程都有

【优柔寡断无决断】,是产品经理最要不得的品质,就是在已经讨论完毕后,大家都等着你拍板的时候“你说吧,往哪儿走我们就跟着办”,这时候你说“啊,那个,各种方案各有利弊啊,我也不知道怎么办啊,你们有什么好想法……”,你就完蛋了;

【报喜不报忧】,产品经理总想藏着掖着一些信息,比如“老板在考虑干掉这个项目”这类信息,出发点可能是好的,但,当大家通过其他途径知道了以后,互信就完全打破了,大家会觉得“你还是把我们当资源”;


还有啥,欢迎补充。


———— 2019年更新 ————

那么到底怎么做产品呢,2019年我和极客时间合作了一门产品创新课程,欢迎来试听

:)

我只说ios平台上的。

1,把按钮往上挪一下,编译一个我看看。编译一个200多个文件的需要3分钟的东西只为了看一个按钮。请找美工挪挪,量出具体距离。这是工程,不是美工。

2,你试试下看看这种方式行不行。拜托,如果每个功能要试试多种方式的话,要产品经理干嘛呢。少量的修改是可以的,或者产品升级的时候是可以的,但是产品开发不是试出来的。

3,这个效果我不是我想要的,你换个。交互不写,也不交流,等coder帮你想好,你真的是领导,只有想法吗。请时刻注意,你不想好的话,自己都不知道要做成什么东西,怎么叫做产品。

4,美工图不就足够了。其实它真的不是一个体力活,虽然ui是有少部分的调整,但是交互,工程图更重要。工程思想真的很重要。

5,这个code应该这么写。请问你是coder吗。你来写吧。你不是coder,coder也不做pm,分工真的要注重,不要过度干涉你的工程师同伴们。

6,这次审批没呀有通过呀,违法了苹果的人机交互设计。我们重新设计一下吧。coder看文档,pm看交互,如果coder把这些东西都做了。你们要下岗的。

7,这个我们修改一下,明天提交新的版本,一看,列了一大堆增加的功能,并不是仅仅是修改。coder真的不是神,增加的功能是需要测试的。pm给自己留时间同时,可怜可怜攻城湿,留点时间思考吧。

8,运营说这个功能非常重要,要马上增加。功能上线。一月后,运营过来发飙。你的做得功能挡到用户的视线了,这个功能我们不要。产品需要成就感,coder也需要,老做一些没有经过验证很傻的东西会很伤心的。

我虽然偏激,但是还是有一些观点应该有助大家参考参考。欢迎大家指正。