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

[sdjl]

现实情况

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

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

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

我觉得合理的模式是：

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

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

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

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

[liyiming2002]

那老板也可以程序员做了。。。
从目标到实现，当只有一个工种甚至一个人的时候是效率最高的。但是生产力太低了。

[Inevitable]

事实如此,你有构思你自己可以去找人创业开发软件了

[ideacco]

做了很多年产品，说说最近的感受。
首先说一下我日常的工作：
1. 上午一般会跟销售团队开会，或者直接跟客户开会。开会前要准备好问题，做好会议纪要，难点是提问题。只有提出好问题，才能理解需求是什么，跟客户开完会要简单的梳理需求，整理出文档。
2. 然后跟交互设计师开会，看看之前的需求实现的细节是怎么样的，是否合理，如果不合理要提出修改意见，如果没问题则需要将审核通过的模块安排到开发计划中去。
3. 跟开发组的领导开会，问问如果要实现之前客户提出的需求，需不要技术预研。简单说一下思路，聊聊可行性和开发周期。
4. 细化客户提出的需求，根据技术那边提出的问题和实现方案，并且结合目前项目的领域模型进行基础的建模。完成更详细的文档。
5.如果有时间，可以找业务那边开会，聊聊客户提出的需求分析的情况，并给个时间和大概得报价。
6. 最终根据商务那边反馈，是做还是不做。如果要做，则跟交互和开发最开会，详细将文档。然后安排设计与预研计划

最后捋一下开发进度，看测试人员的测试报告。自己去测试一下新功能的效果。等等。

以上说的这还算是好的，是一个成熟项目的玩法。如果同时有几个不同的项目，有些还是绿地项目。
那就要先做市场分析、搞问卷调查、业务(专家)访谈，做用户画像、信息架构、领域设计等等等吧。

咱先不说你能不能做，就说你做这些事儿所消耗的时间，我自己反正非常吃力，要带着一起做才行，你说你一遍做产品一边写代码，时间不允许啊。

另外需求的粒度跟实现是正相关的，如果需求写的足够详细，那么真的可以节省很多人力。
比如我前段时间把需求文档丢给了 GPT ，并且对了测试平台的 API ，将一个测试工程师报的一周的写测试用例的时间，缩短到 4 小时（ GPT 根据需求完成测试用例，并且自动提交到测试平台+人工审核时间）

[ganbuliao]

程序员可以做产品 ，但是大部分程序员做不了产品
1. 大部分程序员没有产品思维
2. 部分程序员代码都写不明白 哪有时间梳理产品结构
3. 部分程序员只做产品其中的某一块功能 他们都不知道他们做的产品是什么
4. 产品不是只画原型图就可以的 做了产品就没有时间写代码了

[jdOY]

楼主应该是没有跟优秀的产品合作过，写代码最差还能有培训班培训一下，所以说产品经理的质量比码农还要混杂

[keymao]

产品经理是必须的，为什么必须的，因为庞大的业务系统，程序是没时间都去了解所有业务的，需要有人拆解给所有开发。

[stillyu]

产品经理画原型的时候，没有评审吗？

[HyperionX]

@ganbuliao 这是自己螺丝钉化了，本质不是程序员这个角色的问题

[est]

@ganbuliao 你说这些都不是什么很高的门槛。真正的门槛是老板是否放心把一个产品的前途赌在一个 PM 的设计上。

[ideacco]

@keymao 是的，要好多人一起才行呢。

[pppanda]

比较优势原理的话，程序员即使干的比产品好也不应该干产品的活

[wand]

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

[fish19901010]

举个很简单的例子，C 端更不必说，就单作为一个 B 端产品经理，你除了要设计这个系统之外，你还需要有运营思路，服务 SOP ，怎么安排组织架构和多部门协同，最后完成这个商业模式，在这条业务线上顺利的做大做强。
这样的产品经理，不会画图都可以，最核心的是业务经验和业务的感觉。

[qbox]

楼主应该是在小团队做政府或企事业单位的单子。
甲方表达能力有限，加上老板愿意投入的人员比例，很多这种项目驻场的人都是工程师去沟通。

[xiaowei7777]

我以前觉得产品经理这钱真好赚，后来发现他们跟业务打交道也很不容易。让一个程序员去沟通更不容易，资深程序员还可以。

[xuhui54]

真的当了这个产品负责人，你就会想又个产品专员或者主力角色。毕竟太多设计、版本控制、文档输出、需求确认及跟踪、产品规划、产品介绍的等活等着你，你如果陷入这里面哪就是产品经理了，很少有时间来进行代码开发。不过如果是小团队小产品那是可以兼任，公司也想省一份钱。

[wqzjk393]

产品经理很多工作是要写文档的，有些时候也是要和客户扯皮的，先问问自己能不能接受再说吧…

[marcong95]

回忆一下大学专业课的《软件工程》，似乎产品设计本来也确实是「软件工程师」的职责。只是现在大多数都只是顶着「软件工程师」 title 的「程序员」

[dfkjgklfdjg]

你现在吐槽的，都是当初需求会议时你放弃的。

[freeminder]

@yangxii 我感觉“亲自”一般隐含着赞许对方做了本不该他做的事情。OP 的说法中，自己是程序员角色的话，就是程序员说该“亲自做产品工作”，有点自负。自己如果是产品角色，就有点“您屈尊把我的事情干了吧”的自轻。如果是第三角色，那就无从判断什么工作和角色的相对位置，更谈不上“亲自”。
当然也不排除“亲自”现在大家都不觉得有这一层特殊意思，是我自己茴香豆的茴了也没准。