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

[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 的说法中，自己是程序员角色的话，就是程序员说该“亲自做产品工作”，有点自负。自己如果是产品角色，就有点“您屈尊把我的事情干了吧”的自轻。如果是第三角色，那就无从判断什么工作和角色的相对位置，更谈不上“亲自”。
当然也不排除“亲自”现在大家都不觉得有这一层特殊意思，是我自己茴香豆的茴了也没准。

[jones2000]

楼主可以自己试试， 试玩了再告诉我们结果。

[marktom]

产品 80%时间都是沟通，和不同的人扯皮，理解业务和核心需求

[encro]

你在说我吗？

写需求，画原型比产品和设计还快。。。

[encro]

@liveoppo

功能的取舍，版本的控制 一直是我这技术负责人来做的。。。

耗时间去规划，去跟客户、老板、开发团体反复协调 也是我啊

兜底承担产品失败的主要责任 这个老板自己背。。。

[cogear]

赞同，程序员应该关心业务，同样，产品应该也要懂技术。
我觉得我司目前就挺好，产品同事知道代码在哪（大部分情况下），与此同时，也有产品同事转开发岗位。

[yangxii]

@freeminder hahah 你说的没问题，我只是玩梗而已，你 Google 下“疫情防控是当前最重要的工作。我一直亲自指挥、亲自部署。” 是谁说的 XD

[azur]

遇到过难缠的客户，喝水的时间都没有。所以代码是自己生成的？

[frankies]

绝对不认同，好的产品经理会让程序员和产品的价值事半功倍。

[simo]

产品经理和程序员背的是同一口锅不？
流程上游有锅下来，会往下流的

[GeekGao]

“代码都是我们写的，还要 CEO 干啥玩意儿”

[janus77]

这是现代社会分工产生的结果，并不是说你认为的合理就是合理，社会如此发展就证明这样是合理的。
你得先证明你所说的方式能让社会发展更好，否则你所说的“我认为这样更合理”就是不可证伪。
要不你自己先表个率整个产品出来？

[fregie]

产品经理做好原型图 -> 设计师画出高保真设计图 -> 程序员说“这不合理”
一个合格的产品经理至少也要是半个程序员吧,要懂一些技术才行,要不就是浪费大家的时间.

[olaloong]

真以为产品的工作就是无脑提需求啊

[devfeng]

你所说的，是产品经理和程序员对接的这一部分工作，事实上产品经理还有许多工作不和程序员打交道，这些工作反而是更重要的。

[libook]

产品经理做原型的早期阶段就应该引入开发人员进行可行性评审了，可以在早期大方向基本确定的阶段避免这个方向本身不可行。可行性包括但不限于技术实现难度、成本、风险等。后续在完成原型设计，也需要下游各岗位进行评审，一方面排除风险，另一方面反馈综合成本给产品经理和项目经理来评估时间规划和 ROI ，到时候产品经理自己就知道哪些该修改甚至砍掉。

产品经理作为生产上游，应该提供完善的文档给设计师、开发人员、测试人员、销售人员、客服人员，不光是为了下游岗位可以高效完成工作，也能在一段时间之后为产品经理自己回溯产品设计提供支撑。最好的情况是产品经理仅提供文档，不需要进行任何附加沟通，下游就可以完成工作。

产品经理的工作和程序员的工作所需要掌握的能力和知识有较大差别。通常程序员是从技术实现的角度上来进行设计，并期望用户按照自己设计的使用方式去使用产品；而产品经理是从用户需求和业务目标的角度上来进行设计，会充分考虑用户心理和行为逻辑。
什么？有程序员做出了普通用户觉得好用的产品？那这个人一定是具备了一定的产品经理能力。

产品经理和程序员之间的问题是老生常谈了，实际上都是项目管理问题，基本都可以通过合理设计工作流程、完善对接机制、构建相关工作制度来解决。

当然见于产品经理这个职业并不存在“科班出身”的人，所以现实生活中产品经理的能力也是参差不齐，反正我从业近 10 年接触过的真正能干好产品经理本职工作的屈指可数。其他人没法很容易就能做好，我也不相信程序员就能更容易做好。

[ibiza]

产品经理跟程序员的知识体系要求是不一样的。PS：产品经理不是只是一个画原型图的。照你这么说，所有的建筑设计师都是多余的，工程队自己盖房子不就行了

[Jirajine]

没问题，你看大部分自由软件都是没有产品经理的，那 UX ，你觉得怎么样。

[glfpes]

程序员需要站在产品的角度思考，这个意识有没有，可以区分初级与中级程序员。

[hoopan]

产品经理：评估产品机会、定义要开发的产品，画原型图
开发人员：根据原型图开发具体的产品

两个岗位、两种工作职责、两种思维方式。最近看了点产品方面的书，知识体系并不比我们程序员小。

[fpure]

如果是我来设计用户界面，我只会想弄一个 CLI 应用，然后再搭配一套 DSL ，然而这对于普通用户。。。

[zhanziyang]

有一定道理，但是比较实际的做法是，让有开发经验的产品经理来做产品。所以合格的产品经理需要 both 开发和产品的能力。

[weaponc]

你说的啥都干那是老板的事，老板发钱给你是让你好好拿钱干你那份活的。
至于你觉得不行的地方，不合理的地方，那得靠沟通啊。你跟产品说你实现上有哪些难点，成本有多高，可不可以有另一种方法来实现。
自己都能干自己开公司去呗 - -

[levelworm]

我的看法是产品应该是程序员出身的人来做，但是一旦开始做了就要分开了。产品需要会一些编程，但是业务能力也要比较强。好的产品不好找。

[thinkershare]

我怀疑微软的产品经理就是程序员， 才写了那么多奇葩的程序。

[imsoso]

产品的主要作用是为了赚钱
你真以为天天跟你抠几个原型好玩啊？
你知道天天在老板面前挨骂的是谁吗？

[HL8]

在油管看过一个采访 av 导演的视频，
导演亲自上，很容易拍着拍着就软了。
导演指导演员，才能能把控整体节奏。pm 也是如此。

好的 PM 额外是老板与程序员之间的润滑剂。

点赞越多，我发这个视频链接的速度越快。

[fengfisher3]

@sdjl 这个没关注。

[DigitalG]

有程序员背景的产品经理比较好，但是不认同真的由程序去做产品经理（身兼两职）。至于为什么...我现在在的公司就是这样，有些时候确实沟通会更清晰，但是整个项目坐下来很痛苦，并且对个人来说很低效（当然，跟我们公司的组织架构也有些关系就是了）

[varzy]

我从不否认产品经理这个岗位的价值，可身边的产品经理们却总在亲自颠覆我的认知😅

[OneMan]

大部分程序员其实是工具人，干不了这个。

[zypy333]

小公司有些 toG 的需求定制类的活，还有些对逻辑和架构有要求的活，感觉有产品意识的开发可以代替，但是有些创意类的，c 端的，包括 sns ，游戏等等，特别是规模上来以后，真很难替代。

[adian]

遇见一位不懂程序的产品经理是这样的啊，就好像建筑设计师不懂物理规律，不懂得现有材料特质，能画出来，造不出来。
谁都知道产品经理的职能就是降低程序员和客户之间的沟通障碍，如果他的作用是增加沟通障碍呢，那就是他工作没有做好，不过，遇见一位既懂程序又能帮客户梳理需求的人，不太清楚这个能力对于大伙儿而言难不难

评论区很多人说的驴唇不对马嘴，明明是讨论遇见一位不懂程序的产品经理该怎么办，非要说什么产品经理是背锅的啊，程序员没有产品思维啊这种刻板印象，也许这适用于评论区他们的公司，但一定不适用于 op 的公司，所有的职位设计不都是为了降低沟通摩擦吗？而不是因为有这个职位，所以必须有这个职位。

最终原因还是因为大公司病吧

[libinglong9]

@edinina 只是那个程序员是那样，不是所有的程序员一个样

[shawnsh]

这么说吧，懂一些程序设计的产品是好产品。懂一些产品的程序员是好程序员。产品不靠谱，程序员就得返工。产品应该学会做减法。不是一直加功能，应该减功能。

[lanlanye]

@sdjl #57 我觉得 8 楼贴的文章里的观点非常好，我经常听到「不了解业务做不了好程序员」，「不懂一点开发做不了好产品」之类的说法，说明这些岗位的工作之间是存在交集的。

理想状态当然是每个人都对要做的事有充分的认知，然后大家在各自擅长的方向上展开合作，现实则是如果其中有一个人能力不太行，其他人就不得不被动地承担原本应该由他完成的工作，甚至可能因为沟通的问题使得效率进一步降低。

我是从专业细分的角度考虑这个问题的：

现代社会不断细分专业，让每个人都成为社会这个大的流水线上的一员，其目标毫无疑问是寻找具有效率的生产方式，但很多时候团队成员的能力不足以达成这个目的。

对企业而言，好的企业肯定不会因为害怕培养出复合型人才后人家跑掉就放弃培养，但很多企业 /产线可能本身就更偏向于流水线式的生产，而不是更关注团队中个人的创造力之类的东西，那么自然就倾向于保证员工的可替代性，降低人力成本等等方面。

对个人而言，成为螺丝钉一般不如成为复合型人才更有吸引力，又或者由于现在越来越多的复杂领域需要同时具有多个领域知识的复合型人才，之前强调单一专业的方向已经不再是最优解了，所以有能力的话应该去寻找能让你发挥的地方，找更好的企业 /团队，甚至自己组建这样的团队。

上世纪很多有名的科学家都是跨多个学科的，比如同时在数学和物理、化学、天文等领域有所成就，而现在也一直都有类似的观点被提出来，比如所谓的“T”型，兼顾知识的深度和广度。我个人认为知识的广度和深度都很重要，广度让你能从更全面的角度思考问题，而深度决定你能否在专业上取得突破，由于人的精力终究是有限的，怎么在这两方面取得平衡应该会是个很值得研究的问题吧？

[jack778]

如果这样可行,且产品经理是一个多余的岗位, 那么世界上最成功的(苹果,微软,谷歌)互联网产品公司为什么还会有产品经理这个岗位.

[ByZHkc3]

@ganbuliao 非常赞同，楼主显然还是太年轻了，或者仅仅局限于他自己的一亩三分地。

[wanguorui123]

产品经理真正的作用是收集需求，让程序员迭代同时程序员要知道自己做的业务，是否能有比较好的把握度去实现产品经理收集上来的需要，当然菜鸡程序员压根儿把握不住业务架构，最后把业务代码写成屎山，所以需要业务和技术把握能力强的程序员，这样兼顾业务和技术管理能力的程序员比较少。

[wanguorui123]

一般这种程序员是公司骨干程序员或者组长之内，当然不同公司水平还是有很大差别的，比较带头的人执行能力也不一样

[foam]

可能你接触的业务模型比较简单，也可能你没遇到过优秀的产品经理

[ilook]

@sdjl 我反而觉得 toc 的更不需要产品，tob 更需要产品。toc 的产品大家平时都在用，每个人都可以提出自己的见解和方案。tob 的除了简单的数据 crud 和通用基础功能只需要初级产品理一理或者程序员兼任，还有很多行业内和业务流程的解决方案是整体的，最终到研发那虽然只是加个字段加个表，但这个东西涉及的岗位和管理职责等等是需要很多思考和讨论以及商业权衡的。

[jaywhen]

不是，你们公司做需求的时候不会拉上产品经理、设计、开发一起对齐下吗，（也就是 96 楼 @BMAO 所提到的需求评审）？ 并且设计开始画设计稿的同时开发也能看到设计稿的变动，有啥问题可以及时沟通，你们是不是没有这个环节。

[vevlins]

产品经理的角色要有，但需要有专业素养。

[e3c78a97e0f8]

产品经理做的事情再弱智也是需要花大量时间的，程序员要是去干这个哪里还有时间写程序

[qiumaoyuan]

看情况。

如果给公司打工，就免了吧，别太想当然，你只看到产品跟程序员沟通的一面，没看到他们跟不专业的客户或者老板交涉、沟通的一面，那个过程大概率会让你恨得咬牙切齿。

如果是自己做东西，自然产品经理就是自己。

[akira]

随着 ai 的发展， 以后 部分公司出现 产品经理 和研发 工作混合也不奇怪的了。。

[DOLLOR]

没必要纠结这些，以后有 AI 了，程序员这个职位就淘汰了，然后大家都是产品经理。

[achira]

像个职场菜鸟说的话。

[snw]

我遇到过的不少程序员与业务人员的差别还是挺明显的。比如我作为内部客户开工单提问，IT 经常直接反馈给我数据在哪张表哪一列，故障是因为哪几张表的传递有问题，要是再问这张表是干啥的，大概率会回复“不清楚，IT 只负责技术性解释”。我作为内部客户倒也没啥，要是换成外部客户可能直接掀桌了。

所以需要有人对接技术和客户，除非程序员能把技术语言翻译成业务语言。

[dayeye2006199]

创业基本就是这么干的

[wangxiaoaer]

楼主应该换个说法：产品经理应该有技术背景，具备软件开发经验，而且不是因为干不好被迫转产品的那种。

不是所有的程序员都适合当产品，的确很多缺乏产品思维，自己做出的交互虽然目的是达到了，单交互方式让人眼前一黑。

[IMengXin]

现实的流程不应该是这样的吗？
产品经理做好原型图 ->跟设计师程序员开会讨论提出不合理的地方->产品经理修改->再讨论.....->大家都认可-> 设计师画出高保真设计图 -> 程序员说“这不合理”

[Qcui]

我咋感觉楼主是产品经理，被程序员怼了来发的吐槽贴￣□￣｜｜

[ssw2]

不觉得，专业的人干专业的事。现存的问题只是因为产品经理不及格

[xsi640]

程序员思维的产品，不敢想象！你看市面上除了一些技术类软件，哪些是程序员设计的？

[Gtreace]

我个人认为产品经理的存在还是有必要性的，产品设计的逻辑上线后被客户打回那锅是产品经理背，程序员自己设计那就是程序员自己的锅了，你是愿意自己多增加很大的背锅概率，还是愿意只 coding 来的效率高呢对哇。而且专门有一个人去收集业务信息再输出给你，就相当于上学的时候别人上课认真记的笔记，期末了给你复印了一份，类似这种感觉。都是打工嘛，合理甩锅才是重要的。

[timeance]

一开始我以为是钓鱼，没想到 OP 是认真的...

有这种质疑是好事，但在实际的团队协助中，产品经理并不是一个特别好的职位。它的职能是随着公司的实际业务情况和流程有所不同。

但不得不说，程序和客户之间是一定要有一个缓冲区的，比如产品经理，上面也有很多不同角度的说法

[expkzb]

@sdjl #30 人性就是这样的，积极也是因为有正向反馈

[loryyang]

不行
针对你提出的问题，我建议程序员参与产品设计，但不应该由程序员来设计。程序员也是需求方，要从技术可行性角度提出需求

[iOCZ]

消灭中间商，指导客户自己进行开发就行了

[vincent7245]

我工作中遇到的情况和 op 正好相反。

首先我是理工科初身的程序员，身兼项目负责人的那种。

对于大部分互联网公司来说，技术不是问题，技术不是问题，技术不是问题。这一点是很多程序员认不清楚，容易自我陶醉，认为我们开发很了不起，没有我们开发，你们啥产品都做不出来。

相反，除了了解核心业务的开发人员，这种人一个开发组不超过三个，剩下的开发人随时可以被换掉。甚至有些开发工作管理比较规范的公司，只要技术经理、架构师不离职，其他人谁走都没影响。

如果一个没有产品思维的程序员，去左右产品的研发，那是后果灾难性的。用户需求、交互、UI 等等这些东西真不谁都能做的，你只是看着简单而已。类似很多理工科出身的人会傲慢的认为文科生一无是处。产品也是一门很深的学问，不是谁都能做好的。

程序员平时写代码的思维方式和产品的思维方式的差别，就像理工科和文科一样，大相径庭。

当然很多做产品的本身很垃圾，那另当别论。

所以我多年工作经验的结论是：

1 程序员如果没有产品天赋，没有经过产品思维的训练，贸然去做产品后果是灾难性的。

2 程序员不要去试图左右产品的设计，这不是你的工作，如果你觉得一个需求无法实现，也不要直接甩一句做不了。都是成年人了，沟通的方式方法还是要掌握的。

把你可能遇到的问题用产品能听懂的话告诉他们，为什么实现不了跟他们讲清楚。很多时候产品自己也没整明白他们自己的真正需求是什么，如果你是个比较牛逼的人，你可以试图引导他们让他们意识到自己实际的需求，这个比较复杂，可以单开一个帖子了，暂时按下不表。

可能 OP 遇到的都是比价垃圾的产品，但凡你能和一个牛逼的产品经理共事一次，你就不会有这种想法了。

[mengdu]

想想要敲代码的同时，还要产品设计，对接客户，然后拿着一个份的工资，这种事情就离谱。
实际上好的产品应该都是要懂代码的，不然就是之前的那个根据手机壳颜色识别对应主题的搞笑故事了。

[hello267015]

微软几乎没有产品经理，近些年才引入，而苹果是产品驱动，对比下这两家公司的产品， 大概能 get 到程序员和专业产品设计产品时的思路区别 🙈

[woostundy]

实际这种分工模式对于大型软件工程是合理的，对产品的要求也更高。只是国内太多废物产品，一消化不了真实需求，二做不了整体规划，所以会让你觉得这种分工不合理。

[sdjl]

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

也就是说，很多程序员只是在干活，并没有站在用户的角度或站在甲方的角度，想要把事情做好，对吧？

[ljsh093]

特别复杂的业务逻辑我觉得还得是产品去碰比较好

[sdjl]

@iovekkk “一个需求上线后，有没有获得目标数据，比如下单转化量，注册转化量，或者其他什么数据
这些东西如果需要开发来负责，开发肯定头都要大了”

你是说不同的目标要让不同的人来背锅是吧？ 产品其实另有锅背？

[leega0]

很简单，产品经理学习一下对应技术，这样至少知道技术哪些是可以实现，哪些是不能实现或者很困难的

[shaozelin030405]

1. 产品确实不知道开发细节，很多时候得重新做原型
2. 理解你想说的，产品好多人都是**
3. 但是我只想早点下班，我把份内做完，其他管我毛事

[yhvictor]

我在国内国外都工作过。的确，国内的产品 scope 大得我有点难受。我更喜欢 eng 主导的开发。
国外的时候，产品只出方向，eng 负责之后的所有事情，包括但不限于设计、实现、测试。
产品的输出只是 eng 的输入。
比如跟 ux 沟通这活，有可能是是 eng 做的。测试基本都是自动化测试，也都是 eng 自己做的。
实际国内的产品还兼 TPM 的活。

[WaterMC]

从我的工作内容来看，主题里面，只涉及到了 明确需求方的 产品原型 这一部分。

如果程序开发同事来代工的话，那么还需要补充的有这些内容：
1 、用于存档备份的 产品需求说明书 /需求文档
2 、用于给客户 /产品使用方 的使用说明以及培训
3 、在动手做这个事情之前的可行性分析报告 /简报 - 至少留存备份用
4 、沟通过程中的 变更文档记录 /会议记录及摘要
5 、产品分析：用什么样的指标来评估这次功能开发是否达到预期期望值
6 、如果是新独立产品，随之而来的软著或内外部评奖的文档资料 /汇报材料
7 、效果图设计期间，和设计部门沟通以及反馈设计修改工作

这里列出的是一些需要归档记录整理的文本工作，当然不是每一次的需求开发都会又这么多文本工作，然后，你投入精力和时间完成这些以后，项目工期还剩下多少时间，来让你投入开发编程呢

其实这些文本工作还是最轻松的，困难的是在这些文本之外的沟通和协调以及流程合规的工作内容，费心费力。

=====

世事无绝对，也许楼主目前的工作环境， 是适合你提出的这种方式的。
只是不能一刀切，就说某一个岗位可以完全大包大揽。

[sdjl]

@devfeng “产品经理还有许多工作不和程序员打交道，这些工作反而是更重要的。”

你是说产品经理的一个重要作用是把非代码工作分离出去，和程序员并行运作，是吧？

[sdjl]

@zhanziyang “合格的产品经理需要 both 开发和产品的能力”

许多人提到了产品经理应该懂开发，或者说程序员可以转岗产品经理，这个可能是大家难得的共识了。

[sdjl]

@Livid 提个意见，我点击某个评论回复他人后，页面是否可以刷新定位到刚才我看的那个贴子，方便继续阅读？ 目前是返回到第一页顶部位置。

[sdjl]

@adian “最终原因还是因为大公司病吧”

是的，我觉得这确实是“大公司病”，但可能还有一方面，就是利益的分配问题，如果能找到新的生产关系与现有生产关系竞争，那就有可能实现新的生产模式。

[zzNaLOGIC]

太长不看版
于公：感觉你有点低估了产品的工作，过分高估了自己
于私：我为啥要多干一份工作，尤其是多背一份锅

也不是太长版
可能你接触的产品都比较水，但这就跟开发里也有水货是一个道理，但不能否认这个行业的天花板。
可能你认为的产品工作就是跟技术对接的部分（当然也可能是我水平低了，其实你站的高度很高）。根据我带了不少项目跟产品一起走了几遍之后，我就知道至少我无法完全胜任产品+开发的工作。
除了画原型，做需求，其实就需求市场调研和客户需求沟通和剖析这一块，就能干死百分之七八十的开发了吧？（不否认真的有沟通和思维能力强的，尤其是心态好的开发）大部分开发还是唯技术论的。估计让你去调研客户需求，你能一天骂八百遍娘，这都是些什么傻逼想法？到底懂不懂？不好意思，客户真的就是不懂的。好的产品需要在垃圾堆里捡起有用的需求并且通用化提炼出来。甚至要用相对科学的规划去尽量实现看起来很傻逼的需求。
当然，好的产品，需要涉及的点绝不仅仅是这一点点，这只是举个例子。就不一一列了，毕竟这方面我也是个半吊子。只是负责的项目多了，多少要跟着接触一点。
虽然我也承认，根据我的经历，站在纯开发的角度，有很大一部分公司的产品，除了背锅确实可有可无。但这不是这个行业可以消失的理由。

[sdjl]

@jaywhen “你们公司做需求的时候不会拉上产品经理、设计、开发一起对齐下吗”

我只是提出问题，我并没有在公司里上班，一般是自己开发。

不过大家还是讨论问题，不要议论楼主~

[link1994]

一边思考需求怎么符合用户习惯，一遍思考如何实现功能，是较为痛苦的。

[link1994]

市场、美工、前端、后端。 只负责其中一项，对工作者来说，更为轻松，不用什么都学一点，然后什么都不精。

[Parva]

我们公司每次新版本迭代，会指定其中一名参与的程序员当这次迭代的"项目经理"，专门负责跟产品沟通开发需求上的问题，再同步给其它开发的兄弟。（当然，原有的需求评审会议、需求分析会议、测试用例评审会议，所有人还是需要参与的）