最近看到深圳的一条新闻，程序员砍产品经理新闻，这是什么仇什么怨，才能有这么大恨。
后来又看到朋友转的一则改编的小段子，如下:
-------------------------------------------------------------------------------------------
产品经理下了一个产品的需求。
作为开发程序员拿过来一看，好嘛，写的挺详细的，我按照你写的开发。于是幻想着，这几天辛苦，加加班，做完这个可以小小休息一下，还有奖金拿，拼一拼也值得。
开发完了，交给客户，客户说，你这做的是啥嘛，就不是我要的。
好吧，程序员去找产品经理。
于是 就有了下面的对话。
程序员：客户说，这需求不是客户要的，客户要的是这样这样的。
产品经理说：怎么可能，我和客户聊的时候就是那样的。
程序员：怎么可能，客户刚才说了，就不是那样的，不信，你问问客户。
产品经理于是打电话问客户。
过了一会儿，产品经理走过来对程序员说：客户的需求变了。你加加班，我再写个需求，咱们把这个产品完善了。产品交货的时间紧，要不元旦你就别休息了。
程序员当场崩溃：加你妹啊。老子因为这个产品，一个周都没见女朋友了，都不知道女朋友现在还是不是我的。
产品经理：客户就是上帝，客户说改，你就得改。
程序员：你妹的上帝，信不信我砍你。
产品经理：你敢砍上帝？
程序员：老子砍的就是上帝。
于是上演了 一个需求引发的血案。
----------------------------------------------------------------------------
这个段子中，我觉得起码在以下三点存在问题:
一、管理上存在漏洞
二、员工情绪失控
三、绩效与奖赏制度不合理
一、管理上存在漏洞
我看到这个段子，首先觉得这是个小公司，工作中没有一定的流程和规则。
1. 当再现问题时，程序员第一时间不是找项目经理来裁定，而是直接找到冲突方。从原则上说，程序员应该对项目经理汇报，而不应该直接找到客户。
2. 项目经理需要控制需求。可以直接控制（小公司、精简模式），或者指定系统分析师或者产品经理作为唯一或者专项的对接人。
3. 和客户的需求确认没有规范的流程。应该采取需求采集 --> 需求梳理 --> 需求引导 --> 需求确认四步。对于确认，一般需要留有纸制确认书或者确认邮件，以记录约定的需求范围和技术指标。在本例中，如果有冲突，可以拿出确认书进行对比，是谁的问题，一目了然。客户后期要调整，需要走需求变更流程。
4. 项目开发流程不清晰。开发根据瀑布式或者敏捷模式，一般都需要经过 需求分析 --> 需求评审 --> 需求评审(可略) --> 分析和设计 --> 设计评审(可略) --> 需求交底(开发测试反讲需求,可略) --> 开发制作 --> 交付测试 --> 交付验证(一线或者产品先部署在测试环境检验无误后再布署在正式环境中) --> 正式交付。 上例中如果团队按照正常的流程运作，不会出较大的冲突，因为已经将冲突提前解决了。
二、员工情绪失控
情绪控制原则 :
1. 先处理情绪，再处理事情。
2. 对事不对人。
3.当无法解决时，将问题升级。交由PM协商解决。
这些处理原则，PM应该事前在项目团队中说明，以便项目成员执行。
三、绩效与奖赏制度不合理
程序员不清楚本次工作的奖赏制度，程序员和产品经理之间也没有奖赏联系。致使大家都是公对公，只站在自己的角度看问题。
如果这个任务的利益和整个团队都有直接的关系，那么情况可能就完全不一样了。
任务与月、季、半年、年度的奖赏如果挂勾，就不存在长时间的扯皮，而是会一起想办法解决问题了。