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

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

appmanagecluster

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

大部分程序员上班都是为啥？混口饭吃啊。产品做的不够好关他们啥事，你去帮说需求啊。上班做的东西是他们感兴趣的东西吗是他们就算不工作也有动力做的东西吗，这个概率很低吧，不感兴趣还自己设计啥，程序员愿意像你心目中的那样，也挺好，为了项目能更好嘛。不是那样的，也没问题，把功能实现把需求实现做了份内的事了，道不同罢。有啥子用？能加上产品工资份不，能发奖金不。不差面包，去做自己想做的，何尝不会把项目当儿子一样捧着，何尝怕不自行参与产品设计和优化。你的想法可以有，但凭啥强求别人要认同你的想法，你给面包吃啊

hanlyjiang

2019-07-21 23:43:32 +08:00

在不同的位置，关注点是不一样的。建议换位思考一下，另外多一些宽容，共同协作一起磨合成长。
举个例子：
目前在组内的角色是个开发小组长，作为这个角色有一段时间了，虽然本质上我这还是一个程序员，但是会涉及很多需求对接，需求转化为任务后分派，以上是背景。
但是我觉得非常有意思的是，分配下去的任务，总会有那么一些地方不尽如人意如人意，比方说一个功能相关的流程没有考虑周全，又或者一个 UI 元素和效果有偏差，又或者实现上不注重后期扩展等等，总之就是我觉得应该是他们应该能做到的，没有做好。（当然，等我检查之后，再提出来，他们也会很配合的去做。）

这确实是个很有意思的问题，因为回想一下我之前做某些功能开发，也是这个样子。关于这些，我考虑了下之前自己为什么这么做，我现在为什么会考虑得更多，要求的更严？他们在什么情况下会做成这个样子，什么情况下又做的比较好一些？

考虑总结了之后，我觉得很重要的一个原因就是，对于开发角色来说，他们的任务是我分派的，他们其实对任务中可松可紧的或者模糊不清的地方无法决策，另外，还有时间的限制，在这种情况下，

1. 一般来说，会默认认为任务合理（默认认为任务布置者已经想清楚了），即只需要负责开发实现就完了，其他的不会想太多；
2. 都会采取先实现功能的策略，至于那些无法抉择的，不会去理会。 当然还有一些其他的原因。

针对我以上的这些结论，后续工作安排的时候我做了一些调整：

1. 考虑到他们会默认假设我布置任务时，任务的流程方向等等已经没有问题了，所以我会尽量在任务下发前，将任务在自己这边过一下，看没有什么可能是在这个任务描述之外额外的工作，或者可以优化改进的地方，这些内容我会在下发任务的时候，尽量说清楚，另外如果实在没有时间详细考虑，也会特别交代清楚；
2. 对于一些存在疑惑，在他们那个层面可能无法抉择的，我会尽量确定拍板下来，比方说对于一些 UI 界面，我会自己提前给他们设计好，自己画出设计图（组里无 UI ），什么颜色，什么字体，什么间距，都确定下来，因为这些东西只凭口述或者文字描述，他们就无法决策；（我也深深的知道对于一个没有决策权的开发来说，做一个只凭口述的界面是如何的纠结）

经过一段时间的实践，我发现他们交上来的成果确实会更好了，更加符合要求，

但是在一些关乎他们主动性的对程序的主动改进方面，他们并没有什么提升，但是这个我并不怪他们，如果他们能有这种意识并且做到了，固然好，如果没有，那这就是我应该考虑的问题，我应该考虑如何才能让他们注重这些，如何调整工作安排或者要求调动他们去达到这些要求。

LeeChP

2019-07-22 02:00:53 +08:00

楼主应该就是我最讨厌的那种人了。

产品设计，需求分析的时候不提出来，开发要结束了，这不行那不行。还要给人扣上没有产品素养的锅。

想起来当年，和上头争一个方案，总之据理力争，一句话打回，按他说的做。行吧，我负责 coding。项目到中期的时候，这个改回去，那个改回去。最后整个全改成了我当初提的方案，我那种愤怒的心情，到现在想起来依旧咬牙切齿。

知道我他妈后期工作量有多大吗？牵一发动全身，整个架构全推翻，每天双倍工作量，还优化个几把，最后我也不管了，只堆功能。我一个方法写三四百行，我直接不玩了，开了我更好。

一次我忍了，第二次又他妈来，我直接吵，最后我直接收拾东西打辞职报告，要跟我重新谈待遇我都不搭理。这次让我对企业开发有了极大的恶心，直接回家打了半年游戏，还是自己写代码舒服。

所有的模型，需求，前期尽量做好，后期改动，请找产品沟通，最后重排工期，少他妈的逼逼。

sampeng

2019-07-22 08:28:07 +08:00

楼上在都揪着流程问题在声讨 lz。但实际楼主要讨论的是这一代新生研发要不要做 code 以外的事。
诚然面向工资编程是对的。但，工程师不是能是只 code 啊…这样的人抱怨青春饭我觉得就是自己作。眼铮铮看着产品被带沟里然后跳槽去下一家。最后时间长了手上一点核心竞争力都没有。君不见每个公司的靠谱程序员都是要和产品怼天怼地怼空气的。整个大环境和谐的团队真没见几个能成功的。lz 并没指明需求定了就研发私自改这一件事是正确的
我想 lz 想表达的是，需求定了，这事做的时候发现不对劲是要提出来去怼产品的。怼不过就升级怼。要坚持总是在做正确的事。这个思想一旦在团队内建成。大部分情况就会提升到需求确认的时候，就完美的符合前面各位说的所谓流程问题。但是
如果研发只是 coding …不做思考。这事就得 leader 一个人来干。真的会累死的。
所以我觉得 lz 不应该要求所有研发都如此。但最少小组长是这个特性的。人员分层是社会分工的必然进程。