写这篇文章不是为了凑热闹，更不是为产品经理辩驳，最主要目的是分析问题、分享见解和受到的启发。

目录导航：

一、我对此事件的看法

1. 对事件真实性甄别的必要性

2. 对事件本身和两位主角的看法

二、我对程序员和产品经理之间行业矛盾的见解

三、我们从这个事件中能得到的启示

1. 职场处事方面

2. “需求-开发”流程和规范性方面

最开始看到这个事件，是在8月3号。讲真，当时的兴趣点是凑热闹，对于主角是程序员和产品经理并未留心。

3号当天，微博上、新闻上、各种微信群里都出来了，群消息、朋友发给我的消息内容多是对程序员和产品经理关系的调侃（其实更多的是对产品经理），才感觉不是我在凑热闹，而是我被凑热闹了。

4号在知乎上被邀请回答问题（对此事做评论）时，发现这个事件已经有250多万次浏览量了，而且点赞量最高的评论多是暗讽风格或直接对行业问题诟病的，我觉得，有必要发表几点拙见。

即使事情是假的，也从侧面反映出一个问题：程序员和产品经理间的茅盾是客观存在的行业问题。

为什么呢？

如果行业中不存在这种矛盾，假新闻很难被人相信并传播。

写这篇文章不是为了凑热闹，更不是为产品经理辩驳，最主要目的是分析问题、分享见解和受到的启发。

二、我对此事件的看法

对于这个事件，我的思路如图：

在此表达自己的主观意见：

1. 事件的真实性甄别的必要性；
2. 站在中立的角度表达对打架事件的看法。

1. 事件的真实性甄别的必要性

如果此事件内容全部是真实的，即：是平安的打架事件&主角是产品经理和程序员&手机壳颜色识别的需求引起的打架，那么有必要去评论、去思考。因为从这个反面教材中我们能够得到对程序员、对产品经理的岗位认知，更能够对今后的职场处事原则有很大的正面启发。

但是，如果事件内容是假的，那么经过微信群、朋友圈、微博等各种文章的渲染后，我们很容易由于这个事件对程序员、对产品经理日常工作产生错误认知，进而是不合理的评论、误解或嘲讽。

热闹是凑了，但对两位主角是伤害，同时也会给外行人留下“程序员容易动怒，产品经理总是提混蛋或无知的需求”的印象，实际中不是这样的我可以说，程序员绝大部分很好沟通、不会轻易怼人，同时产品经理也不是这么强势和混蛋的。

结论：假消息造成的不仅是对当事人的负面影响，同时也会让外行人对这个行业、这两个岗位的人及他们之间的关系形成错误认识，进而是误导更多的人产生认知偏差。

因此，如果热闹看够了，对新闻/消息产生质疑是有必要的。

2. 站在中立的角度表达对打架事件的看法

假设、假设、假设，事件内容全部真实，完全就事论事，我的看法有这么几点：

（1） 对这个事件本身

这个事件暴露出程序员和产品经理之间的沟通问题值得深思和反省，在下面第三大点我专门给出了自己的见解。

（2）对两位主角的看法：动手打架，两人都不对

不良后果有：

1. 自己被开除，在网上出名后，后面找工作多少会有障碍 —— 对自己和家庭；
2. 自己所在的外包公司也会受到牵连，可能会被甲方责难或罚款，这又牵扯到钱的问题了 —— 对自己所在公司；
3. 对甲方的声誉有负面影响，若不良影响再继续扩大，接着就可能影响到股票和业务了。打架本身并不会极其严重，但打架发生的环境会引发严重的后果。

（3）我对这位产品经理的看法

① 流程不规范

正常的流程，如我上面的图示中“是”的步骤那样才合理，哪有产品经理直接找具体实现的程序员直接要求实现某功能的！假设产品经理已经完成了该有的可行性评估、调研等环节，提需求的时候，也应当有正式的通知（例如：文档或邮件），任务由程序员的领导确认或知悉，而不是两个人直接互相沟通和确认需求。

有些产品经理认为前期搞那么多评估是浪费成本，我认为这是胡说，至少技术可行性确认该有吧？评估不做，一旦进入开发，耗费了大量人力、财力后发现不对劲再推倒重来的传统方式更应该摒弃。

也有产品经理认为可以直接先开发，快速上线后根据反馈再迅速改，也就是“小步快跑、快速迭代”，纠正一下，小步快跑、快速迭代本身没错。但再小的步，可行性评估要做、书面需求要有、开发人员的领导要知悉。

② 沟通方式有待改进

即使是程序员直接沟通发生了不快，下一步应当找各自或对方的领导，当着有决定权的领导讲清楚，共同决定做与不做、如何做。

（4）我对这位程序员的看法

当发生沟通障碍时，建议第一时间把事情向上抛，找领导协调，技术领导一般都会站在程序员立场去调解难题的。

try{//沟通} catch{//不愉快} finally{//找领导反馈};或者throw new Exception(“这我搞不了!”)都行啊！（PS：开个玩笑）。

（5）或许还有我们不知道的

最后，我们只从新闻上看到了事件的开头和结果，开头是“平安的产品经理和程序员因为手机壳颜色识别的需求引起了打架”，结果是一段视频和处罚通报：

至于中间两人还经历了什么，我们不知道。会不会，这个需求本身不能实现只是导火索，而引起动手的却是其他原因呢？

因此，即使打架发生了，也不应把事件的起因认定为“无理取闹的提需求”，因为我们并没有了解到事件的全部，甚至连确认过事件的真实性都没有。

三、我对程序员和产品经理之间行业矛盾的见解

这个矛盾客观存在，不仅是程序员与产品经理，早在产品经理岗位火之前，行业中时常被调侃的对象是程序员和测试工程师，还有前端程序员和后端程序员。

难道现在程序员和测试工程师之间矛盾好转了吗？

并没有，依然是吵闹不断，只是产品经理盖过了测试工程师的风头。

为什么能盖过呢？

• 原因一是行业中始终存在操作不规范、业务不熟、沟通能力不足的产品经理，毕竟新人始终存在，这是客观因素；
• 原因二是产品经理的岗位性质就是动手少（动脑多）、提需求多的；
• 原因三（主要原因）是提出的大部分需求都很容易引起争辩甚至激怒程序员的。

虽然岗位性质就注定两个岗位不和，那有解决办法吗？当然有。

① 若是产品主导/运营主导/市场主导型公司，这个问题解决起来更容易，毕竟开发人员的发言权是不足的，但弊端同样有 —— 即产品/运营/市场总会提出不专业或天马行空的想法给开发人员，不仅不切合实际，开发完后推倒重来、浪费人力财力的情况自然增多。

那矛盾怎么解决呢？

由于做与不做的决定权几乎都在产品/运营/市场手里，所以他们的专业能力非常高才可以，上游做正确的事，引导下游正确地做事，有了良好的成效和用户反馈，矛盾自然化解。

为什么有些公司对产品经理、运营人员要求那么高，知道原因了吧？

② 若是技术型主导的公司，或者是技术和产品/运营/市场不分高下的公司，这两类公司实在太多太多了。那这个矛盾处理的关键就靠两个字：“情商”。

这里不仅要求产品人员的能力高，更要求懂很多职场处事技巧、懂一点点开发技术原理。职场处事原则例如经常与开发、测试的同事聊天，偶尔买点下午茶一起吃，遇到直接冲突想办法化解情绪层面的问题，耐心听完再接着就事论事，解决不了不要直接争论，马上转向找领导、向上抛。

如果能力不高例如专业技能不足，一旦做了错误的产品决定、浪费了开发资源，接着就是被程序员抱怨；若能力够足但不会“处关系”，一样是工作难以推进。

总结：矛盾解决办法最主要是产品人员要有足够的职场处事、沟通协调能力，二是产品人员专业能力强，能够引导正确的产品走向，三是开发人员应适当理解产品经理的处境。

自己身边的真人真事：一个朋友，产品人员，很少玩游戏，不懂开发技术，金融专业知识还是进公司后才现学的，在产品经理基本技能还不错的情况下，凭借另一点顺利开展的工作——他在手机上下载了王者荣耀自己试着玩多个人物，之后午休时与开发的同事们一起玩，聊工作前掺杂聊聊游戏，还不错吧。他说，玩这个游戏的主要目的是跟同事们有话聊，其次是娱乐。

四、我们从这个事件中能得到的启示

1. 职场处事方面

• ① 最高的水平是关系处理的融洽，压根没有不愉快发生，产品经理首先应多学职场处事技巧，其次才是专业技能。
• ② 若由于个人不会处理关系、不擅长沟通，办法是有争执时控制自己的情绪，不要轻易动怒，再大的怒火，先想想后果。

沟通 = 70%情绪 + 30%的内容，发生不理智的争辩时，不良情绪就占据绝大部分了。

这里的关键点：沟通不畅时，立即停止两人私下交流甚至是争辩，因为对解决问题毫无意义，结果往往是越交流越糟糕，应该直接抛出问题、向上找领导调解，把对方的领导和其他相关人员拉到一起，一同决定。

2. “需求-开发”流程和规范性方面

根据我上面的第一张图，如果流程走的规范，会引起激烈争辩的事情基本不会发生在程序员和产品经理之间。

那还有其他方面的需求用不着这么规范的流程，或者必须程序员和产品经理直接沟通的问题怎么办？

若是产品经理，应自己先做足可行性评估，这不是为程序员做的，而是为产品和需求本身做的。这些工作到位后，找程序员先讲明目的、再讲此需求的积极意义和评估结果，走到这里应该可以说服大部分程序员了。如果仍然沟通不畅，就找他的领导协调，依然推不动，就找自己的领导，一起去找程序员的领导沟通。

若是程序员，遇到产品经理直接提的需求，可以表示质疑，要求对方讲清楚需求的目的、意义和评估结果。若他讲不清楚，可以拒绝并反馈给自己的老大有这个事，让老大决定。若产品经理说的让自己折服，那也要反馈给老大，让老大来安排开发排期。

最后：实际工作中产品经理总会提出让人啼笑皆非甚至无理取闹的需求，这个不争的事实是我们产品人员需要不断改进的地方，共勉。

本文由 @产品经理王梓任 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议