害，有时候觉得，产品真的就是领导，程序员，就是一条实施狗。

• 資深大佬 : eGlhb2Jhb2Jhbw

  要不然呢？他的工作就是这样的，你该讲到的讲到，声明出了问题他背锅就行了。实现他说的过一天，实现你自己说的也是一天，公司又不会欠你这一天的工资。（况且，不一定是你对）

• 資深大佬 : westy

  谁离用户近，谁离收入近谁说了算。

  我是觉得程序员应该距离用户和收入更近一点的。Coder 都懂产品和用户了就不用天天说 PM 怎么怎么样了…

• 資深大佬 : findmyself

  主要看开发这边的头硬不硬

• 資深大佬 : dodo2012

  我去，你们都啥心理啊，工作而已，

• 資深大佬 : StickmY

  那你其实可以去做产品的，会舒服很多（对你个人而言）

• 資深大佬 : taxiaohaohhh

  这东西谁背锅谁说了算

• 資深大佬 : Hanggi

  你要拿到主导权，不要总是被牵着走。

  你要明白，如果你是干活的，你的领导就是用来担责的，你要把选择带来的利害关系说清楚，然后把所有责任推给领导。
  如果你们家产品经理有产品决定权，那么每个选择造成的结果都要他来担。
  一旦出什么问题，就要把领导吊起来抽，让他知道当领导有多难。

  而且，在听从指示的同时要加入自己主观的选择，这样你自己做着也舒服点。

• 資深大佬 : onfuns

  但是产品做不好也是被大领导骂

• 資深大佬 : mougua

  这不挺好么？

• 資深大佬 : hao4857

  兄弟有点偏激了，普通的分工而已，何来领导，何来狗…

• 資深大佬 : yaphets666

  那肯定啊 做坏了 要你负责吗? 如果你好好砌砖了 塌了肯定设计师背锅啊

• 資深大佬 : whatv3

  工作而已+1 。

  我是产品，我反正是很愿意跟咱们研发打成一片啊，我觉得大部分研发也是负责的。

  除了极少数，会制造对立，“这个做不了…”，认真负责的评估结果，我们都能够讨论，我还和研发共同写过代码。

  与此同时，产品确实会有一些其他的考量。

  我个人理解哈，举个例子，比如之前很火的，手机壳颜色改主题事件。这个需求，本身看起来很不合理，不过如果有前提呢？共同讨论方案呢？

  1，需求来源举例：在 iPhone5c 时代，App Store 有一个电台 App，本身功能免费，但是默认只能白色主题，如果更换主题，比如我用的绿色 5c，想用绿色主题，就得 6 元购买，我买了反正。 — 如果这款 App 就是这个公司的产品，他的盈利模式就是这样，这个需求是不是也不那么无理了？（实现方式另说）

  2，锤子吧，好像是，之前不是出过手机壳，不同贝壳不同主题么，实现方式是用 NFC 吧，我印象里是。类似的，三星的 led 贝壳也是，用 nfc 实现了更新奇的内容。（哪怕是自动识别，也不是不可能）

  当然，我也意识到，手机壳改主题事件，主要在于确实基于当时的限制（第三方 App ），确实是不太可能实现的。

  我是觉得，这个都是沟通者进行的。同时，也确实需要有人拍板，拍板的人不一定是领导，更有可能是背锅侠~（承担责任）

  我是觉得，大家没必要对立，一起把事情搞定不好么。如果不做一点新的东西，那么也没什么意思不是么。过程中遇到问题，一块想办法呗。

• 資深大佬 : Cielsky

  工作不要代入感情，又没侮辱你的人格什么的，只是意见不合罢了

• 資深大佬 : cnrting

  你自己开个公司，老板 PM 程序员你都可以自己做，是不是很爽

• 資深大佬 : orangey

  @westy

  无非就是讨论可行性，如果技术能实现，技术跟产品去纠结什么，背锅位又不是技术

  反过来是一样的，如果产品也会技术

  下次发帖人就是产品了：
  讨论了一圈，结论就是
  技术：就这样了，实现太麻烦，要考虑很多，换个需求吧

• 資深大佬 : coderluan

  我感觉都没谈到点子上, 产品和开发的矛盾点根本不在需求, 而是这个需求的工作量.

  需要是应该按产品的来, 但是工作量是开发决定的啊, 这时候如果产品相信开发, 接受工作量或者修改需求, 大家肯定是相安无事的. 但是一旦产品自以为是的估计工作量或者去压榨开发让开发加班, 那开发一定只想和产品母亲进行亲切交流了.

• 資深大佬 : hanksun

  嗯大家想的都很开啊

• 資深大佬 : alphadog619

  需求不评审吗？产品说啥就是啥吗?真的是业务专家也可以，但是大部分产品都是拍脑袋的。

• 資深大佬 : 2379920898

  麻烦加个分号或者句号

• 資深大佬 : lifesimple

  没必要 工作而已
  要是产品的需求很奇葩 就多要点工时
  后面又要改，给时间改就是了，公司本质上还是花钱买你的时间，干什么都一样。（个人拙见 勿喷）

• 資深大佬 : zarte

  产品考虑的是用户使用，至于技术实现应该技术经理来负责。产品说按他的可以，成本问题技术经理来给。

• 資深大佬 : Kirsk

  既做产品又做开发算甚么？

• 資深大佬 : jsondog

  都是打工，又不是自己创业，纠结这个点没啥必要

• 資深大佬 : jsondog

  @lifesimple 是这样的，爱改啥改啥，只要给我时间就行。改 50 遍也没问题，反正都是按时间领工资

• 資深大佬 : gabezhao

  那要不然呢，来需求了让产品经理做吗？

• 資深大佬 : LETTXZ

  狗就狗 为啥说实施狗 看不起实施？

• 資深大佬 : Landlords

  看评审水平 ，有时候一些设计用起来逻辑根本走不通，根本都没仔细想过的

• 資深大佬 : gimp

  他跟你说这么做，你跟他加工时啊

• 資深大佬 : lcdxiangzi

  心态摆好，他们有他们的难处。他们愿意做决定摆好，出问题他们自己负责

• 資深大佬 : gimp

  不合理的需求及时向上反馈，做一个快乐的不粘锅

• 主 資深大佬 : cyiwei

  大伙看的都很开，然而，明明平级，却在发号施令。

• 資深大佬 : wangkun025

  最郁闷的是，讨论完了，产品的任务就完成了，程序员的任务刚刚开始。

• 資深大佬 : soulmt

  你要觉得是条狗，那你不管干啥都有这种感觉，务工者，想那么多干什么？

• 資深大佬 : mars0prince

  你也可以开个公司，招一堆产品，每天工作就是否定他们的方案嘛

• 資深大佬 : gadsavesme

  不知道你遇到的都是啥产品，反正我们这边产品都挺不错的，你觉得有问题的地方可以改，都是可以商量的，真有争执的地方退一步听产品的好了，毕竟开发干啥不是干，只要实现上没啥问题你爱咋弄咋弄呗。还有就是工作量肯定也是开发这边定，不知道你们那边啥情况-。-

• 資深大佬 : binxin

  因为权责利统一啊~
  产品做得稀烂，日活个位数，研发仍然可以靠技术牛逼晋升，视觉直接贴个博客就能跳槽，但是这个 PM 就很难做了。
  复盘的时候，效果不好，大家是不是都在骂 PM sb ？
  复盘的时候，效果很好，是不是也是 pm 组织，表扬大家，实际上最大受益者可能是 PM ？

  既然如此，既然项目做得不好最早被优化的一定是 PM，那么责任和权利统一嘛。
  除非，项目做得好，研发也站出来背锅，那么肯定让研发有话语权，问题是，实际情况大概率是项目不好，研发是第一个站出来怼 PM 的。

• 資深大佬 : eGlhb2Jhb2Jhbw

  @cyiwei #31 “明明平级，却在发号施令。” 这是他的工作啊，就像 coding 就是你的工作，不明白你有啥想不通的。就像你给 ux 说切这个图切那个图一样，难道你也是在发号施令？

• 資深大佬 : ZoR

  事先把锅甩出去 有人愿意背 就行了,刚毕业那会也爱钻牛角尖，时间长了想想没必要

• 資深大佬 : zdnyp

  只要代码没 bug，又不用你背锅

• 資深大佬 : Tink

  谁背锅谁说了算

• 資深大佬 : LiuJiang

  我天天怼我产品

• 資深大佬 : xuanbg

  做什么当然产品说了算，不然呢？

  产品又没管你怎么实现。

• 資深大佬 : JerryCha

  你可以抗议，让产品以后当个半全栈，尤其你看现在 vue/react 多么好上手。
  产品拿 code 做个 prototype，然后扔给开发完善。

• 資深大佬 : liujialongstar

  只要能实现, 当然听产品的, 至于客户体验好不好, 又不用程序员背锅. 大不了再改嘛, 虽然改需求很烦

• 資深大佬 : helionzzz

  当你有这种心态了就算你是产品了你也觉得也就是条传达用户信息的狗而已

• 資深大佬 : XCG0000

  有的公司也是技术主导的呀，你完全可以和产品 pk，产品是需要说服支持方才能开展的项目的，除非你们产品本身就是老板

• 資深大佬 : saberlove

  面向工资编程

• 資深大佬 : voidxx

  在我司，产品>运维 /测试>前端>后端，我就是那个后端

• 資深大佬 : LennieChoi

  产品决策、决定需求本就是他的工作，叫唤就叫唤吧。但有一种产品比需杠，就是老把快速试错挂嘴边的人，好家伙给自己整的挺专业似的，快速试错，敏捷开发，迭代发版更新。一句试错，程序员又得加班赶进度，他嘴里的快速试错 好家伙的 试错成本全在咱程序身上了。现在又不是百花争鸣的市场，什么样的产品投放到市场，以什么方式运营，这么多年了，早就行成了一套很成熟方案，除非真是在做全新领域。这年头了 还试错 那只能怀疑产品的专业度了

• 資深大佬 : jydeng

  流水的产品，铁打的开发，产品要背锅，所以听他的。

• 資深大佬 : whypool

  讲道理，程序员是做不出产品的

  或者说，程序员做的产品都是半成品

• 資深大佬 : citydog

  包工头也没见听取过板砖的意见
  按他说的整就行了，出了事又不是你负责，干一天活，拿一天工资，何必跟自己较劲
  话糙理不糙

• 資深大佬 : kaedea

  产品就是调和老板和程序员之间矛盾的产物，ta 执行的是老板的意志。

• 資深大佬 : maddot

  普通程序员就是搬砖的，不过享受了行业的红利工资相对比较高而已，像古代，多数人是文盲，文章写通顺了就有官做。以后编程成了中小学生必修课，就没这种红利了

• 資深大佬 : keepeye

  经常怼产品不要做客户的传话筒要有自己的主见

• 資深大佬 : westy

  @orangey 我认为是存在这样一个场景的：技术跟产品一起讨论需求的目地是什么，想要解决的问题和带给用户的新的体验是什么，然后共同找到一个技术可以实现也能满足目地的新需求出来。

  我是技术出身的产品，我觉得懂技术的产品或者懂产品的技术都是对最终结果更有帮助的人。

  不管是技术还是产品大家的工作其实都是把业务做好了公司多挣点钱好让自己也能多拿点价值（钱或者经验或者名头），所以我觉得与其讨论谁对谁错倒不如一起向对方的职业走两步然后一起想办法实现自己的目地。

• 資深大佬 : souths

  不嫌弃累你可以兼了产品的活……

• 資深大佬 : opengps

  很多出发点很好的好产品都是被 [产品] 做烂的

• 資深大佬 : mouyase

  我倒是见过一个公司，产品确实是领导，就算是新来的小产品也是程序的领导（指程序请假要找产品汇报那种

• 資深大佬 : john22eclipse

  产品一句话，开发加班好几天☹ 整个行业有种开发成了最底层的趋势，也是代价最大的承担者（背锅）

• 資深大佬 : orangey

  @westy
  现实是这样的，只不过主的发言给人一种 你说的不算，我说了的才算的感觉。
  他心态上发生了亿点点变化 也没放上具体过程，我只能代入我的见解了

  产品经理定位近似于小组 leader，对项目结果负责。讨论会上大家发表各自意见，修正不合理的要求。讨论结束各领各的活，产品对项目最终结果负责。如果有独特的见解，有数据或者某一方面能够支撑你的方案，我觉得这很 OK 。

  不然就是你在教产品做产品，换过来如果一个不会写代码的人强行让主按照他的意愿去写，我不觉得主会这么好沟通

• 資深大佬 : zhuweiyou

  让他以邮件形式说明需求，以免到时候出了问题，好划分责任。

• 資深大佬 : 80738730

  @Kirsk 自主创业

• 資深大佬 : Jooooooooo

  所以我一直说程序员是整个互联网产业链上创造力最低的职业

  最接近搬砖工的工种

• 資深大佬 : newmoyupoi

  我们公司运营说了算…

• 資深大佬 : iplayio2019

  有产品就不错了，没产品才头疼呢。

• 資深大佬 : ImSpiderMan

  我是这么看待这个问题的 ，产品经理和程序人员都是项目中不可或缺的一部分，每个人都有自己的一套逻辑和想法，但是整个项目组如果想把项目落地，那么就需要有一个主导项目进程的人，老板不懂程序员的心声，老板只要结果，那么产品经理就需要把老板想要的结果，转化成程序员可以理解的，这样项目才会有进展。这也得看你是服务什么样的公司，如果是传统行业的话产品的需求不是市场说了算，也不是产品经理说了算，而是老板说了算，如果是创业型项目的话是产品经理结合运营经理的市场需求，来去做 PRD 文档给程序人员，让程序人员进行开发、测试、上线。只是分工不同，程序如果对于需求方面和运营方面有涉猎的话可以向产品经理转。

• 資深大佬 : iasuna

  真逗

  不就是搬砖嘛 还以为自己是公司的主人呢

  产品让你干啥你就干啥呗 干不动再说 搬砖的人每天挑砖的好坏 闹呢？

• 資深大佬 : a1562619919

  割裂产品和开发的关系没意义，不如就事论事说说是啥矛盾，平均而言产品比开发懂产品，技术比产品懂技术，谁行听谁

• 資深大佬 : zhw2590582

  产品本来就是分析需求的啊，他这样做完全没毛病，做开发可以提意见，但最终还是产品说了算，别计较啊。

• 資深大佬 : haha12000

  盲生，你突破了华点

• 資深大佬 : Flourite

  不知道你工作了多久，如果刚出来的话，是件好事，说明你一下子看清了事实

• 資深大佬 : Flourite

  天下产品一大抄

• 資深大佬 : hjw45611

  各司其职而已，你要觉得你能干，你可以转岗，你跟客户谈需求，把控项目进度

• 資深大佬 : vZexc0m

  需求可以讨论，关键是有些产品的水平参差不齐，做出来的东西逻辑都走不通，前后矛盾，最后还要开发来完善逻辑。有时候我甚至怀疑一些产品都不知道自己在做什么东西。

• 資深大佬 : NoKey

  能不能做，需求评审，评审完确定可以做就做，个人的想法，可以写点日记啊，博客啊之类的，等一定时间来验证，看是自己想的对，还是别人对了

• 資深大佬 : justin2018

  刚刚做完一个 demo 说是确定了 结果 又要修改 跟当初说的不一样了

• 資深大佬 : neptuno

  其实产品也不是，上面的 boss 才是领导，boss 一句话调整业务，产品和程序员都得加班，，都是苦逼打工仔，没啥领不领导的

• 資深大佬 : atonku

  很简单啊，放平心态。
  坚持贯彻一小时定需求，一个月写代码，一年改需求的精神绝不动摇！

• 資深大佬 : xzwc

  不要觉得 就是 哈哈哈

• 資深大佬 : Desiree

  首先要看得起自己，不然你还指望别人看得起你？

• 資深大佬 : d0v0b

  按着产品的要求做就完事了，大不了工期长，只要不甩锅

• 資深大佬 : intellectual

  这不是产品那个人的问题。你程序员在公司工作大话说是实现梦想，实际上是解决公司的需求，产品创造了这个需求，你有意见当然可以，但你的意见那不是需求。明确这个需求的合理性的背锅是谁那就好了，完了还是那句比较难听的话，干的不爽可以走啊。想办法让自己干得爽一点吧。

• 資深大佬 : buzailianxi

  不爽就骂他，叼他，搞好自己的铁饭碗，就没事

• 資深大佬 : secsilm

  歪个，「害」这个字用在这里具体是啥意思，来源是哪？读起来很别扭啊

• 資深大佬 : jmyz0455

  @secsilm 貌似就是嗨。你把它想象成口语化地读出来就可以了。

  我经常用语音输入法，发现自己日常说话很多语气词，转成文字可能让人摸不着头脑，但是一念出来就懂了。