你们不觉得产品经理这活，应该由程序员自己亲自干吗？

[sdjl]

现实情况

1. 产品经理做好原型图 -> 设计师画出高保真设计图 -> 程序员说“这不合理”
2. 通过团队合作，产品经理看似加快了项目进度，但后期许多本可以避免的沟通又消耗了大量的时间

是不是？对不对？合不合？

程序员就应该自己去画原型图啊！

我觉得合理的模式是：

1. 程序员去理解业务需求，在理解业务的时候就能构思出解决方案、数据库设计、原型设计
2. 在设计原型图时，程序员就知道能不能实现，实现难度有多高，怎么实现
3. 程序员画出原型图，交给设计师画出高保真设计图
4. 程序员拿着自己的产品，自己写，避免了大量的没必要的沟通

所以，我认为产品经理和程序员，应该就是同一个人或同一个团队！

什么？程序员只会写程序不会做产品？

1. 有些人觉得，产品有产品的丰富经验，程序员不一定会做产品
2. 瞎说，都会写程序了，还不会做产品？
3. 做产品需要丰富的经验啊，要懂心理学，要懂消费行为学，程序员懂吗？
4. 瞎说，我都会写程序了，我还不懂这点心理学和消费行为学？
5. 做产品要会用产品经理的工具啊，这么多工具你学过吗？
6. 瞎说，我直接写代码就好了，你那个工具不就是你不会写代码才学的么

[liprais]

你以为是奴役你的，其实是保护你的

[hefish]

有一些产品经理，是程序员转岗来的。
也有一些产品经理是自我学习来的。
这个原则上，程序员转岗来的，提的需求相对会实际一些；
自我学习来的产品经理，如果愿意学习，愿意了解产品开发的流程和一些细节，那提的需求也会实际一些。

[tony1016]

不行，一个人不能有当裁判，又当运动员，不为别的，人是懒惰的动物

[a302800411]

前提是非常有责任心，站在对用户负责的那一趴。

而不是怎么开发简单怎么来。

还有和客户（用户）沟通是很浪费时间的，但人的精力又是有限的

[hheng101]

一些 2b 产品，确实是程序员自己画原型的

[edinina]

用过一些程序员独立做的产品，太程序员了

[ufan0]

对你所在公司的体量比较感兴趣，我对帖子内容是持否定态度的。

首先假设本文讨论的程序员均为能力很强责任心很重的人。

1. 程序员干了产品经理的活儿，工作效率会大打折扣，无需展开叙述了；
2. 业务和技术之间存在有壁垒，不是所有业务场景都很好理解，就比如金融行业的，银行保险证券，就算你二十年开发经验，没做过这行的话来参与开发主链路都已经不容易了，还干产品？业务直接投诉到公司经理部门了！
3. 公司规模大的话，一个程序员，非常难通晓全公司业务逻辑，但是作为产品是需要通晓全公司业务体系架构的；如果不知道，那就只能被挑战了。
4. PD 不仅仅只是负责拆解业务需求，还有对业务需求的考量。

对于本文提到的“合理的模式”，在我看来，说白了就是遇见了一些非常差的 PD 同事，所得出的结果。

专业的人干专业的事，公司老板也不傻。

[1252603486]

很喜欢陈皓的这篇文章
https://coolshell.cn/articles/4951.html
许多公司认可 X 理论
X 理论参见
https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y
按道理产品经理这个职位的出现会降低程序员和别人沟通打交道的能力，而且让程序员放弃思考最原始的问题，因为从产品经理过来的信息已经是第二手了。
对于公司来说，分拆之后看样子可以提高公司的开发效率，产品快速出原型和需求文档，程序员按照需求来做，但是长久来说对公司的产品很不好，不过呢，国内的大氛围是偏向于快，不可能思考那么多，这就造成了如今的局面。

[Vegetable]

你这种认识，和产品经历拿着需求问你”这不是很简单吗？“有什么区别？

你觉得产品工作简单，程序员也能做，只是基于你认识的所谓产品工作。确实有很多产品的水平一般，整体素质不如对接的开发而被鄙视。但产品本身和开发面对的层次并不一致，想要同时做好这两份工作，或者说找到能做到这点的人，比找到胜任单一层次的人才更难。

程序员之间的差别也往往也比程序员与产品之间的差别大。

[liveoppo]

产品经理有很多费心的事，像功能的取舍，版本的控制，都要耗时间去规划，去跟客户、老板、开发团体反复协调，最终还得兜底承担产品失败的主要责任。

作为产品的总责任人，也是产品的灵魂，产品经理并不简单。

[GeruzoniAnsasu]

有些人觉得，产品有产品的丰富经验，程序员不一定会做产品
瞎说，都会写程序了，还不会做产品？
你虽然会写程序，但你不明白我们的用户为什么就是必须得要那样一个功能
做产品需要丰富的经验啊，要懂心理学，要懂消费行为学，程序员懂吗？
瞎说，我都会写程序了，我还不懂这点心理学和消费行为学？
「我都会写程序了，还搞不懂怎么治理国家？」 —— 是的，你会写程序跟治国理政和心理学都一样没什么关系
做产品要会用产品经理的工具啊，这么多工具你学过吗？
瞎说，我直接写代码就好了，你那个工具不就是你不会写代码才学的么
不，我是为了能让设计师、甲方、程序员、产品总监、售前支持、其它产品经理等一大群人都能看到同样的 preview 才用这些工具的。



我觉得合理的模式是开除程序员，让产品经理学会写代码，你觉得呢？

[kongyiji]

商务其实也是，程序员自己亲自去谈就好了，反正也更了解技术背景。🐶

[zhhqiang]

要不工资程序员发吧 🐶

[fox]

我觉得楼主的理论如果说得通，假设说得通的话，应该是开除程序员，让产品经理学会写代码

[blaaibla]

这个出发点是技术可行性和开发节奏可以得到保障，其他方面也考虑一下就更好。体验好不好？用户会不会不好上手和高效率使用？ 友好高效的交互是开发前期就应该有保障才好，不然开发了也会效果不够好。
我个人觉得最佳的方式就是设计投入的时间越多，开发投入的时间就越少。我现在能做到设计方案用一个月来设计，但开发只用一天来开发，效果还可以。

总体来说，简化沟通和衔接的流程和投入的人员的方向肯定是对的，因为这样更高效，但对应的人员的要求也越高。

[NessajCN]

产品跟程序的关系，是一种「创作」和「执行」的关系
类比的话，其实是「作曲家」对比「演奏家」，或者「作家」对比「打字员」，「导演」对比「演员」
前者通过灵感、创意和经验构想出作品，后者将前者的创意创作展现出来。
这两种角色有各自特点：
前者似乎是个人都能担任，而后者则需要大量训练
但事实上只有那最顶尖的一小撮天赋选手才能真正创作出优秀的作品，
譬如作曲，不就是把音符、和弦拼一拼嘛，写作不就是讲故事嘛，谁不会似的。
但只有真正尝试过自己去作曲、写作，才能知道要干好这工作真不是一般人能行的。
特别是有很多执行者，特别容易产生「我干嘛要听那些就知道指指点点的人的话，我上我也行」的错觉
譬如弹钢琴弹得好了就觉得能作曲了，演戏演得好了就想导演了
不排除的确有两种角色都扮演得好的人，但必须指出大部分执行者都是没那个天分当创作者的。

回到产品上来，你程序员要当产品，那当然没问题，的确是个人都能当。
但你要是因此轻视这个职业，那只能说还是对这两项工作的本质了解得不够深入。
「做得出」跟「做得好」完全是两码事。
对一项软件产品来说，产品的重要性远高于程序，
宫本茂并不会写程序，但只有他是马里奥之父，而非那些程序员或美工。

比较可惜的是，国内很多人，甚至很多大厂，都没认识到产品的重要性。所以要不就只会抄，要不就做得一坨 X

[freeminder]

别的不说，就这个**亲自**，看着真别扭呀

[nzbin]

微信不就是吗？真正的产品经理只有张小龙，其他都是助理

[NoOneNoBody]

程序员就应该自己去画原型图啊！
-------------------
这就不是团队了，更像是个人项目
你可以说程序员有很多人啊，怎么是个人呢？
没有分工，一个岗位完成大部分的工种，就是个人项目的方式，此题起码产品经理可以裁了，因为程序员已经理解了业务需求，不是么？

其实这里所有问号，加一个步骤就可以了，做原型图前，整个团队做一次宏观沟通，宏观说的是不以具体细节肯定或否定全盘，只将业务流程理顺，找出预计难点或瓶颈，这样有利于下一步的分工安排，以及和客户的交涉

[gps949]

话说，连程序员本身都分为研发、测试、前端、后端、算法、大数据、AI 、数据库、客户端、移动端……一堆工种。
我依然觉得经济全球化、社会化大分工这两个我中学时课本上讲的趋势没有问题，虽然现在有标榜“全栈”“DevOps”“DevSecOps”之类乱七八糟的东西。
就和知识本身的发展史一样，现在的知识丰度，再出现亚里士多德那样的“杂学”“博学”家，可能性已经为 0 了。
不排除顶端杰出的人才还能把计算机、电子、网络、通信、自动化范畴的事情单兵搞定，也不排除个人项目也可以一个人一把抓，但岗位职能细化才是发展趋势。一个人当三五个人用，是小作坊和垃圾公司的做法。

[hlwjia]

当然可以；不过你要不要问问程序员是否愿意和老板、客户、市场 /销售 /设计同事沟通，还是就写写代码好了。

我觉得大多数的程序员还是挺乐意光写代码的。

[jamosLi]

有没有可能产品经理需要懂技术是必要条件而不只是需求收集器？

[estk]

难怪失业率攀高，原来是产品经理岗位被砍了

[wusheng0]

没产品真的很痛苦。

[taresky]

认识一些产品经理都是独立开发者的水平。

各自职业发展的路线不同，真不一定哪条更好，自己取舍就行了。

不过从标题可以猜测，LZ 当前团队的分工和合作不太行。建议要么你去看看更好的团队，要么你扛起这个责任定义清晰工作规范（如果大家都信任你的话）。

[estk]

“我觉得公司不需要老板，我都会写代码了，难道还不会赚钱给自己发工资？要老板干嘛，公司的收入都是我代码的贡献”
“我觉得公司不需运营，我都会写代码了，难道还不会懂得兜售产品的亮点？”

[terrytw]

所以说国内程序员大部分是草台班子
但凡有点质量体系概念的人都不会说出这个话来
产品是设计输入
程序员是设计开发
测试是设计验证
三者不能兼任，二战期间管炸弹质量的思路，延续到现在总结出来的基本原理，不要去对抗

[terrytw]

简单读一下 ISO 9001 ，IEC 12207 ，很多问题都可以得到解答

[sdjl]

我是楼主，我补充一下。

我是这样想的，程序员团队应该自己做产品设计，自己画原型图，程序开发时自己写自己的部分。

程序员团队一起做好产品，一起沟通如何分工，这样大家都知道产品做出来是什么样子的，减少了沟通。

程序员团队在开会沟通的时候，他们就知道产品开发起来合不合理，困不困难，如果产品这样设计对后期会有什么影响，数据库如何设计，如果甲方提出修改要求现有数据库是否能满足变动，程序员自己了解。

[sdjl]

@tony1016 人是懒惰的动物 这句话有一定的道理，有人互相监督有时候是必要的。

我说的情况是在这个人本身就是积极地情况下

[sdjl]

@a302800411 当然是站在设计合理，把项目做好（而不是完成工作）的角度

你说的这一点，可能是现实工作中真正的难题，许多程序员只是想要把工作完成下班，而不是把事情做好。

[sdjl]

@Vegetable “想要同时做好这两份工作，或者说找到能做到这点的人，比找到胜任单一层次的人才更难。”

你说的胜任两种工作的人才不好找，这是事实，但不表示这种工作方式不合理。

[sdjl]

@liveoppo “产品经理有很多费心的事，像功能的取舍，版本的控制，都要耗时间去规划，去跟客户、老板、开发团体反复协调，”

现实的情况不就是，程序员觉得产品设计需要修改，所以产品经理需要反反复复的去和甲方协调么

[zongren]

程序员觉得不合理没有用，程序员应该只负责实现

[sdjl]

@NessajCN

“产品跟程序的关系，是一种「创作」和「执行」的关系，类比的话，其实是「作曲家」对比「演奏家」，或者「作家」对比「打字员」，「导演」对比「演员」”


不认可此观点，我觉得好的演员可以当导演，好的演奏家可以自己作曲，好的程序员就应该自己做产品

[sdjl]

@NoOneNoBody “这就不是团队了，更像是个人项目”

有分工的，程序员团队内部有分工，只是产品大家一起做，要么自己做自己的部分（产品设计），或者大家一起开会，少数有经验的人来做产品。

[LaGeNanRen]

你要这么想你真的太不适合创业了，业务往来 90%都是屁话，销售不当真，老板不当真，产品不当真，但程序员一定当真。特别是 tog 的项目，你以为人家说的云里雾里多高的并发多新的技术，其实实际上线之后只有领导来的时候才会装门面用一用，如果让程序员去做对接去接需求，那指不定整出啥花活儿来

[nuII]

挺好的，老板就喜欢你这样的，1 个人干 2 份活，和开发负责人、需求方以及老板互相掰头，只需要付开发的钱，赚翻了

[ww940521]

要有人背锅的兄弟。

[dudubaba]

to b 的可以，to c 的不行，因为产品经理要花大量时间去调研竞品，然后把相关功能整理出来抄出来，然后还得调研这个产品未来会不会赚钱。这个过程是有很大的沟通成本的，就是磨嘴皮说服别人的过程，老板不会信程序员的嘴的，因为某个需求实现不了时潜意思的认为程序员懒不做。

[erwin985211]

37 岁的老程序员了，怎么跟 17 岁的一样。产品只是画原型的是吧。

[sdjl]

@hlwjia “你要不要问问程序员是否愿意和老板、客户、市场 /销售 /设计同事沟通，还是就写写代码好了。”

所有的前提都是：更高效的把事情做好，不能说程序员不愿意就觉得这种做法不合理。

[nothingistrue]

只画原型图的产品经理，是画图经理，不是产品经理，此帖就在这里终结吧。

[sdjl]

@dudubaba “to b 的可以，to c 的不行”

恩，我说的很多问题确实出在 to b 项目中。

[Felldeadbird]

产品经理不能让程序员当，反之亦然。

但是这个这两个岗位可以从各自工作经验转岗而来。

我公司没产品经理，所以我就成了开发和产品经理。这样会带来一个很恶劣的情况：我日常接到需求，我做的开发只能凭空去揣摩提出需求的人的想法。

典型的例子：公司有一个采购模块。老板提出来后，采购人员没想法，仓库人员没想法，老板只有需求的想法，其他不管。 我就只能去找网上相似产品去做。经过一番开发后，用的人觉得难用，开发过程自己也难受。到最后连反馈都没有。

每每出现这种情况，我就想如果有个产品经理，我都不用去自己苦恼这些了。他给我制定好方向，我执行就可以。

[chenrui920614]

写程序和懂心理学、消费心里有什么关系

[konakona]

程序员可以转行当产品经理，但不能产品经理负责写代码。

[justfindu]

是的, 但是又不是, 产品经理其实还有其他要做, 但是傻逼产品经理的确不如程序员自己搞.

[hjw45611]

😎: 我觉得老板这活也该由我干

[whyiyhw]

程序员跟产品是一体两面，早期的程序员都是，跟人打交道，理清业务然后对现实场景进行建模，设计数据结构，用程序去模拟现实，后续随着大规模生产需要，分工细化，就分出了产品这一个岗位。 有能力二合一的人，是不甘心打工的，搭配点销售，营销的工作，一个人就是一个公司。
@sdjl

[sdjl]

补充一下，我确实经常自己做产品自己写程序，所以我才会来发这个贴。

但是发帖的目的是为了讨论这个问题，不是讨论我的情况，所以建议大家围绕问题讨论，不要议论楼主~

[sdjl]

@whyiyhw “有能力二合一的人，是不甘心打工的，搭配点销售，营销的工作，一个人就是一个公司。”

这点同意的，看来当今社会复合型人才不好找。

[lanlanye]

我支持什么都干，产品运营开发运维推广销售这些都可以自己做，老板也自己当，因为做好这些有一个共同的前提，就是对你做的事有充分的认识，职责分到多个人身上之后，沟通成本会显著提高，如果每个人对所处领域的认识有差异，就会出现问题。
然而从企业的角度来看，打造流水线，让每个人可以在细分领域不断深入，只做一件事无疑是更有效率的。

[losephsky]

不行，大多数程序员沟通协调能力不如产品经理

[szkoda]

最好那段问答真是太偏激了，对产品经理这个职位毫无尊重，建议发到即刻或者产品经理的圈子里接受下洗礼

[AlvaMu]

@sdjl #32 合理与否不是光靠说的,也不是"存在即合理". 如果是个人作品或者小公司的产品,使用这种方式完全没问题,而且大多数的初创公司的产品也都是通过这种方式做出来的,但是当一个产品的规模到达一个体量的时候,这种模式是否还合理呢? 在产品设计的同时,能否兼顾日常版本的迭代与维护? 产品调研市场的时候,能否一边调研一边改 bug? 这也是工作管理中最基础的分工与协作,专业的事情交给专业的人去做,市场中,效率最重要

[sdjl]

@lanlanye “然而从企业的角度来看，打造流水线，让每个人可以在细分领域不断深入，只做一件事无疑是更有效率的。”

你点出了个人利益和企业利益点的不同之处，许多企业老板在乎的是容易招到人和稳定的流水线。

如果企业换一种思路，培养复合型人才，等人才培养出来了，他们就自己出去单干了。

所以问题出在：利益的分配关系决定了工作方式？

[buchikoma]

不知道 op 是做什么方向的 rd ，作为 2b 行业的程序员，如果说你让我做产品的工作我肯定能做，但问我愿不愿意同事做产品和研发，那我肯定不愿意，至于为什么呢。
产品一般不会只负责一个小模块，而是一到两个产品线，在此基础上，跟设计、售前、商务、客户、运营以及其他业务线产品打交道。对于一个产品线来说，就是需要一个统筹全局的人去协调资源，确定排期，确定业务模型，可能这个人他不如研发了解代码，但缺了这个人，让研发去对接负责这些工作只会更乱套扯皮。

[yangxii]

@freeminder 亲自指挥，亲自部署有问题吗 XD

[Leonard]

还是有产品经理好一点，可以把不合理的需求挡下来。做过没产品经理的产品，老板啥都想要，天天想一出是一出

[sdjl]

@AlvaMu “ 在产品设计的同时,能否兼顾日常版本的迭代与维护? 产品调研市场的时候,能否一边调研一边改 bug? ”

你说的“不能一边 XX 一边 XX”的问题在我看来并不成立，如果你假设项目有 3 个产品+3 个程序员，那我的方案是假设有 6 个程序员。

[la2la]

合理的规划甚至比高性能的编程更为重要

[7gugu]

不觉得，跟运营跟老板扯皮就够喝一壶的了，根本不想做庞大系统下的产品

[wonderfulcxm]

没有产品经理，我直接对接老板，额，我就是产品经理…

你是不知道有些外行是多外行，经常发明一些让人摸不着头脑的名词，比如要在网站导航栏加一个项目，他管那个导航栏叫置顶。把搜索页叫做标签页。

有问题的时候也不发网站 URL ，老发截图，我还得自己找 URL ，截图就截图吧，还是是 printscr 全屏截图那种，偶尔用 QQ 内置的截图功能，也不会用快捷键，只会用鼠标点截图的按钮。图发过来半天不说话，让我只能猜猜他想干嘛…

[AlvaMu]

@sdjl #61 所以也是我说的 产品的体量不够,这么做没问题

[fengfisher3]

一句话：太年轻（太片面）。
但你可以尝试自己去做产品，自己设计（借助 AI 画图），再自己写程序。做全能独立开发者。

[sdjl]

这个帖子让我想起了一个游戏：《星露谷物语》

[sdjl]

@fengfisher3 我正在往这条路发展，话说有“原型图 -> 设计图”的 AI 吗？

[dann73580]

很多技术出身的人是有知见障的，技术背景会阻拦对普通用户的洞察。所以需要一个产品经理是也正常。为什么有些产品经理不行，那是另一个问题了。

[zhouweiluan]

可能这一点只局限于 OP 和极小部份人，能拥有产品的思维和能力，独自就能把产品做的很好。
但是这不是我即世界啊，大部份程序员估计都做不到这一点，硬上的结果就是做出的产品非常的「面向程序员而设计」，无法面向大众。
万年欠揍老句：存在即合理。如果每个程序员都能独自把产品做好，产品经理这个岗位早就消失了。

[wanwaneryide]

有个话我觉得还是挺对的：不要拿你的业余爱好和别人的专业比。能做和做的好，能用和好用差别还是挺大的。产品调研、需求沟通、确认这些环节建议楼主自己去体验下，看看需要多少时间。

[est]

之前我也不明白，后来我明白这道理了

简单的说就是市场的错配

美国搞产品经理、搞咨询公司，前提有一个——别人是真的能拿得出来 business 案例，知道怎么挣钱，对用户心机了如指掌，知道如何营销和讨好用户。这样的人来做 PM 我觉得真没啥问题，毕竟别人 PM 是拿来吃饭的。PM 不靠谱早被干掉了。

但是国内很多煤老板和乡镇企业家东施效颦，也设置平行岗位引进了这一角色，我承认国内也有很多出色的能力很强的 PM ，但是大多数岗位上的人就是纯混子。。。。

[NoOneNoBody]

@sdjl #36
一级分工和二级、N 级分工是有区别的，我觉得你模糊了它们，没分清楚

例如一级分工主管业务的，还有二级分工售前和售后，你理解的产品经理只是售前部分里面的设计岗位，但售前还有和客户沟通的岗位，只不过小公司多数是兼任而已。程序员直接替代售前、售后的话，我预料会得罪很多人

[xiaojun1994]

《你们不觉得测试这活，应该由程序员自己亲自干吗？》

[exmario]

说明你不了解产品经理，一个游戏的产品经理，程序员可以兼任吗？又做裁判又做运动员

最后只会出现最容易实现的产品，而不是最好的产品

[est]

技术岗能平行引进，因为就 tech company 赛道而言美国的市场需求和我国很类似。但是「商业」层面我国其实和美国差别太大。所以才让美国那一套 PM 行业方法论其实不太灵。国内的 PM 感觉也没搞出成套的知识体系和成长路径。最终这一岗位演变成中层和事佬角色。

[8355]

很多东西只是你以为的是你以为的
我前司产品被业务部门疯狂 diss 其实他很优秀 你的牛逼方案人家未必满意

做开发你能干的爽必然有人为你负重前行，可能是产品，可能是你的 leader
有些事故 bug 之类的都要有人去顶雷
你说东西都在你脑子里 你不画出来谁知道你想的是不是人家想要的呢

你天天跟业务部门过需求你还有时间写代码吗 你开会过需求干说不讲文档不画图不写 prd 不画原型你跟 ui 怎么对接 直接全栈开发是吧
你能做到业务部门 24 小时 oncall 第一时间回消息吗

[HancockXu]

产品经理由程序员干，产品就会充满了妥协与凑合

[hhjswf]

你们不觉得测试这活，应该由程序员自己亲自干吗？提交了 bug ，程序员认为不是 bug 再打回去，增加沟通成本。
每个人都不是全知全能，需要别人来补充。

[darkengine]

太小看人的惰性了，就我接触过和带过的同事来说，如果让他们决定产品的功能，出来的就只能是个 demo 。公司 /产品又不是自己的，能懒就懒。可能 OP 接触到的都是高素质层次的人才，那就不一样。

[zzzmh]

第一句话不认同，不是产品经理这个岗位降低的效率，是人和人沟通就会降低效率。只要一件事参与的人大于等于 2 人，就会需要沟通，人越多，沟通就越累。人性使然。举个例子，客户要五彩斑斓的黑，如果产品去沟通，理论上产品就需要洞察客户的真实需求，判断需求的可行性，转换成程序员和设计能理解的语言，增加沟通效率减少客户和开发之间代沟。如果你让程序员直接和客户谈，鸡同鸭讲，客户说客户的，程序员说程序员的，最后很可能程序员会直接来一句这也实现不了，那也实现不了。那客户黄一次，黄 2 次，第三次程序员就黄了。换个角度，假如程序员是一个双商都高的人，既能沟通也能开发，那是捡到宝了，只不过这样的人会十分罕见，价格也会十分昂贵。

[fiypig]

我还是喜欢拿着产品的原型做事， 这样省去一些麻烦的，怕扯不清
关于测试要程序员来做这事，开发做好功能的确要测试的，然后在走到测试人员去测试功能，测试人员说是 bug ，如果开发说不是 bug 的话，那其中一个人肯定功能理解错了。

[LiubaiQ]

哎，其实是大部分开发都没有合作过高水平的 PM ，然后就产生了 PM 只会起反作用的印象。。。点名夸奖杭州很多公司，确实很多 PM 都是这吊样。。。但不能否认有高水平的啊。。。

之前还在外企工作的时候，那跟 PM 共事，真是合作愉快，顺畅无比，一个做了小十年的项目，功能巨 tm 多（ asp 项目，120w 行代码。。。），老开发都记不住哪块有啥，文档写百十页，但人 PM 就是能整明白，出新功能，或者迁移、分离老功能，就是稳得一批，夸张一点说，kick off 大会上开发连脑子都不用带，直接照着需求文档实现就行，啥都给你列好。

当然可能跟工期充裕也有关系😅俩月一次迭代，经常半个月干完活，剩下半个月：摸鱼+优化+code review 。。。，最后一个月给 QA 、PM 、I18A 啥的做点支持、沟通的工作。。。哎怀念啊。。。

[LiubaiQ]

@LiubaiQ 补充一点，QA 也有很 nb 的，就是相对 nb 的开发来说比例少得可怜。。。

[oakcdrom]

拉倒吧，大部分研发只负责功能实现，哪有在乎用户体验的。。。

[lykhero]

你肯定没干过产品类的活， 绝对把你恶心死。。无数的会，无数的无效沟通。
你说唾弃的是那些完全不懂技术的产品，或者说那些自以为是，不去学习或者请教技术的人，这种人在某国大有人在罢了

[lykhero]

@LiubaiQ 老哥那你当年为什么出走了啊？？？？

[xhcarlin]

其实也可以参考一下大多数独立开发的产品

[Yuicon]

分开很正常 事情太多管不过来 我不爽的是开发地位太低 产品可以领导你 测试也可以领导你 开发就是干苦力的 还要加班干 完了还要整一堆绩效管理开发 生怕你摸鱼

[iovekkk]

你其实只看到了产品经理与开发有交集的地方
其实这只是产品经理本职工作的一小部分
从考核指标来看，产品经理是直接看数据结果的
一个需求上线后，有没有获得目标数据，比如下单转化量，注册转化量，或者其他什么数据
这些东西如果需要开发来负责，开发肯定头都要大了

[nekoneko]

给我 double 钱我可以都给你干, 可惜资本家甚至只想给 half 钱让我干 double 工作

[LiubaiQ]

@lykhero #87 还是因为钱啊。。。二线钱太少了

[nebkad]

你们不觉得组织劳动这活，应该由劳动人民自己亲自干吗？

[iovekkk]

或者我们再换一个角度来看问题
假如你们是一个电商公司，做了一个电商产品
开发加班加点做了一个新功能出来，本来是指望这个功能能够吸引用户下单，提升下单量，提升交易额的
但是新功能出来以后，下单量没有上升甚至还有下降
这个时候，老版怒了，来找开发兴师问罪，如果你是开发你会不会觉得冤屈？
我功能做出来了，又没有出 bug 。用户不下单关我什么事？
你是开发的话，你一定是这么想的吧？
如果你这么想的话，那么如果新功能出来以后，下单量提升了，达到了预期，你会觉得这功劳全是开发的吗？

[Worldispow]

先把你现在手头开发的功能，写一个 20 页的 ppt ，再分别写 400 页左右的可行性研究、需求设计、详细设计，把这几个文档拿出来再说，不然谁都会 bb 。

[BMAO]

远古时期的确是这样，但是现在的产品和系统越来越复杂，你一个人要搞多久？按你的想法，汽车设计师或者汽车制造不分工每个人啥都干。福特当年就不会占领市场了。我看你的描述，好像少了个环节，叫需求评审，这个是可以技术参与一起讨论方案的。

[MiaoLei911]

小厂思维吧，一般产品经理牵头带一个项目，与其并进的可能有项目经理，其次任务下发到运维、开发、美工等，虽说有技术思维的产品经理开发起来很愉悦但这不是老板该考虑的事情，我们的职责就是尽可能实现需求，各司其职吧。

[0o0O0o0O0o]

站内开发者经常发自己的作品啊，你看看有几个能赚钱的...

[OpenJdk]

应该，但是老板不给钱和时间。

[wangxiaoaer]

我理解楼主，有些没有技术背景的产品经理输出的设计没有逻辑，不成体系，最终流于形式，实际实施中还是要把开发人员推到甲方面前，并且甲方自己也不懂，各种天马行空的想法导致边开发边改，最后就觉得产品经理没啥价值。

我觉得最大的问题还是国内软件开发的模式还是太草率了，甲方乙方缺乏足够专业的人进行沟通，导致需求无法精准表达，最长听见的一句话就是“先做个东西出来给甲方看看，再来细化”。另外有些群体也看不到软件开发的工作量，晚上提需求，第二天上线的情况也着实不少。