我们来回顾下“平安打架门”事件：
事情发生在7月，产品经理要求程序员改需求，APP的主题能够根据手机壳的颜色来改变。由于双方沟通不畅产生了矛盾，后来大大出手，后来双双被公司开除。
再来看看事件中两个非常有代表性的角色：
程序员(程序猿)
程序员是一种非常独特的人群，他们不爱沟通，希望活在自己的思维里，耿直一根经，他们有很多自我特点：
1、 非常喜欢跟同样的程序员比技术，就算嘴上不说，暗地里非常喜欢较劲。别的程序员做的很多工作他总是第一时间否定，自己才是对的。
2、 产品经理或者项目经理的死敌，他们不太能理会为什么客户的需求一直在变，他们脑子里只有当初说的初始需求。
3、 固执，绝对的固执，而且善恶分明，打死也不跟自己不喜欢的人交流。
4、 想事情都是第一人称，按照自己的惯有思维去想任何事情，不会换位思考。
5、 嘴笨，特别最容易得罪人，如果一群人团建，他说什么做什么都非常尴尬和腼腆。
6、 很难找到女朋友，所以特别易怒，如果选择对象他们不会找女程序员。
7、 如果有女朋友，往往跟女朋友说什么会用百度去查话题。
8、 大多数程序员极度抠门，对自己抠门，对身边的朋友也非常抠门
……
产品经理(Product Manager)
是企业中专门负责产品管理的职位，产品经理负责市场调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。
他们分两种派别，特征如下：
一、曾经是技术的产品经理：
1、 其实就是程序员升级版，依然固执和嘴笨，不是特别善于表达自己的观点。
2、 总以为自己是对的，要求做出来的东西是大部分人不要的。
3、 想法非常固化，先考虑的不是产品能不能赚钱，是功能能不能实现。
4、 有点闷骚，喜欢茶余饭后在大家面前装的很懂风月。
5、 喜欢装高雅，混迹于各种论坛和峰会，表示自己非常专业。
二、曾经是销售的产品经理
1、 特别喜欢新鲜事物，大部分时间都在讲一些不够现实的事情。
2、 忽悠是家常便饭，能忽悠出资人，能忽悠团队，很多产品到后来都是虎头蛇尾，搞的是全公司战略产品，到最后常常不了了之。
3、 善变，需求每天变化，喜欢天马星空的创新，也喜欢不切实际的梦想。
4、 最喜欢不懂装懂，要在程序员及项目经理面前表现的自己什么都懂，反而会变成很多懂技术的笑柄。
5、 注重外表，喜欢用各种名牌来包装自己心中的没文化和不足。
由于工作角度的不同，往往成就了程序员跟产品经理是天敌的说法。当然，这早已违背了企业的战略目标和产品目标。产品经理应该是客户需求最敏锐的那个人，而程序员则是应该帮助产品经理实现目标的那个人，其实大家的立场是一样的，大家都为了实现公司的新产品创新。
而在这个事件上，我们发现了几个问题：
一、公司体制的问题。
1、 在新产品创新和开发过程，团队凝聚力低下，没有团建来提升团队之间的信任感。
2、 没有形成产品创新的奖励机制，变成产品经理为了自己的KPI，程序员为了自己的KPI，为了工作而工作，大家各扫门前雪。
3、 没有很明确的新产品创新开发流程，产品经理随意朝令夕改提需求，需求都是靠嘴肯定是不行的。
4、 还是按照以前的管理模式来管理创新团队，没有鼓励大家积极沟通和集中办公的办公室氛围或者文化。
5、 新产品创新的方法论及职务职责划分不清楚，还是一群人跟着产品经理团团转。
二、 产品经理自身的问题。
1、 自己在产品创新中需求不明确，擅自改动需求过多导致程序员抱怨。
2、 不会有标杆法，其实GOOGLE早就有了此类产品，程序员又没这么聪明，他们第一反应都是功能有难度或者做不了，给他们看标杆啊。
3、 自我管理及沟通能力太差，作为产品经理首先的职责就是懂用户要什么，然后怎么用通俗的语言跟团队沟通，说服团队，让团队站在公司立场或者产品立场考虑问题，而不是功能立场。
4、 体能太差，整个大家过程有70%是程序员揍产品经理，知道自己体力不如人还去打架，肯定做不好产品经理。产品经理要非常了解自我产品的优劣，和市场上的竞争力，明明知道自己打不过，还硬打肯定要输。
5、 如果打架过程是产品经理指挥测试和架构师狂揍程序员，说明他是一个懂市场分析、有战略眼光还有领导力的人，视频看来，他没有。
三、程序员的问题。
1、 只会用自己的思维看事务，没有换位思考，其实产品经理需要的功能是真的对产品有或者没有帮助，第一反应就是程序员职业反应，做不了。
2、 沟通能力和涵养比较差，如果觉得真的自己做不了，可以跟大家沟通，或者推掉这个任务，让能做的人去做呗，干嘛揽在自己头上。
3、 没有运用群众的舆论和同情，只是跟产品经理硬顶撞;如果利用舆论和大家的同情，大家都说有难度或者做不了，产品经理也会不了了之。
4、 拳法太差，我目测了这个程序员的拳法，都是用手发力，这样其实攻击力不高。真正的拳手是用身体带动手臂，这样才能最大发力。另外，打脸是不对的，大家都是要靠脸吃饭的。
5、 最最严重的问题，这位程序员没有来交大慧谷培训中心学习PMP课程，我们除了教项目和产品研发流程，也会教如何情商管理、领导力和引导技术，他完全不懂。
最后，我们从项目管理视角来看待这次打架门事件到底问题出在哪里，如何去改善呢?
一、在团队架构上出了问题。
对于敏捷创新式项目管理，我们的团队架构是PO(产品经理)+SM(敏捷大师)+团队。而我建议最佳组合应该是：销售型PO(产品经理)+SM(敏捷大师)+团队。PO还是可以天马行空的从用户角度挖掘需求，但是敏捷大师会带领团队一起收集用户故事，大家自我认领故事和功能。这样就避免了是产品经理直接派工和改需求，程序员觉得做不了的矛盾了，这个项目尽可能的变成产品经理代表需求方(甲方)，敏捷大师和敏捷团队是实施，让团队们自己去沟通是否功能可以实现。
二、变更管理的问题
在整个需求变更过程，完全由产品经理说了算，没有变更控制委员会(CCB)，这样整个产品研发过程都是一言堂，一人说了算。带来的风险就是未来产品是什么样子大家都不清楚，没有前期需求的调研，想一出是一出，如果要变都是通过口头，所有变更都没有追溯及审批。所以才会爆发这个矛盾，打架开除两位员工是小，如果耽误企业新产品研发创新能力和进度，其实是大事情。
三、PMO的改变
我也去过很多银行的系统，原来银行的开发都是瀑布式，现在越来越多的提倡创新和敏捷式项目管理，问题其实出在PMO高谈扩论我们要提倡敏捷项目，但是由于权力需要不肯放手，不肯放手带来的还是敏捷团队根本没有发挥敏捷的创新力。
为什么呢?大家来看，在传统瀑布式的项目管理过程，我们讲究前期可行性研究和项目预测性，立项考虑很多风控事宜，所以由项目经理一个人立项是不够的，我们会建立一个指令型或者控制型的PMO。PMO在银行系统的项目管理中往往权利很大，控制着所有的项目，如果有一天我们要谈敏捷式项目管理了，原先高高在上、位高权重的PMO成员会拱手让自己的PMO变成支持型，把创新给予产品经理、项目经理、敏捷团队么?
四、团队凝聚力问题
一个有凝聚力的团队可以战胜任何困难，好比当年曹操的官渡之战。一个没有凝聚力的团队就是一盘散沙，好比当年袁绍的几十万大军。作为企业领导者，也应该在企业文化和凝聚力上面多下功夫，提倡员工之间的团建，提倡我们员工之间在工作之余的私下交流和互动。有时候问问自己，我们多久没团建了?如果回答是超过半年没有团建了，那其实说明了整体企业和集团已经失去了生命力。
五、大公司反而有大公司病
很多人会有这种感觉，在一个小公司工作，什么事情都要管，每天忙的不可开交，但是有时候感觉挺锻炼的，也为自己每天努力感到骄傲。很多企业的高层管理者其实也有这样的回忆，我们企业初创只有几十个人的时候，大家氛围最好，凝聚力最好，现在我们企业有几万人，几十万人了，不知道为什么跟原先不一样了。原来人少的时候各个人都充满斗志，脸上洋溢着笑容，大家互相尊敬。现在人能多了，反而感觉各个人脸上表情木那，每一个都像陌生人，每一个都是为自己工作的机器，这个就是大公司病。
一般大公司病往往如此：
1、 机构臃肿。公司拥有几十个部门，部门跟部门之间缺乏沟通，没有交集也没有交流。以前一个人能做的事情，确要横跨几个部门甚至十几个部门。
2、 决策缓慢。层层报批，因为要等流程经常延误很多战略机会。有时候以前几分钟能给的答复一等就是十几天。
3、 多重领导。一个决定要经过很多领导的同意，甚至领导之间还有互相推诿勾心斗角，尔虞我诈。大家关心的是自己的权益了，而不是公司的利益了。
那么带来的肯定是创新人才的流失，企业创新力的下降。所以，公司大可以，但是千万不能得大公司病。
好了，本期我就以项目管理“法官”的视角来看的打架门事件，也算回答了牛牛同学的问题。大家怎么看呢?