【重磅系列】跟着老汤一步一步建立产品管理体系-第七篇-如何保证PMS的正常和高效运转(上)

从第三篇到第六篇,我们一共用四个篇幅介绍RPM实施模型中的四大管理体系:人力管理体系;系统管理体系;流程管理体系;文化管理体系。

有朋友会问了,是不是我按照介绍的体系去做,就能构建出PMS呢?

这样说吧,如果你的企业和产品想死的快一点的话,就去做吧。

在本系列开始的时候,我就提到过,这个系列最主要的目的是提供给大家一个构建的原则和思路,我希望的是大家能够按照这种原则和普遍性的思路,结合企业和产品的实际情况去构建,而不是指望有一套产品管理体系套路能够套到你的现实中。

打个比方,这就像在驾校学车,教练交给你的是一种驾驶规范,但是你在拿到驾照后,至于怎么开,那得根据开的车,行驶的路况,甚至自己的性格最终形成自己的驾驶风格。

简单说,就是我所有介绍的东西都是死的,但企业、产品和人是活的,必须在原则和规范的指导下因地制宜。

但是,在这个构建的漫长和艰难的过程中,肯定会有很多的问题、难题会出现,而不解决掉这些问题、难题,你所构建的PMS也是无法发挥出太大作用的,因此,从本篇开始,我就讲一些在构建、实施、运转PMS的过程中可能出现的问题,换句话说,就是在这个过程中,会有哪些因素会影响到体系的构建、实施和运转,希望能够给大家在做这个事情的时候提供一些经验和教训。

我先来总结一下,RPM的这四大体系之间是一种什么样的关系,我经常把RPM这个实施模型比喻成一棵树,大家看下图:

这是什么意思呢?我来做个比喻:

  • 系统管理体系如同树生长的土壤,为RPM提供生长的根基;

  • 流程管理体系如同树发展的脉络,为RPM提供能量的输送;

  • 文化管理体系如同树所需的营养,为RPM提供成长的保障;

  • 人力管理体系如同树产生的枝叶,为RPM提供最终的产出。


上篇

说的有点多了啊,回到本篇正题,我们如何来保证基于RPM构建起来的PMS能够运转好呢,或者说,我们衡量一个体系运转良好的标准是什么呢?

我认为就是两个,一个是正常,一个是高效,正常是指体系中的各个系统、流程是处于一种合理范围内的状态,高效是指在合理范围内的最大可能产出。

具体到RPM上,“正常”往往会受到PMS的组织架构的影响,“高效”往往会受到PMS的运转体制的影响,接下来,我就通过四个案例在本篇中先讲讲“体制”对PMS的影响都有哪些具体表现。

1)责权利的不清晰

小A是某互联网公司的产品经理,近期,由他牵头负责一个新产品的开发,公司给他制定的工作就是完成对用户需求的分析,定义产品功能,监控产品研发,以及完成产品上线等,因为这个项目是公司的重点产品,因此公司采用了封闭开发的模式,整个团队三十几号人都被关在郊区的一个度假村里进行工作,这个团队除了小A这个产品经理外,基本上都是研发部门的人,还有一个项目经理在全权负责整个研发团队,也就是说,小A负责产品管理,项目经理负责项目管理,在经过了60天的封闭开发后,产品终于上线,项目团队解散,公司给了整个项目团队一笔项目奖金,但是小A却发现,在奖金发放中,却没有自己的份,小A不满,向上申诉,在经过多次协调后,才给小A补了奖金。

事后,小A向我抱怨:公司只看到研发团队加班加点,就看不到我在研发之前做的那么多工作,好像我就是为这个研发团队做文档的,按说,产品出现任何问题,都是必须经过我来协调的,但是在整个研发过程中却是有什么问题,研发人员直接向项目经理汇报,而不和我沟通,出现任何变更,项目经理就能拍板,我却无能为力,我就是一个理论上的产品负责人。

案例剖析:

这是一个在IT行业里比较普遍的一种情况,也就是产品经理的“责任、权力、利益”不能明确定义,不能形成书面的企业制度来通告全公司,造成“说不清、问不明、做不了”的结果。

出现这种情况,通常是由以下三种原因造成的:

1、上知下不知:

作为公司高层个人,他可能对产品经理在公司内要做什么,很清楚,并且也在招聘产品经理的时候也会用期望的指标来进行考核,但是,他只把这种信息传递给产品经理就到头了,而作为公司的其它业务部门,也不知道是因为他不想,还是不屑,总之是不知道产品经理应该做什么,要说不知道也不准确,多少有些模糊的认识,但是误就误在了这种模糊上。

市场部门会把产品经理认为是“产品售前”的角色,研发部门则会认为是“产品功能设计”的角色,归根到底一句话,其它部门对产品经理责权利的认识都是支离破碎的。

2、我知你不知:

许多产品经理自身对产品管理的工作非常清楚,也一直在努力去做,但是恰恰所在的就是一个对产品管理有着模糊认识的公司,也就是说,除了产品经理个人外,公司的其它人,包括高层在内,都对此职位没有明确的定位,稀里糊涂的模仿别人来使用产品经理,要么一会让产品经理去支持销售,一会让产品经理进研发团队去辅助工作,甚至还有让产品经理去做系统设计的,在他们的认识中,只要和“产品”二字沾边的,就应该是产品经理要做的工作,可一个企业里,几乎所有的业务都是和产品有关的,那自然而然,产品经理就成了一个“打杂”的了。

3、书知人不知:

这种情况最有意思,就是说企业的产品经理形象永远存在于纸面描述上,当然了,这种纸面描述是原创的,是抄袭的就不那么重要了,重要的是,我有了产品经理了,这就足够了。这张纸面的描述打写完后,就被锁在了HR的柜子里,只有需要招聘了,才拿出来看一下。因此,别说公司的其它业务部门不知道了,就连产品经理自己都不知道要做什么,结果就是被动地等待工作的安排,成了一个不做产品管理工作的产品经理。

分析完这三种原因,可以看出,无论是那种原因,都存在一个同样的问题,就是“职责不明、权力不定,利益不享”。

先说职责不明,这里的“不明”不是说某个人或者某几个人不清楚,而是说所有挂在PMS上的业务部门中的所有人对产品经理职责的不清楚,这是一种群体现象。

我们知道,产品经理是要通过他人来产生绩效的,可以想象,你要依靠产生绩效的业务部门中的同事连你的工作都不清楚,如何给你提供必要的支持,你又如何让对方准确地理解你需要他们提供什么样的支持呢?

这个道理很简单,多支协同作战的部队,如果互相不知道对方该做什么,根本无法实现协同。

因此,职责的明晰一定是要公司全体的明晰,而不要认为只要当事人知道就行了。

再说权力不定,按照对产品经理经典的描述,应该是“没有权力的小CEO”,但是问题就这样出现了,在产品团队中,产品经理的重要工作就是保证团队步调一致的按照计划进行工作,许多人也认同,促进团队工作的主要方法是个人的影响力和沟通协调,这是一个比较有意思的现象,在团队成员的认识中,既然产品经理是产品团队的旗手,鼓手,那么,你肯定是有权力在身的,即使没有直接的权力,也是某种权力的代言人,这种理解是没有错的,团队成员在潜意识中会认为你是具有直接权力的。

当然,这里不讨论是否应该有权力的问题,而是要说,企业要非常明确地说明产品经理的工作方法,管理产品团队的基本思想,而千万不要给产品经理一个让他人感到和权力暧昧的角色。要知道,这种暧昧会让团队成员放不开手脚,直接影响到产品经理的工作。

最后说一下利益不享,这个谁也不能否认,每一个职场人员在工作中无非追求两个目标:一就是长远发展,二就是现实收益。

作为产品经理来说,因为他是跨部门进行工作的,和每一个部门都有一定的工作联系,并且工作重心也会随着产品过程的发展而不断偏移,这样就不太好对产品经理的绩效进行量化,如果只把产品过程中的某个阶段的效果作为绩效标准,那么产品经理为此阶段所做的工作就会被忽视,而这些工作同样是对该阶段有着重要作用的,但是如果不以此作为标准,那么能用什么来衡量呢?

销售团队可以用简单的销量是否增长来衡量,研发团队可以用是否按时按量按质完成开发和生产任务来衡量,市场团队可以用是否扩大了公司市场份额来衡量,客服团队可以用是否减少了客户投诉来衡量,可是,产品经理呢?

有些企业为了省事,干脆直接把产品经理扔到市场部门或者研发部门,让他们享受和这些部门同样的绩效待遇,这种做法的后果就是永远地让产品经理成了这些部门的附属职位。

或者有些企业干脆就不进行量化的绩效考评,而是给一个固定的收益,不论工作成绩到底如何,只要一个月干够了22天,薪资就不会少。

前一个方法让产品经理做的信心不足,不能发挥出足够的作用,后一个方法则让产品经理很容易混下去,同样也使企业采用PMS的初衷发生了偏移。

责任、权力、收益,这三者是紧密联系的,如果有一项不够明确,都会对产品经理的工作产生很大的影响,而这三者的明确,一定不能照搬,不能模仿,需要的是企业好好对产品经理这个职位进行认真地研究和分析,制定一套能够对企业有利,对个人有益的制度出来。

2)强势部门的影响

先来看一个案例:

小B是某软件公司的一个产品经理,负责公司的一个重要产品,在产品团队中,除了产品经理,还有研发经理、市场经理,他们的直属上级分别是产品总监、技术总监和市场总监,其中,产品总监和技术总监属于主管产品和技术的副总裁,市场总监属于负责市场和销售的副总裁,同时,这家公司也是由项目型公司转型到产品型公司的典型。

小B在工作中遇到一件事情,很让他郁闷。

在一次项目过程中,因为某些原因,影响到了项目的完成时间,在项目开始之前,已经做过了相应的风险评估,并制定了预防措施,所有产品团队中的人都签字认可了风险方案,但是当小B决定采用预防措施的时候,研发经理却说“无法按照既定措施进行工作”,并同时要求寻求其它的解决方案,小B不同意,明确指出“如果重新寻求解决方案的话,很可能会出现新的风险并直接影响到进度”,研发经理和小B在沟通无果的情况下,分别上报给技术总监和产品总监,继续沟通无果,最后只能上报到副总裁那里进行协商。

最终的结果是,副总要求产品部门按照研发经理的建议进行工作,私下对产品副总和小B说“只要能把产品做完就行了,用什么方法是次要的。”

小B后来对我抱怨说:如果是这样,那还不如随时遇到问题随时解决呢,何必制定那么多的规范和流程呢?

案例剖析:

这是一个典型的“胳膊拗不过大腿”的案例。

在许多公司中,无论你是否同意,都必须承认公司内必定存在一个或者多个强势部门,尤其是在一些形成规模并且原始创业团队依然在位的公司内,至于是哪个部门占据强势,很简单,看公司核心业务部门的一把手是谁即可。

公司的核心部门通常有市场、研发、生产和销售这四个部门,至于产品部,一般情况是在公司有一定规模的情况下才会设立,刚起步的公司不是说没有产品部,而是产品部的职能被分解到了核心团队成员中。

如果公司的总经理、负责市场的副总以及下属部门的中层都是市场出身,那么,整个公司的强势部门必然是市场部门,同样,公司是否是技术部门强势,以此判断即可。

而产品部门呢,如刚才所说的,通常只是公司正规化后才能显现出来的部门,如果不是给与特别的照顾,是很难在短期内发展成强势部门的。

造成这种情况的原因主要有二:

1、惯性思维(历史原因):

这种惯性思维存在于高层、中层以及许多普通员工中。最典型的表现就是“是技术实现了产品,是销售实现了利润”,而产品管理者,只不过是在为这些部门提供支持而已,甚至有些部门认为,产品部就是一个可有可无,类似鸡肋的部门,我们这些部门完全可以做产品部的工作。

我们不可否认,在公司的初创阶段,首要的目标是“生存”,是把产品做出来,然后卖出去,因此,在那个阶段,研发和销售力量的强弱直接决定了企业能够生存下去(也就是以“经营为主,管理为辅”),但是随着企业逐步的发展,形成规模,生存的需要转变为“持久发展”需要的时候(也就是以“经营和管理兼重”),这个时候,企业就需要少数有着高瞻远瞩,能够为企业提供长久发展思想的人加入进来,这些人就是产品管理者。

但是,当这些人加入进来后,企业中传统的业务部门因为自身思维惯性不能在短期内改变,因此,对于产品部门的作用没有足够的认识,尤其是在老员工保持的许多核心业务部门,对于产品部的认识通常是忽视,轻视,甚至蔑视。

这种惯性思维会存在于自上而下,拥有着传统影响力的部门里,上至高层,下至基层员工,由此可见,当产品部和这些传统强势部门发生冲突的时候,公司通常的做法是“丢卒保车”,丢掉产品部,保护传统部门的情绪,作为决策层来说,作出这样的决定,无非两点:一就是传统的上下级感情;二就是产品部的作用不能直接显现,而今天得罪了例如销售这样的部门,影响到了销售部门的整体情绪,很可能明天就会影响到产品的销量。

2、量化思维(现实原因):

强势部门之所以成为强势部门,除了传统影响力外,另一个原因就是因为部门间的量化思想。

什么是量化思想呢?简单地说,就是通过简单的数量计算来衡量部门是否在公司内强势。这种数量的计算就五花八门了,可以是人数上的,可以是市场份额上,可以是销售业绩上的,甚至可以是加班时间上的。

比如说,一个研发部门的人数占了公司的一半,如果该部门的领导和下属关系相处的不错,那么,作为公司高层就要考虑了,如果我得罪了该部门领导,是否会影响到整个部门呢?这种可能性一半对一半,风险还是不小的,因此,避免这种风险发生的最好方法就是“不得罪这个部门的核心人员”,除非出现了关系公司根本利益的问题,否则睁一只眼闭一只眼就行了。

但产品部门呢,在国内,上千员工的公司,产品经理的数量最多也就十来个,扔到人堆里就找不到了,就是都走光了,公司的业务也不会受到什么太大影响,如果再加上第一种思想的作怪,那产品部门在公司内就更说不上话了。

因此可以看出,强势部门对公司PMS的影响,既有历史原因,又有现实原因,而这种情况的改变在许多企业内是短期无法实现的,即使高层非常坚定地支持PMS,但是到了具体的业务层面,或明或暗的都会存在这种传统势力左右PMS的情况,对于产品管理者来说,这将是一个长期的挑战。

通过对以上两种原因的分析,可以看出,在任何一个公司内,都是客观地存在强势部门的,部门间必然有利益的冲突,甚至出于个人的目的,进行明争暗斗,如果出现这种情况,就不单单是PMS的不幸了,而是整个公司的不幸了。

其实要改变这种情况,已经不仅仅是某个部门的问题了,而是涉及到企业管理层面上的了,如何提高国内公司的现代化管理程度,提高工作效率,减少内耗,部门间协作更畅通,员工忠诚度更高,这就不是本文要讨论的问题了,有兴趣的朋友可以看一些企业管理方面的资料来加深对这个方面的认识。



分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址