?>

【老邱百问】第六十六期:为什么要打你,心里没点数吗?

2018-08-29         阅读   7661

  我们来回顾下“平安打架门”事件:

  事情发生在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、 多重领导。一个决定要经过很多领导的同意,甚至领导之间还有互相推诿勾心斗角,尔虞我诈。大家关心的是自己的权益了,而不是公司的利益了。

  那么带来的肯定是创新人才的流失,企业创新力的下降。所以,公司大可以,但是千万不能得大公司病。


  好了,本期我就以项目管理“法官”的视角来看的打架门事件,也算回答了牛牛同学的问题。大家怎么看呢?