想必大家都听说了，这两天关于中国平安一个产品经理因奇葩需求和程序员爆发肢体冲突的事件在朋友圈被刷屏，更有现场打架视频在技术群里疯传。
在这里先带大家简单文字回顾下事情经过，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 一下就能找到答案的问题，节约双方时间；
缕清用户流程，不要让他们来处理你的工作内容；
想清楚产品可能出现的各种状态（404、零数据、极端用例、转场……）；
该你决策就由你来决策，不要分担责任；
相信他们的技术水准（如果他们确实不会，他们会学）；
勇敢承认你的错误；
记得给他们展示用户/客户的反馈；
改需求不要超过 3 次，再改就先跪下；
就算月饼被抢了，也要友爱和睦相处。
「 给项目管理层的建议 」其实，谁都有想不到的地方，和想不明白的东西。但是自己都没有搞懂之前就觉得只有自己是对的，那就只能撕了。
在我们公司的团队里，程序员和PM一起讨论需求，勾画原型，提出自己不同角度的不同理解，让程序员更接触“原始需求”，能参与到产品的生命线里会更好，毕竟每个人都有思考能力，不是机器，一张需求甩过来就照做的程序员不是好的程序员。
在产品需求会议上，允许程序员参加并发表意见，这样可以从技术的角度及早发现产品功能中存在的问题，从而避免后期需求的频繁改动。
这也是大多数比较有经验的互联网公司的常规做法。
「 结尾 」身在江湖，谁都不易，只要换个角度思考，互相多点体谅，这种矛盾自然就可以化解。
文章最后，如果想彻底解决pm和coder的矛盾冲突，土叔有个不成熟的终极方案，朋友们不妨一听：
产品/UI每天给程序员提任务，程序员每天给产品做任务。
如果同一个人可以分饰产品/UI和程序员两角，那么他就会变成永动机。
这款永动机有个广为人知的名字，叫做独立开发者。