「深度剖析」程序员由于奇葩需求暴打pm，而后被双双开除

「 前言 」

想必你们都据说了，这两天关于中国平安一个产品经理因奇葩需求和程序员爆发肢体冲突的事件在朋友圈被刷屏，更有现场打架视频在技术群里疯传。

在这里先带你们简单文字回顾下事情通过，N次打架视频和截图就不给你们放出来了，相信你们都在技术群和朋友圈里亲眼目击过了（固然，没看过的朋友能够找我微信私聊），最重要的一点是为了社会和谐。

「 肢体冲突的原由 」

如下是网上流传的本次打架事件的文字叙述：

「 事件的处理结果 」

事情的原由大概就是这样，先不讨论本次事件中pm提出的需求是否合理，程序员可否实现，自己这起办公室冲突事件的发生，引发了圈内很大的热议，“成功地”推上了互联网热点头条，同时也给中国平安公司的名誉带来了负面影响，最后涉事的两位外包人员惨被双双开除。

不少看过现场视频的网友是这样分析的，秃头的是程序猿，没秃头的是产品，伪装劝架的是运营和设计，看戏的是测试，拍这个视频的应该是商务，pm下次记得戴安全帽提需求。

分析地头头是道，活脱脱一个国内社会看热闹不嫌事儿大的缩影，也是厉害。

「 如何向外行解释内情 」

可能一些非软件行业内的吃瓜群众，想不通为何程序员和产品经理要干架？我彻底能够经过一张表情图合集，来生动形象地告诉你，一家软件公司的项目是如何上线的。

「 打架是不对的 」

看完这张图，咱们再来讲说pm和coder打架的事儿

年轻人血气方刚，一言不合就互怼，借用孙红雷在电视剧《征服》里的一句台词：不气盛，还叫年轻人吗？

可是，以暴制暴是不对的，朋友，毕竟就算打赢了也是真的疼啊。

在乱提需求的前提下，至少得练得跟我同样吧。

否则，还真不必定打得过我，说一下我三大项的数据吧：

• 卧推：90kg
• 深蹲：140kg
• 硬拉：160kg

「 冲突的根源是什么 」

先来讲说不少公司的现状：产品经理和“老板们”关起门来开了个会，赶出原型和UI图，以后交给程序员们的就是“圣旨”，“反正咱们就这么定了，你照着开发吧。

程序员说：目标是需求，技术只是手段。
产品经理说：目标是用户，需求是方式。
立场不一样，定位不一样，矛盾就来了。

产品经理永远是用户需求的代名词，自觉得是研发人员的上帝，动不动就要改需求，他们以为好像很简单的事情，却不知给程序员添了多大的麻烦。

技术和产品撕逼，无非就是如下几个缘由：

1，产品没有想明白，而后来来回回的改；
2，开发没有理解清楚需求，开发东西和产品的要求有出入
3，产品的需求有问题
4，技术的时间不够用

因此说，一个不懂项目管理的程序员不是好程序员，一个不懂软件开发的产品经理，不是一个好的产品经理。

程序员和产品经理彷佛天生就有不可调和的矛盾，和平共处很难么？

「 说点掏心窝儿的话 」

就此次事件，土叔我不站队，也不说谁对谁错，抱着一颗同理心，我分别来站在程序员、产品经理，以及项目管理层的角度，给coder、pm，以及manager分享几点个人小想法。

「 给程序员的建议 」

程序员和产品经理干架其实须要理性，查查他的经历，要分析下他懂不懂技术，懂的话有多懂。

通常很懂技术的产品经理是不和程序员干架的。
懂一点，可是就拿出来讲事的这种，通常和程序员关系很差。
一点都不懂的产品经理有的谦卑，有的不懂装懂乱说一通。

对于懂一点，就拿出来讲事的这种，就要想法设法在技术上反问他，让他以为本身其实真的知道的不多。
这时候再动之以情，说明本身作这个的难度。

对于不懂装懂的产品经理，就俩字：你来。

还剩下一种是不讲理的，对于这种不讲理的就只有一句话，我他娘的意大利炮呢？

玩笑归玩笑，土叔在这里分享几点走心又走肾的建议：

作好需求更改的准备，提升代码的扩展性和可维护性；

预留出修改bug和需求的时间；

对需求理解透彻再开始写代码；

代码不要写死，防止需求变更。

「 给产品经理的建议 」

好多pm搞不懂，为何产品经理频繁更改需求会令程序员小哥哥们烦恼不堪？我想，大多时候是由于大家pm平时在工做中的这些口头禅吧：

1.「先作出来看看吧」
2.「我就要这种效果，怎么实现是你的问题」
3.「这应该很简单吧，不就是XXX，而后XXX吗」
4.「这个需求，先这样这样，再那样那样，用XX技术很快就搞定了」
5.「你就说能不能作吧」
6.「我有一个绝妙的idea，什么都准备好了，就差一个写代码的了」
7.「这个需求老大已经赞成了，你照着作就是了」

产品经理频繁的需求变动，和程序员有限的工时是存在矛盾的，除非让程序员加班。特别是上次的变动刚刚改完，这时又提出再次修改，朝令夕改，一步一步很巧妙地惹恼了程序员。

程序员最讨厌朝秦暮楚的产品经理了。

如何与单纯的程序员共处，土叔的走心建议要不要听一下：

不要随时打扰，尤为在他们戴着耳机的时候；

传达「要作什么（What）」，还有「为何这么作（Why）」；

学习基础开发知识（好比 HTML/CSS），方便彼此沟通；

不要让他们成为最后知道的人，一块儿讨论能够少走弯路；

尽量用数听说话；

配合工具（哪怕是纸笔）来表达你的想法；

提供有用工具给他们参考（好比 AniCollection）；

作好设计规范（我的很喜欢 Mavel 的 Styleguilde）；

尽量和他们坐在一块儿；

他们可能羞于/不善于表达，多给一些耐心；

不要很差意思发问，其实他们都很热心解决问题；

不要问那些 Google 一下就能找到答案的问题，节约双方时间；

缕清用户流程，不要让他们来处理你的工做内容；

想清楚产品可能出现的各类状态（40四、零数据、极端用例、转场……）；

该你决策就由你来决策，不要分担责任；

相信他们的技术水准（若是他们确实不会，他们会学）；

勇敢认可你的错误；

记得给他们展现用户/客户的反馈；

改需求不要超过 3 次，再改就先跪下；

就算月饼被抢了，也要友爱和气相处。

「 给项目管理层的建议 」

其实，谁都有想不到的地方，和想不明白的东西。可是本身都没有搞懂以前就以为只有本身是对的，那就只能撕了。

在咱们公司的团队里，程序员和PM一块儿讨论需求，勾画原型，提出本身不一样角度的不一样理解，让程序员更接触“原始需求”，能参与到产品的生命线里会更好，毕竟每一个人都有思考能力，不是机器，一张需求甩过来就照作的程序员不是好的程序员。

在产品需求会议上，容许程序员参加并发表意见，这样能够从技术的角度及早发现产品功能中存在的问题，从而避免后期需求的频繁改动。

这也是大多数比较有经验的互联网公司的常规作法。

「 结尾 」

身在江湖，谁都不易，只要换个角度思考，互相多点体谅，这种矛盾天然就能够化解。

文章最后，若是想完全解决pm和coder的矛盾冲突，土叔有个不成熟的终极方案，朋友们不妨一听：

产品/UI天天给程序员提任务，程序员天天给产品作任务。
若是同一我的能够分饰产品/UI和程序员两角，那么他就会变成永动机。
这款永动机有个广为人知的名字，叫作独立开发者。

---

更多文章我会第一时间更新在公众号<闰土大叔>里面，欢迎关注~