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

@Gtreace “产品设计的逻辑上线后被客户打回那锅是产品经理背，程序员自己设计那就是程序员自己的锅了”

这个是从个人工作感受的角度考虑的，但是如果站在“老板要改进公司整体工作流程上”，打造一个“程序员兼产品经理的团队”，会不会更有效率呢？

自由软件没有产品经理, 成功的商业软件哪个没有产品?

我记得以前读大学的时候，老师和我们说：

好好努力，以后就可以从程序员变成产品经理，去带人了！

原因：产品经理是你的上级。

我在一些小项目上同时做过产品经理+设计师+程序员，虽然效率没得说，但最终产出质量难以提升，我想有两个原因很重要。
1 、会自我妥协。如果一个需求和设计效果我不会实现或者实现成本偏高，我会不自主降低需求水平。因为如果去挑战这些难点时会发现，难点往往不是单个难题，而是跨越业务、设计、技术的难题，有一个环节不熟练就会带来产出效率失控
2 、没有足够的时间和精力深钻。我时间有限，不可能既钻研技术、有学习设计、又去市场调研分析数据，水平很难提升，在任何一个领域也没有足够竞争力。

问一下 V 站的程序员们，你们有没有这样的经历：

程序员拿到产品的图，做啊做，发现不合理，需要和甲方沟通。

这时实际情况是甲方直接和程序员沟通，而不是产品经理在中间沟通，因为这样做节约大家的时间。

此时，无论程序员愿不愿意，程序员实际上都在干产品这个活。

@SillyChenBrother 可以说是上游，不能说是上级

程序员干了，那不就变成产品经理了吗？

@sdjl
问一下 V 站的程序员们，你们有没有这样的经历：
程序员拿到产品的图，做啊做，发现不合理，需要和甲方沟通。
这时实际情况是甲方直接和程序员沟通，而不是产品经理在中间沟通，因为这样做节约大家的时间。
此时，无论程序员愿不愿意，程序员实际上都在干产品这个活。

==========

很熟悉的操作，这事情我自己就做过。

1 、拉一个会议室，直接开发同事和业务同事聊。 == 我在场参与
2 、或者是一个邮件 /信息留言，直接让业务和技术同事他们自己约时间碰一下。 == 我不参与这个过程，事后再听一下双方的共识或者分歧

原因为啥：
1 、业务不信任我啊，业务认为我在故意刁难他部门的需求，不给他们排期，或者夸大他们的需求提升难度，所以他们要干掉我这个二道贩子，直接面对技术部门
2 、这个需求或者功能，我已经放弃了，无论结果如何，都不会做。但是场面上，不能撕破脸，所以就客套一下。
3 、工作交接：这个东西原本就是 业务技术直接对接的，他们已经磨合好了，我中途接手，所以我的角色就是如实记录，做好文档工作。之后再交给下一任。
4 、技术团队认为我没有讲清楚需求，所以他们要直接了解一下初始需求。
5 、我自己的私心，因为有些工作任务确实不需要我投入工作量，技术和业务直接就能搞定，我参与反而效率低徒增成本。
6 、我自己的阴暗面，在面对甲方时，尤其是项目进行了一段时间之后，发现了不合理。我去和甲方说的话，那么全部责任在我，是我无能没有提前发现隐患导致的项目风险，一旦甲方有了这种印象，我后续的二期、三期、运营维护合同还怎么和甲方愉快的玩耍？所以就一定需要我之外的人，去把这个锅背起来，然后我担一个次要责任。加入我让技术同事去沟通了，那我无非就是收到了技术评估的蒙蔽才误判了一些东西，我后续一定更仔细负责一些。所以二期、三期这些我还是能好好聊的。 ==献祭他人保全自己

其他的原因就不列举了
但是我要说，这事情上，程序员还真的不是在干产品这个活。

======
打个哈哈，抖个机灵儿

有没有一种可能，产品经理、测试、运维这些岗位就是从程序员分拆出来的呢？

所以 需求评审阶段 是干啥的呢？不就是应该让开发也参与进评审么？
原型图 直接评审，UI 肯定得在评审后再干活啊。

@sdjl 术业有专攻，产品经理又不是只做一个产品，开发进行的时候，产品经理可以下一版本，或做其它产品。
职位本身是合理的，人不行应该换人，我们比较烦的是非技术出身又不太爱学习的产品经理，这种建议辞退。

toC 的可能需要产品经理，toB 的，对内的业务，大部分是没有产品经理的，搞业务的，还要给产品经理讲业务，指导产品经理画，浪费时间，浪费精力。

也有可能你们的项目不是很复杂，所以不需要专门的产品经理

主要是大多数产品经理不专业，真觉得是个人就能干了

@liveoppo 一般不是程序去背锅了么 233

只能说你是一个想当产品经理的程序员
产品经理是出题家
程序员是做题家
有一大部分程序员是就喜欢做题而不喜欢出题的
当然，任何一个岗位想要做好，都需要一些交叉背景
但这是个人追求
不是职业要求

都你来，保洁 行政 会计 老板都你当，不跟你抢

你们不觉得后台接口这活儿，应该由前端（包含 iOS/安卓）程序员自己干吗？

@sdjl #201#201 看了下你前面回复的，意思是在产品设计的过程中程序员直接参与去进行设计是吧，但是显然有更合理的方案呀，我们公司是这样的：产品对需求进行调研→产出设计图→需求宣讲会（包含产品开发测试）→会上前后端 leader 以及具体负责的前后端 测试会对产品产出的设计进行评审→在会上大致前后端各自讨论能否实现或者如何实现更方便以及大致开发方向；这样开发也参与了设计的一部分了解开发需要的框架，而不是直接由开发对需求进行调研后直接产出设计，先不说大部分现在的前端没有 css 审美这一说（大家也都是为了完成任务 可以理解），客户对设计的满意度谁去对接呢，开发直接去对接客户嘛，不现实的嘛，那就还是需要一个人去对需求进行调研以及对接客户嘛；而且如果设计由开发直接产出，那开发自身的 coding 时间肯定会受到压缩的吧，一个人精力就这点，多干其他的事情，本业就会减少。
总结就是总要有这么个人去对接，那不如设计也交给他们去产出一份大概的，有不合理的地方再去评审打回就好了。

我之前在小厂待过，感觉 PD 很专业，基本功就不说了，很扎实，还懂技术细节，又懂行业发展趋势...
到了大厂之后，MD ，啥玩意儿啊，只会传话的 PD 遍地都是，有时候原型图都不画，就给个页面，可以抄... 无效的电话会议没少打，遇到事儿躲的远远的，产品稍微做出来点儿啥，到处宣传，感觉都是他做的...

看沟通能力、理解能力、思维能力。