产品经理是不是程序员的领导?

2020-05-21 10:31:11 +08:00
 NakeSnail

最近几年感觉比较明显,虽然名义上是上下游,但是感觉现在很多产品经理在实际交流中都是把开发当成他下属的开发团队。

10860 次点击
所在节点    职场话题
87 条回复
crazybinggan
2020-05-21 10:53:39 +08:00
不是,明显开发团队头头不够强势,我之前团队怼到产品没话说直接反转他们的需求...后面都是拿数据来提需求了。
更多的是合作关系,我们也可以给产品提意见,更多看团队磨合。
wyz123723
2020-05-21 10:55:46 +08:00
不是, 主要开团队领导强不强势, 像我们领导, 总喜欢和稀泥, 胳膊肘往外拐
RomeoHong
2020-05-21 10:56:33 +08:00
有的产品经理还真把自己当经理了
zgl263885
2020-05-21 11:11:39 +08:00
已经把产品怼的不敢说话了。
主要是太菜,基本功没有,不会思考,拍脑袋做决定。比如从一个对象列表里选一个对象作为表单的一个参数,他们给的要求是吧对象(有名称)列表显示成表格,而不是下意识的下拉列表。类似的想法太多了。就像是上班大家通常都是开车公交车自行车走路等,他们却指定开黑鹰直升机。
越想越来气,菜就态度好点,多听听别人意见,真以为产品经理就是高人一等了?你做的好,我可以听你的,你做不好,劳资还惯着你不成?
x86
2020-05-21 11:14:04 +08:00
坦白说混子职位(起码 90%吧),啥都不懂用几个软件写写体验就以为啥都懂了并自我感觉良好的那种
2232588429
2020-05-21 11:15:14 +08:00
大多数产品其实并不是什么经理,只是专员,对外说得好听都管这个职位叫经理,怎么可能真的是经理呢?如果技术原理都不懂一点,纯靠拍脑袋来,这样的产品在工作中毫无价值,就是个传声筒罢了。
cmdOptionKana
2020-05-21 11:15:25 +08:00
严格来说,让产品经理主导产品设计,让程序员当“将军”和“战士”的角色,尽量去满足需求,这样是最健康的,但是对产品经理的要求比较高。

另一种健康的方式是,让程序员的头头做主导,让产品经理做一个“军事”的角色,收集需求分析需求、提出各种创意,然后由程序员头头来最终拍板,但是这样对程序员头头的要求也会比较高。
cmdOptionKana
2020-05-21 11:16:02 +08:00
“军师”
tomczhen
2020-05-21 11:16:52 +08:00
程序员和产品经理都有菜的,说白了大多数情况下就是互相看不起,连良好的平等对待都做不到还谈什么交流合作。

更不要说很多小公司还真是领导和老板直接负责产品经理的职责。
pengjay
2020-05-21 11:42:43 +08:00
看团队,是技术主导还是产品主导。
evill
2020-05-21 11:48:31 +08:00
有的产品经理把自己真的当经理了
当你经历过数据驱动的时候,就知道产品出错需求 KPI 没了,然后他们就不会指手画脚了
xuwei0056
2020-05-21 11:57:11 +08:00
在我们公司是这样的,起码工资结构是。产品的工资比开发高的多
wienli
2020-05-21 11:57:55 +08:00
是个锤子,直接开怼,都是第一次做人凭啥我让着你
tsuijinglei
2020-05-21 12:10:00 +08:00
产品经理不是领导,产品经理应该是很具备说服力的 同级 /同事 /合作者。
jimmy2010
2020-05-21 12:13:05 +08:00
这时候不应该说一句:产品当如张小龙?
em70
2020-05-21 12:17:13 +08:00
如果不是领导,根本没法驱动程序员工作,除非还有一个 leader 一起工作
ctOS1H
2020-05-21 12:17:41 +08:00
日常围观产品和开发吵架
hanbing135
2020-05-21 12:21:09 +08:00
没有比程序员更低的职位了吧
maduoduo
2020-05-21 12:21:36 +08:00
项目经理 负责项目的进展,更像是项目成员里面的领导,产品经理算不上,产品经理只能算项目的一步,和开发人员、测试等属于差不多的
libook
2020-05-21 12:28:26 +08:00
产品给技术提需求的时候,技术要进行评审,对需求的合理性、可行性做出评估,有问题的话技术可以提出异议,以通过需求评审作为分水岭,通过前是产品经理的责任,通过后就是技术的责任。如果产品经理忽略技术的异议,那么可以使用邮件手段,来把相应问题、风险发送给对方,并抄送领导,已经正式声明有异议的这部分将来风险发生了就是由产品经理负责。

一个需求通过需求评审之后,必须冻结,以正式邮件申明需求文档和冻结状态,此时产品经理承诺不对需求做更改,技术承诺研发周期。如果产品需要变更需求,走需求变更流程,发正式邮件说明变更原因,技术重新评估研发周期,项目经理评估项目安排影响,由对应产品对相关损失负责,如扣绩效。若技术不能依照承诺时间完成开发,技术承担相应责任,如扣绩效。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/673895

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX