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

[CF3B5]

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

[version]

@lonelygo 现实中是这样的，如果代码好，能预知扩展性，认真负责，肯钻研的，在技术总监里面铁定是有排名的，哪天裁员了或者要分配任务的时候，往往打卡上下班不积极的同事就会被安排无营养的功能 crud 或者无聊的 bug，公司的新架构钻研就分配给认真的同事，等过上 1 年，他们的技术水平就拉得非常开了，公司不行了，技术总监会带上靠谱的跑路或者内推给朋友公司，哪有找工作麻烦的事情，你有项目带上总监，总监也会留肉给自己，生活就是这样现实和赚钱

[scotmouton]

我认为，如果程序员写的代码与实际敲定的需求有偏差，没有达到楼主所说的人性化设计，那是产品经理和程序员拍需求没拍到位或者程序员理解设计的问题；但是如果程序员写的代码质量有问题，运行效率低，健壮性差，那是技术 Leader 有没有规范技术方案的问题，应该考虑的是有没有及时做到 Code Review,有没有代码规范；小弟虽说工作才几年，就自己经验来看，这两点做到了出来的产品基本不会太差，也不存在你说的这些问题。程序员如果想混日子至少也应该保证自己水平能力在平均水准之上也才能混日子，否则那叫拖后腿吧...

[userdhf]

@CF3B5 #158 学习了。。。还是觉得，做事要各个方面的人都要参与进来，一起商量着做，这样既能互相监督，又能互相学习，太分离的职能，估计人事考核会比较简单，大公司估计也有大公司的考虑吧

[muller]

大哥 ，我理解你，不过 我还是想吐槽 [这么简单的需求来这里嘚瑟 ，你咋不自己替 java 程序猿改了呢？] 牵一发而动全身 ，反正就是懒，大家都懒，改了一点 ，还得 测试别的模块有没有受影响，出了问题都要自己担责任，你看哪一个程序猿不受怂逼，谁愿意担责个责任，改好了 是分内的，该糟糕 出错了，就是自己责任，那么多星辰大海，那只是你的而已

[ragku]

1. 不懂得思考产品的开发正在变成编码工具，有一天会被 AI 替代掉的。
2. 说拿多少钱干多少活的，按编码字节收费，看一个月能拿多少？ curd 找个初中生培训一下都能做。
3. 技术总监都找你改了，没问题该改就改，有问题抛出来确认好改不会？
4. 背锅怎样了？都做程序员了连个背锅的胆量都没有，还想升级加薪，当上 CTO，走向人生巅峰？

[LeeSeoung]

楼上太多人台着重于程序员不愿意改变了，你怎么知道人家内心里没有设计，没有想法？拿 1w 的工资去操拿 2w 工资的人的心？按规章办事没错，开发就怕这种上面两个领导的，一个说改成 A，一个说改成 B，有争论，把产品经理一起拉进来讨论，何必隔一层以技术总监头衔来压制后台开发呢，那你又是出于啥目的不愿意把所有相关人都拉进来理清楚，这么简单的事情你为什么又要复杂化？

[noobcoder1]

u can u up, no can no bb.....

[Gea]

@CF3B5 反过来看，现在倒是一个很好的机会，好的团队坏的团队就像好的代码坏的代码，都可以给人很好的经验，往往是一般的代码，让人既不能从中学习好的点，也没有太多可以改正的机会，提升代码水平的机会不多。目前的团队存在比较大的问题，慢慢的改变整个团队，是一个很有挑战也很有提升的经历。156 楼有解决方案，具体的实施方式有很多。楼主计算机理论基础很扎实，应该看一些管理的书了，我个人觉得楼主还是缺乏一定的管理经验和理论支撑。技术的深度，产品的思维，都很重要，但是接下来带队的能力才是能走的更远的必要条件吧。

[win7pro]

1、是我理解错了吗？技术总监不能要求下面的 java 开发改代码？是不是你的管理出了问题？
2、我认为应该是这样的：如果你要改的代码涉及到产品特性，那应该反馈给产品经理，确认后安排你的人改；如果你要改的代码只涉及到性能调优，技术方案，那可以把这位 java 开发开了，当然无论结果好坏都是你承担。
3、在成熟的公司环境，每个员工首要做好的事情是自己的本职工作，即便不过问产品策划或设计，只要能优秀完成自己的任务，都是好员工；感兴趣拓展自己边界的员工值得鼓励，但不意味着就应该项目流程上要求大家都模糊自己的边界参与进来，而是每个职位都需要有一个负责人，你可以鼓励开发员工去多思考产品和设计，最终落地应该是去影响产品经理和设计师的决策，而不是代替他们决策；不然项目将乱成一锅粥。
4、鼓励大家模糊职责边界都参与项目更合适小团队，初创企业，因为人力不足，分工太明确流程太严谨反而会影响项目产出。
5、最后，作为技术总监，感觉你在下属面前缺少威严，可能是管理手段需要优化一下。良好的管理氛围是，你的下属要支持你，撑你，你决定的事情下属需要执行，说的不客气一点，如果下属敢这样反抗你的指令，你完全可以把他开掉，不然其他下属也会知道：原来拒绝执行技术总监的方案，是可以滴！

[ConteMan]

只想知道楼主作为一个技术总监，有没有想过自己在这个事件里有什么问题？

[Mmiracle110]

我觉得过需求的时候，程序员就应该和产品这边沟通是否合理，我们之前也是这么干的，不合理的地方直接提出来。然后讨论，感觉这个没啥问题。但是作为技术总监，你也应该有不合理的地方和产品沟通，而不是直接和开发说把这里改掉。如果改了，产品那边说不认，必须改回来，怎么办？
总的来说，开发是需要理解业务，而不是只盯着眼前的一亩三分地。但是你的做法感觉也是有一定问题的。

[unco020511]

你要增加需求或者改需求本来就要推动产品经理先出文档或者邮件,技术可以提供一些技术指导或者方案,但必须由产品经理发文档或者邮件,技术这边才按需修改,否则不就乱套了吗?
你技术修改了,产品和测试都不知道,流程不就乱了吗?
再说改出问题了谁负责?是你还是改的那个程序员?
测试的测试用例需不需要对应修改?
这些都是问题

[unco020511]

按楼主的意思,按流程就是怕背锅?混日子?你不经过产品经理就私自修改需求,那是你们产品经理脾气好,我们产品经理早在会议上拍桌子了;
你作为技术总监发现了问题,理应先去跟产品经理沟通,确认修改后让他发邮件,这样又快又避免了很多问题;

[Mmiracle110]

@Mmiracle110 补充下之前的回答，如果是程序性能上或者设计上的问题，你要求开发改，我觉得没问题，也不需要和产品沟通，如果开发一次两次不改，可以考虑裁人；但是如果是产品流程上的问题要改，我觉得是需要拉上产品，开发这些人一起讨论

[doing1]

嗯，思考，重要的是思考，不仅仅是执行。

[shikimoon]

我们之前也是这样，每次质疑产品设计就是被怼回来，理由不外乎用户需要的，竞品就有这个功能。导致产品一昧做加法，越来越臃肿越来越难用。结果导致用的人越来越少以至于裁员，反思之后，目前流程都需要有人讨论可行性和合理性，吵架是必要的，千万不要认为吵架伤了和气。也千万不要总是站在自己的立场去思考问题，只关注自己的那一亩三分地，认为程序猿就是写代码的，产品让做成什么样就是什么样，不然一个产品永远也做不好，自己也不会有提升

[lonelygo]

@version 所以楼主根本没必要和这种 CRUD 工程师计较什么，既然人家要废自己，那就目送好了，而且为了业务安全 D 这种活都不给他。

[WispZhan]

这些都是没有灵魂的。 真正一个有灵魂的人，不论做什么都是想着如何做的更好。真有好的办法和点子，会主动找产品和负责人沟通。

---

巧了，前几天我也和同事聊起这类问题。我认为互联网企业里的“工程师”应该对得起“工程师”这个头衔。而不是真正的一个程序员！

[version]

@lonelygo 其实楼主的情况看得出是小团队的创业企业，之前的技术总监带不动跑路了，后来楼主入职了，要求改，小的都能顶嘴，然后我是看不惯那么多人说楼主，流程什么的，也要区分情况，那么多人回复其实不是现在互联网的通病么，支付宝为什么那么卡，那么多年了，说白了就是没人敢提需求，没人敢动，很多应用都是第一版完美，越更新越卡，企业到了一定人数其实就是权斗，一周一半时间开会某行需求都能扣字眼那些，大评审下来到开工可能历经 1 年，喝喝下午茶过过日子，写写 ppt, 最怕就是大企业出来的人当技术总监，框架完全就是在大企业没机会练手然后拍板定下来，遇到问题也是忽悠手下加班解决，大企业也知道这些问题的，招那么多技术也是底面和储备，免得真遇到互联网 ai 抢人也不会血亏，平时复杂的都是外包，国内各行各业也是这样

[linZ]

@lonelygo 出了问题谁的锅。。这个问题解决了，谁都可以改的