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

[CF3B5]

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

[clayyj1210]

131 楼后面说混日子的部分不说。
131 楼举的例子 spring、git、tomcat、apache、linux 内核，这几个例子不算好例子。这几个例子，程序员既是产品的开发者，也是产品的用户。但实际上在开发产品的过程中，程序员是开发者，但不一定是用户。这里对用户的定义并不是那种打开一次应用就算了。

[Torpedo]

都说国外程序员开发的技术项目多，国内程序员都是写业务。
结果国内程序员业务都不愿意去了解，推动。。。

[LeeChP]

粗暴管理就是粗暴管理，少扯那么多。你问问林那厮一个人能开发出现在规模的 linux 么？你问问比尔盖茨能开发出现在规模的 win 么？
这个制度是你们公司定的，有本事骂你们 ceo 去，关程序员屁事？
你就是改了没问题你拿功劳，出了问题程序员背锅的那种人，在你手下干活的那帮人可算是倒了血霉。

[sxlzll]

@weiqk 考虑问题不要总是极端化，对产品业务有一定的认识不是让你取代产品经理，打个比方，如果每个角色都只懂自己的专业能力，哪怕个个都很强，也会像复杂机械却没有润滑油一样，所以需要一部分人能力图谱比较宽，并且和其他上下游角色有一定交集，事情做起来才更“润”，也有人互相为对方纠错

[cherishd]

@Torpedo 至少在我们公司开发了解业务是 p 用没有的，也不是我们不想了解，需求分析根本不带开发能怎么办，再说你了解了能按照你的意思改么？产品说的话你能不听么？产品说领导要求的，跟你了解的流程不对，你改还是不改？自己改了出问题了，谁的责任？形式所迫而已，我们也知道业务有问题，我们就能按自己意愿改了？挣钱已经不容易了，为啥还要自己找锅背？

[Aresxue]

@CF3B5 怕背锅是重要因素，但不是主要因素。。。软件发展到现在，稍微有点用户的系统业务复杂度都太高了，别说程序员，就是所有的产品经理加一起都未必能搞懂业务和用户需求，分工是必要的，各自关注自身职责也是必要的，设计模式都有个单一职责原则，对于工程师来说把产品经理的想法能接近理想的实现就已经很不容易了。人的精力都是有限的，有人追求深度有人追求广度，没必要强行要求。

[QQQQQQQ]

开发对需求的参与及讨论应该在需求落地前，而不是已经出了需求文档。当然我理解的文档应该是需求详述了。这个时候再改，我认为确实应该通知需求去评估，而不是只要求开发去改动，这样后期出现问题的时候，锅就扣自己头上了，还可能牵扯到绩效等一系列问题。我认为一个开发在需求落地时期去明确需求和了解整体业务是没有问题的，但是真正到了开发阶段再要求去修改就不能只针对开发一个人说了，既然是团队，还是得按照流程来的，之所以有规则，不还是大家多年摸索出来的吗。

[Gea]

1.楼主是技术总监，让手下改点东西，不管是什么理由（合理或者不合理），手下能吵起来都不改，楼主在团队里真的是一点权威都没有，一点管理能力都没有，我觉得先想想自己的问题吧。至少我的总监让我改代码，不管怎么样，我还是会改的，楼上说责任的问题，真到最后，我肯定会说是总监让我改的，这点大家都看着。

2.闻道有先后，术业有专攻。你说张小龙，马化腾等人又做技术又做产品，这种人拿出来举例子没什么用，有多少做技术出身的创业失败的，他们不也是懂技术又亲自做产品，依然创业失败？这种东西不拿数据出来说话，没有什么说服力的。

3.现在是一个合作的时代，不是单打独斗的时代，把背后交给队友，全力做自己的事情。你看不起你们公司的产品经理，但是有些方面人家肯定比你强。如果你们产品经理真的什么都不行，想想为什么会在这样的公司而不是一个好公司吧。

4.人都有身不由己的时候，可能要忍受傻逼的同事，傻逼的领导，但自己也要恰饭，无法避免的要一起工作。这个时候更应该楼主（技术总监）出马去预先解决掉这些问题，在研发一开始就提出可能的问题，不管是告诉产品方面还是自己手下这些，而不是产出了，才去跨过所有需求流程来告诉程序员去改。不然，这个技术总监，当的也太简单了。

至于程序员打磨产品的精神，我司的情况走的敏捷开发，每次迭代的需求宣讲会和评估故事点，都是研发、产品、测试三方一起来开会的，说起来，产品精神测试同学比我们研发更认真，究竟是你太 out，还是我司太 in，我也不知道，只不过当代程序员的情况应该比你那时候要好，你的时代结束了。

[1cming]

其实楼主的意思我大概理解，但是就像楼上一个 V 友说的一样，不能刚划范围不给权力。
我本身是很乐于去跟产品讨论的，大家相互可以转变身份打磨思维——这是建立在有跟我有同样看法的产品的人身上。
如果对方本身就是比较固执一些的产品呢？甚至好多所谓的产品已经沦为运营的工具了。
这个时候技术想要去反向推产品、运营、业务是何其难。因此权力的意义就在于此。
回到事件本身应该是楼主推动努力跟产品团队达成共识，大家相互打磨。
有的人喜欢去跟产品打磨那就让这样的人去打磨，这样的人后期往 PM 方向培养，当公司有项目时，这类人去带是有价值并且可以拿到结果的；有的人不喜欢去那就让他专注于技术范畴内，挖掘深度，不定期团队内部分享一些知识也是不错的。
无论何时，一刀切都是不适合的。作为 team leader，楼主要学会当伯乐。

[cdh1075]

没有规矩不成方圆，程序员的规矩是按照上级的指示做工作，你想改动你就应该按规矩走，去找他的上级，你这么做表面看是提高了效率，如果人人都这样就乱套了，你这么做是你觉得自己的想法对，产品经理那么做是他觉得他的想法对，先不说谁是真的对，但人人都会觉得自己的想法对，如果第二天一个 xx 总监也觉得自己对，来找程序员改成另一样，你会是什么想法？

[starerlloll]

老板说了算， 你程序员能直接跟老板刚正面？

有的项目从技术的角度上来说就是辣鸡， 但是能赚钱啊，3 个月出了辣鸡产品捞一笔然后暴毙不多的是？还不是拿钱写代码做产品，然后产品失败了换项目？我觉得老板这个 idea 垃圾的要死我能怎么办？ 整个项目毙掉算了？

你去争这个不如离职来的有效率。你钱就给这么多，我 996 还不够，还要我 24 小时为了公司产品掉头发？

楼主最大的问题是把工作 和 兴趣混在一起谈，我自己的项目我反复打磨一个星期都没问题， 但公司的项目，团队里每个人都这么搞，需求还定不定了？工期前做得完么？ 公司倒闭了楼主给大家发钱么？

[userdhf]

楼主我跟你想的一样。别的不多说，了解需求，能避开许多产品留的暗坑。而且长期来看，这是一种学习和经验积累。现在的人都太浮躁，也没有那么团结一致，各种西方传进来的分治思想和公司制度搞得企业内部各个部门和职能有巨大的鸿沟。
我们一直是强调，集体力量大，但是呢。。。

[TingHaiJamiE]

楼主说的特别好，也特别对。但是现实情况就是有一些开发人员只对文档负责，一点也不多想，一点也不多做。很难改变。

[NickBlablabla]

我 jiao 着 LZ 发到这里的帖子也是在做调研、验证。

[CF3B5]

@Gea 其实我们也是每次必带程序员，而且还千叮万嘱说你们要好好想清楚啊，但是问题还是架不住这帮人不肯动脑子啊！说白了就像这楼里头的一些人，潜意识里头就觉得公司做的这个产品和自己没关系的，按照流程他就只是个敲代码的，产品设计成什么样子都是产品经理的锅，他们唯一考虑的就是技术上能不能实现而已，至于产品是否合理根本不再考虑范围内啊……！
作为技术总监，你和他分析说这个需求，其实可能用这样的框架这样的技术比较好把，这样子实现起来会更合理，以后需求变更也更方便等等！这些人要不给你来句这个技术我不会啊，之前没做过啊，公司在招一个会的把！要不说我的办法能实现啊，能做出来就行了，考虑那么多干什么，可是一到改需求时候这些人就哇哇叫了……最后经常的结果就是我自己懒得和他废话，把门一关一晚上搞完了，收工……无语！但是真心 TMD 累啊……唉！
软件开发真的是团队活，但是说真的现在年轻一代的程序员，你们真的清楚什么是软件工程师吗？你们究竟有多少人认真看过《代码大全》《设计模式》《重构》《程序员修炼之道》这些书了？你们真的明白这些书里面写的各种坏味道，各种代码、设计的目的是什么了？尽管很多人现在的水平不足，但是你们真的觉得按照自己现在这种等着产品经理给自己安排开发需求的状态，就慢慢能变成书中描述的那种软件工程师和程序员了吗？
作为一个老程序员，我也很为现在这种程序员就是青春饭的模式打抱不平，但是真的看到你们有些人的回复，真的也是挺心寒的……

[lonelygo]

这么多楼，不想一一看了，这是属于老生常谈的问题了，直接放我的结论。

说难听点：任何人，做任何工作，不愿意去突破“自己给自己的边界”，无法成长，难成大器；

说鸡汤点：我们需要更多的去理解别人的工作，这样我们才有可能站在对方的角度理解别人工作的难处与不易，我们才能更好的在自己的工作职责范围内，尽可能的去帮助别人一起进步；

说正常点：
写代码的目的是为了实现某个特定的功能，一些特定的功能组合起来，我们称之为“产品”；只有站在产品的角度去理解需求，审视代码逻辑与设计，才有可能“避坑”和“改来改去”；
当你是更高的段位的程序员，能理解产品方向之后，面对 PM 的需求，你可能就会主动和对方沟通，“未来这里会不会有这样的变化，哪里会不会增加新的功能……”，你会“理智”的在设计阶段就留出应对未来变化的结构和抽象方法；
当你段位更高之后，你关心的是架构与产品层面之上的问题，而不是写几行代码或者改什么功能；

所以，对于楼主而言，这样的程序员，吵大可不必。
安排一次不听，我给你讲一次道理，听进去，配合则好；
安排一次不听，我给你讲道理，还不配合，这次就这样，我相信这也不是不改地球就要爆炸的功能；
再安排一次，还不听不配合，那就最多再给一次机会；
三次之后，恭喜你裁员的时候有了第一个候选人；如果没有裁员机会，那么总有增删改查的维护，这些不需要那么复杂，给他干呗，干两年干废了再说。

[AyanamiRei]

行业细分是趋势, 专精一个方面才能做得更好

[CF3B5]

@userdhf 国外对产品经理的定义和国内的完全不一样！实际上现在国内很多公司的产品经理的职责就是模仿腾讯和阿里这些大厂的模式来的，并不是借鉴国外的模式，实话说大厂有大厂的原因，对错不好评价……但是实际上国外的产品经理基本上要么是读 MBA 商科毕业的市场大拿，要不就是从技术做起来的技术大神！像国内这种直接社招的既不懂技术又不甚了解市场的产品经理来设计产品，还给他们扣个高帽子说他们很专业本来就是强人所难！实际上在大部分公司就是沦落成给技术甩锅的可怜虫……

[cnrting]

我敢说楼主的公司一定很乱

[Leigg]

楼主你说的没毛病。
问题在于，现在很多人觉得只是干技术，工资就已经使得他们心里满足了，他们不想多花一点心思了，这批人也就叫做马龙。
而你说的雷军，张小龙那批人，他们可不是马龙。