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

[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 了。
不排除顶端杰出的人才还能把计算机、电子、网络、通信、自动化范畴的事情单兵搞定，也不排除个人项目也可以一个人一把抓，但岗位职能细化才是发展趋势。一个人当三五个人用，是小作坊和垃圾公司的做法。