「深度剖析」程序员因为奇葩需求暴打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.「这个需求老大已经同意了，你照着做就是了」

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

程序员最讨厌朝三暮四的产品经理了。

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

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

2. 传达「要做什么（What）」，还有「为什么这么做（Why）」；

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

4. 不要让他们成为最后知道的人，一起讨论可以少走弯路；

5. 尽可能用数据说话；

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

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

8. 做好设计规范（个人很喜欢 Mavel 的 Styleguilde）；

9. 尽可能和他们坐在一起；

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

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

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

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

14. 想清楚产品可能出现的各种状态（404、零数据、极端用例、转场……）；

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

16. 相信他们的技术水准（如果他们确实不会，他们会学）；

17. 勇敢承认你的错误；

18. 记得给他们展示用户/客户的反馈；

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

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

「 给项目管理层的建议 」

其实，谁都有想不到的地方，和想不明白的东西。但是自己都没有搞懂之前就觉得只有自己是对的，那就只能撕了。

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

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

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

「 结尾 」

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

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

产品/UI每天给程序员提任务，程序员每天给产品做任务。

如果同一个人可以分饰产品/UI和程序员两角，那么他就会变成永动机。

这款永动机有个广为人知的名字，叫做独立开发者。