现在做程序员（工程师），难道不应该考虑自己负责的产品设计工作吗？

[CF3B5]

前几天有个 Java 程序员死活不愿意改程序，都吵起来了，说你又不是产品经理（我是技术总监）凭什么要我们改，产品经理的文档就是要求做成这样子的……
作为一个十几年前就已经是程序员老人来说，我们当年都是和项目经理一起去和用户碰需求，自己做设计画原型，都是在我们的脑海里从一个假想的画面，或者功能，然后通过自己的双手逐渐变成现实，那时候那种成就感是无与伦比的！
实话实说，我觉得我们这代人天然觉得自己作为程序员，作为软件工程师，天生就是应该是去思考如何用我掌握的技术，去思考、去设计系统该做成什么样子的人。系统在性能、稳定性、人性化、交互流程等等多方面都是应该是软件工程师能力的体现才对，特别是掌握如何将系统设计的更人性，更友好的能力，和想办法掌握某个编程语言的能力都应该是一个程序员工程师应该追求的能力啊。现在炒的火热的微信产品经理张小龙，还有大家熟悉的马化腾、雷军、周鸿祎等等，这些人那个当初不都是程序员吗？
这几年我带团队，我和新一代的程序员聊过很多次这个话题，他们的理由基本上都是说程序员都是不善于沟通的群体，就应该专注写代码，这些事情应该交给更善于沟通的产品经理去做，任何系统都是一大帮人团队配合的结果，你怎么可以让程序员去设计和了解需求，这样是非常不专业的……你以前干的都是小 case，我们是干大家伙的（实际上我以前干的系统比现在大得多和复杂的多了）！
实话说如果有特别靠谱的产品经理，我也的不介意让需求沟通、产品设计这事由产品经理分担去做，但是这几年和一些产品经理接触下来，我自己感觉真正靠谱的产品经理那是比程序员少太多太多了。程序员想法其实在再不济，好歹也是能把问题解决吧！但是很多产品经理因为不了解技术，往往很多时候把简单问题复杂化，甚至让沟通更复杂困难，问题反而解决的不好了。甚至有些产品经理觉得自己不懂技术才是优势，他们觉得懂了技术就局限了自己的空间，这样产品就会变得没有“创意”了，你和他讨论产品的设计，他反而会用你太懂技术了，所以你的想法不行用户不会接受的这种观点来拒绝你……无语……
我一直和我们的工程师说，github 里头的各种开源项目，Appstore 里头的大量 App，其实都不一定是产品经理带领下完成的吧，这些这么优秀的产品，不都是一帮、甚至只有一个程序员、软件工程师呕心沥血的成绩吗？现在语言的发展和技术的创新发展，不都是在让程序员变得更复合，更独当一面，似乎并不是变得分工更细，更专注只是编码啊！（ MD 我感觉现在写起代码来比我们那个时候简单太多了）
所以现在在我自己的团队里头，我一直在坚持要求程序员自己一定要去参与设计产品和系统。但是这么做下来，脚本语言的小伙伴还算配合和理解，但是后端 Java 的这帮人真心是不接受，很多时候和这帮人沟通我都有种绝望的感觉，所以有时候我也是真是挺迷茫的，也许是我真的已经 out 了，难道我真的 Out 了吗？

[www5070504]

而且生产力发展的一个重要方式不就是专业化细分吗 不然大家都去搞全栈不就好了吗 全栈可就不是这个价了

[www5070504]

我相信做到总监级别的人 不会不明白基本的职场潜规则 除非是领导家亲戚

你想想如果底层员工直接跨级汇报 你乐意吗 如果你是团队负责人你乐意吗

[liuxu]

总监要改需求，应该是去找产品经理改原型，改完文档定下来程序员和产品经理对接改代码

不然时间久了突然有人说程序员没按产品经理的原型开发，他找谁说理去？

[sheny]

有 bug （ criminal ）要改（抓），你直接改（上）呗（啊），要产（ police ）品（ legal ）干什么，这年头有责任心的年轻人真是太少了，想当年我们都。。。。

[ganbuliao]

最烦做事只管担不但责任麻不麻烦,不动脑子考虑的人，程序员是整个产品最后输出的人，要是程序员明明知道产品这么设计 还按照产品的去做 我觉得才有问题吧 我见过的产品没有一个设计的东西最后细节没问题的 难道非得全做完了让他们发现有问题 在改才是正确的 ，我觉得这种人最后肯定会被代替（机器人在不思考的情况下比你高效的多）。可能好多人看不懂我说的话，不在一个思考频道的肯定看不懂了。^_^

[zr8657]

想让手底下人听话还不简单，加钱啊，钱到位人到位多么浅显易懂的道理，现在都 2019 年了。

[passerbytiny]

@CF3B5
程序员（ Programmer ）是一种人物类型，制作程序的人基本上都可以被叫做程序员；软件工程师（ Software Engineer ）是一种职业工种，并且是“工程师”大类下的一个工种，有明确的能力要求、职责要求，和工作范围，有些较真的地方还会有认证要求：请不要将二者混为一谈。

只负责编码不负责需求制定或者产品设计的工程师，严格意义上叫做软件开发工程师（不排除有些守旧的公司还会再细分为软件设计工程师和软件编码工程师）。不负责编码只负责产品的人，传统工程中叫做系统工程师或者需求工程师，敏捷开发中叫做产品负责人（形同产品设计工程师）。上面的人都是程序员，并且都是工程师，区别只在于是不同方向的工程师。至于“产品经理”，这是一个呵呵呵的中国特色职位。但是，他特色的原因不是“产品”，而是“经理”，而且是那种拥有无限权力但不用负主要责任的经理。你不能因为产品经理而否定产品。

程序员，可以并且应当具备软件开发、产品设计两种能力，好的程序员可以在开发工程师和产品工程师之间相互切换。但是，一旦一个具体的项目或者迭代开始了，那么权力和职责就固定了，不能随意切换，这一点不管是传统工程学还是敏捷开发，都是如此要求的。即使是只有一个人开发的项目，这个人也应该在不同的场合切换不同的身份：调研的时候要变成产品，不能在这时候考虑“循环比递归好”；编码的时候要变成开发，不能在这时候出现“用户操作时，这个分支是走不到的，所以我就不做这个分支的单元测试了”。楼主你要求程序员自己一定要去参与设计产品和系统，我不知道你是要求他们在什么阶段去参与，如果是在编码阶段同时参与，一边编着码，一边去设计产品，这必然会严重降低代码的质量。反过来，如果产品负责人一边设计交互过程，一边想着该怎么编码，那这设计出来的产品的用户体验度必然是极差的。

张小龙、马化腾、雷军、周鸿祎虽然都是程序员出身，但是他们现在可不是程序员。在他们当初干程序员的时候，做得东西并没有在市场站稳。

[abcbuzhiming]

楼主你说你是技术总监？你一个总监怎么这点职场基本规则都不懂？你要让程序员改需求，难道不应该先把产品经理叫过来，你都没说服产品经理，凭什么越级指挥程序员呢？你改了需求到时候产品经理不认，这算谁的？你的想法才有问题，我倒不觉得 Java 程序员有说错什么，产品经理出了文档，不按文档做到时候产品经理翻脸你给帮说话不？
程序员参与产品设计，这没错，优秀的技术人员大部分同事也是优秀的产品设计，问题是职责在谁那里？产品经理已经存在并且写了文档的情况下，楼主不先和产品经理商量，反而煽动程序员私自修改需求。你那产品经理真是好说话，不怕人家键盘砸你脸上并且拉老总来怼你？

[gw1992225]

作为楼主口中新一辈的程序员 其实我们也是想尽心尽力 多学点东西 把产品做的尽善尽美 但是在公司真的是要分工明确的 公司既然有流程一定要遵守流程 楼主觉得有不妥可以把大家都叫上一起开会讨论定方案定工期 而不是单纯的觉得后端开发有问题

[chen2019]

... 唉，LZ 人人有本难念的经 尤其是底下程序员 可能有些有好几个领导 比如 项目经理 产品经理 技术主管 老板 ，到底听谁的？这么多领导，自己能提什么意见？不会说话的直男说错话了，那岂不是代表着 这么多上级想得都没自己好？所以选择一个能负责的人听，才是生存之道。
这不是程序员对产品负责的问题，是程序员无权对产品设计负责，而经常还得对此背锅。

[CF3B5]

我觉得看到很多人的回复，让我想到一句话：后宫不得干政治……哈哈，看样子很多公司的技术部就是公司的后宫啊！实在想不到这么多人年纪轻轻就如此的迂腐！
当我们说起某个软件、某个系统的作者的时候，无一例外提到的都是这个软件、系统的技程序员，工程师！产品经理并非说不重要，但是很明显在计算机的世界里头，程序员、软件工程师才是真真正正这个计算机世界皇冠拥有者，过去是，未来也应该是！如果你还不承认，你可以翻翻自己的电脑，看看里面的软件，有多少找的到他的产品经理，有多少找得到他的开发工程师？
说白了，权力越大，责任也越大，很多人无非就是不想承担责任而已，流程什么都是虚的，产品的好坏本身就是一个团队应该共同负责和承担的责任，很多程序员只不过是借着“后宫不得干政”这个理由来规避自己的责任而已！就好像产品好不好是产品经理的事，程序有没有 Bug 是测试的事，我就是个打字的，虽然可能拿着整个 team 里头最高的工资，但是想让我承担责任？ NoWay ！

@sampeng 所以其实你的分析的是对的，我目的吐槽的其实就是程序员，但是没想到这么多人关注的是流程，就是所谓的技术不能干政……真是是挺无语的……说真的我一点都不排斥产品经理！我的意思是就算有产品经理，程序员都应该主动积极的去参与思考产品设计，一样要对产品好坏负责！很多程序员觉得自己不应该背这个锅，其实我想表达的是，产品设计这个锅本来就是程序员、软件工程师背的，你才是这个世界的国王，是你把这个责任甩给了产品经理而已！放十年前，很多软件项目只有项目经理+程序员，实际上产品经理这个岗位并不流行。所以说白了，程序员不是受害者，产品经理才是受害者！

@LeeChP 其实你觉得你最痛恨我这种人，但是你没有发现你就是现在这种结构的受害者吗？如果本身项目给予工程师足够的尊重，让工程师参与沟通和了解需求，你作为工程师如果一开始了解用户真实需求想法，按照这个需求和想法去设计架构，这本不就是最合理和最高效的开发流程不是吗？现在所谓的流程，把责任都甩给了很多连实现原理都闹不清楚的黄毛小子，要和客户沟通，设计了解需求的时候，就给产品经理带高帽，说产品经理们才专业，产品经理沟通能力比我们好！等要写代码的时候，自己又在骂娘，什么产品经理设计的东西都是一坨屎，垃圾，动不动就要改等等……！你觉得你背了别人的锅，实际上产品经理何尝不在被背程序员的锅？

[yxcoder]

感觉挺有道理的，对于软件工程师和程序员的划分标准之一就是在软件生命周期中的参与程度。软件工程师应该是需要参与到软件的整个流程中的，或许在有些过程中，软件工程师不是决定性的地位，但参与到其中对自己本职工作是有很大的帮助的。

[LeeChP]

所以当你吐槽这个的时候，麻烦能先把贵司的产品先开了么？你以为这种流程这种结构别人愿意啊？还不如吃一堑涨一智？不按流程，最后出了问题程序员背锅？还是说，你绕开产品直接找程序员，就是为了规避风险，把锅扔给程序员？坏的很！

[Fortnight]

让开发者参与设计这个想法本身没有错，但是改程序的例子举得不行，真的有需要改的地方应该先跟产品沟通，而不是直接就改了，不然产品又说研发不按文档来，这个锅还是得研发背

[JerryCha]

楼主认为大家不懂产品，大家认为楼主不懂企业。

[maxiaofeng]

所以你说服不了产品经理，也没能力改变公司流程！ 只有来喷一波 java 后端？ java 后端脸上写的好欺负写嘛？

[Aresxue]

1.改了可能要背锅，不改就不会，这种明哲保身没人可以指摘；
2.职业不断细化，最早的程序员是全能的，后来分化为产品、测试、运维，甚至本身又分化为前端和后端，这是有一定道理的，随着业务复杂度的上升，分工确实能带来效率上的提高；
3.有追求且有精力的程序员是乐于参与产品设计的，像提到的成就感和参与感是一个方面，了解市场和用户并融入产品的能力也是程序员独当一面的一个必经历程，但不能苛求。

[CF3B5]

@Aresxue @LeeChP 其实说来说去就是怕背锅……
在公司里头混日子怕背锅，不去干沟通需求设计产品的事情，这是一件事！
但是作为程序员该不该具备沟通需求，设计产品能力，这又是另一件事！
在我看来在公司里头，为了明哲保身各种甩锅没问题！
但是作为这个行业从业人员，自己要成长要发展，就是应当去思考产品和需求的，这本来就应该是程序员应该具备的能力，这个和在公司里头如何避免背锅并不冲突！

[aaronhua]

论一个不恰当的例子，如何引战。lz 很强

[xaplux]

这种事情不应该技术总监先去和产品碰一下么，产品同意你再去和具体搬砖的说么？我一般如果觉得产品设计不合理我会直接向产品提出来，说出我的想法。我也经常和具体任务成员强调，如果觉得产品不合理，那么试着去说服产品经理。