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

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

xuanbg

2019-07-21 08:44:52 +08:00

我去！上面的回复简直不忍直视。。。天天喊着程序员是青春饭的是你们，不愿意在业务上下点功夫积累的也是你们。就你们这个认知，也不要等 30 岁 35 岁了，凡事都是赶早不赶晚，你们明儿就赶紧地、麻利地转行了吧。

别不服气，就你们平常写的那些破代码，一个智商在线的人我能三天教会。不说能解决多大问题，写的 bug 多不多，效率高不高，至少能够面向搜索引擎编程，能把一些简单的逻辑实现了。这说明什么？这说明现在写代码这个事情的难度和拧螺丝一个级别了呀。。。码农不再是程序员的自嘲，而是真的有了呀。。。但是，现在能解决业务问题的高级程序员还是非常稀缺的。

言尽于此

mcfog

2019-07-21 10:22:10 +08:00

我赞同工程师应当有产品素养，但不应当是为了替代产品的职责，而是为了正确找到产品需求和具体实现复杂度的平衡，产品即使懂技术，他也不了解项目的具体实现和技术债，所以产品需求当中一定有“虽然是好的体验但并不值得大量的研发维护成本”的部分，和“其实不需要太大成本就能做到更好的体验”的部分，工程师应当负责填补这个空白

我觉得楼主作为技术负责人，对产品团队若有若无的敌意是非常不可取的，先抛开产品团队其实并不差的可能性（你是否真的理解产品工作的复杂性？），即使产品团队真的不行，作为技术负责人，应该做的也是和产品负责人沟通交流看能否改善，产品负责人也不好沟通就和老板沟通。同时一定要避免煽动团队对抗产品经理，下面的人对抗就算了你作为领导也对抗那整个公司的协作配合的氛围就完蛋了。就好比销售和风控，开发和测试的关系是一样的，指责上可能有冲突，但团队之间一定是要配合的，讲默契的，这个氛围是需要双方领导一起来建设的

CF3B5

2019-07-21 10:40:28 +08:00

@mcfog 我其实对产品经理没意见，我有意见的是现在的很多的搞技术的这帮人，年纪轻轻，思维固化的厉害！我们那个年代，学了点技术就像应用起来，自己写网站，开博客，主动去想很多办法把自己所学的东西都用起来！但是感觉现在很多做技术的，完全就把自己当成了一个打字的！产品好不好那是产品的事情，有没有 bug 那是测试的事情，自己每天就是打字，只要需求完成了，不出 bug，绝不会改第二次，还觉得这才叫负责！系统出任何问题都是别人没有把问题告诉他，和这些人沟通太 TMD 难受了……

chmaple

2019-07-21 10:48:38 +08:00

@CF3B5
我的观点就是你有毒。
你觉得有问题第一步要找产品经理，都进入开发阶段了，还直接让程序员改，有没有一点规则概念？？？？
这不是你一个人过家家的事情，前端、后端、交互、UI、测试、产品，多方共同参与的。都进入开发阶段了你有问题就应该找产品、找项目的开发负责人，而不是扯一个程序员来批判，有病吧？
我做项目，别说你技术负责人，顶头 boss 让我不按照需求去开发要我改东西我都不搭理，都进入开发阶段了，你要改可以，找齐产品、开发负责人、测试负责人，需求变更的会议记录通知到所有人，不然改出事情了归谁？早不说干啥去了？还一大堆大道理，一堆的“我们当年”，还一堆的“感觉”，看把你能的。

chmaple

2019-07-21 11:08:22 +08:00

@CF3B5
而且需求是需求，技术是技术，别把两者混为一谈。
项目的需求，从下发需求文档、批注、评审、签字，这么长的时间你想改什么觉得有什么问题随便提。都签完字进入开发阶段了，除非涉及到流程不正确会卡死或者存在非常非常大的问题的情况下，会采取通知项目负责人和开发负责人以及相关人员一起修改，否则谁来说都应该是不做不改，你是产品经理还是咋滴，这个项目你是负责人吗？你要改大家知道吗？产品知道了吗同意了吗？
技术是另一回事。我这边项目开发完，每个人都有自己的学习计划和技术分享安排，爱搞权限的搞搞 shiro/security/jwt/sso 之类的，爱搞数据库的搞搞 es/elk/mongo/pg，爱玩网络的搞搞 nio/netty/dubbo。程序员这方面做的不好，不愿意学习，不愿意按照你的要求做技术调研，这个你可以随意喷，开了都是你的权利。
“只要需求完成了，不出 bug，绝不会改第二次，还觉得这才叫负责”，这就是负责，需求都完成了还没 BUG，只要代码 review 没有明明白白的错误（我们这边是违反阿里 java 规约、或者存在明显不合适的实现方式的时候），你凭什么要去改别人的代码？