[0号公路] 15年产品经理的职业复盘 · PM 职场小说2-9-我的第一次PMS实施

前面几篇主要讲了讲我在HS业务方面的事,本篇我就讲一下我是如何参与HS的PMS建设的。

前面提到了,在我刚到HS的时候,Z就和我说过要基于HS的实际情况来构建PMS,但是具体怎么建,谁也没有想法。

于是我们就一次一次的讨论,那个时候国内也没有一个可借鉴的不错的PMS,而国外的又离我们很远,无论是距离上还是实效上。

因此,我们首先定了一个原则,就是:借鉴好的但不模仿,创新但不脱离产品管理的本质。

于是,我们的思路大致就成型了,简单说一下。

第一步:对HS的产品进行重新的整理,这个工作已经通过上一篇说到的“红色警报计划”完成了。

第二步:基于产品的情况,重新制定产品相关的方向和策略。

这是什么意思呢,因为当时我们已经深刻感受到互联网带给软件的冲击,也开始尝试如何把软件和互联网进行结合,当时已经有了一个概念,就是ASP,其实就是现在SAAS的前身,简单说,就是把纯软件做成服务,但是具体怎么做,没思路。

还有一点,就是在PC端上,我们可扩展的市场基本已经很小了,并且又受到盗版的严重冲击,盈利乏力,于是就把眼光放到移动终端上,至于结果如何,我会在后面讲到。

但是大的方向已经定了,就是两个,一个就是互联网如何支持软件的发展,一旦触网,就意味着我们产品的市场不仅仅限于国内,那个圣诞节营销计划就是一次尝试,效果还不错,一个就是移动平台的产品。

第三步:评估企业的资源以及现有的产品发展流程。

要想实现既定的产品方向,脱离不了企业资源的支持以及现有的产品发展流程是否可以更好的适配现有产品的转型。

简答说说当时HS的情况,就以研发资源为例,在我的印象中,尽管HS有十几个产品,但是研发人员最多的时候好像就是12个,也就是说,一个研发人员身上都背着1-2个产品的开发项目,关键是懂互联网平台开发的研发也没有储备,如果再让这些哥们去学,时间上是个问题,要是招聘的话,成本上是个问题。

还有就是现有的产品发展流程,实话是说,那个时候的产品发展过程是非常无序的,这应该是当时很多软件公司的共性,就和我的上一家公司MT一样,想好做什么了,就做。

因此,我们评估,这可能是最困难的一个工作,因为要改变一个人的认识比登天还难,问题是我们要改变一群人的认识,难度可想而知了。

因此,无论是从资源上看,还是发展流程上看,我们都面临很大的挑战。

第四步:由简入繁,由易到难的实施。

但是,这个问题必须得解决,于是我们的基本思路就是先攻克最难的点,就是从研发入手,以前研发直接就和市场接口,这次加了一个产品,由产品来连接市场和研发,市场倒是没什么,反正作出什么,我们去销售就可以了,但是研发比较麻烦,因为如果产品做得不好,研发完全可以把锅甩到我们这边,说产品设计的就有问题。

怎么办呢?

我只举HS的PMS中的一个规范,我们把它称为是“内部协议制”。

其实这个思路是借鉴了SCM(供应链管理)的思想,简单说,就是我们要分别和市场、研发签订合作协议,对于市场来说,我是乙方,对于研发来说,我们是甲方,或者可以这样理解,我们接市场的单子,然后通过产品部一系列的工作,把单子交付给研发,研发开发完成后,我们在验收合格后,把最终商品化后的产品交付给市场进行销售。

这样就有三个关键的环节:

1、市场给我们的需求

2、我们给研发的设计

3、研发给我们的成果

事实上,这样就形成了一种互相约束的机制,大家的方向也就一致了,市场要保证需求的可靠,我们要保证产品的合理,研发要保证成果的质量。

然后三个部门之间互前协议,这个协议就和真实的合同是一样的,有责任,有权利,有违约处罚。

比方说,研发通过评估我们的PRD,预估开发时间是30个工作日,但是如果如期没有提交成果,就要违约,当然,违约金是要给的,从哪里来呢,就从这个产品的开发人员的绩效里扣。

当然了,如果按质按量,并提前完成了,有奖励。

具体结果如何呢?

实话实说,不是太好。

因为前面提到了,每个研发人员身上都背着最少两个产品,能少延期完成就不错了,因此,自从这个制度实施后,几乎所有的研发人员每个月都会被扣绩效。

扣个一次两次还好,但是时间长了就受不了,加上老大又是程序员出身,对研发有一种特殊的感情,于是,就说能不能去掉这个制度,但是Z也是一根筋,非要把这个事情做好,说如果这个取消了,整个PMS就乱了,不行。

但是胳膊扭不过大腿,在我走之后,这个制度还是被取消了,尽管PMS还有。

第五步:效果评估

PMS作为一种企业的业务体系,肯定是需要边实施,边评估,边完善的,效果如何呢?

我只说说我们这些产品经理的感受,感觉效果还是很明显的,在MT的时候,我说过公司就是典型的睡袋文化,但是在HS实施了PMS后,我几乎没有加过班,非常爽。

但是不加班的前提有一个,就是在产品的这个阶段,你必须全身心把相关的工作做好,比方说需求的分析一定要到位,PRD的规格定义一定要准确,否则出现问题的时候,还是会找到产品经理身上的。

因此,那个时候,我每天的脑袋就没停过,不停的思考,虽然不加班,但是感觉比加班还累。

再加上我经验、能力有限,而Z的要求又很高,有一段时间我经常失眠,甚至感觉自己要被淘汰了。

简单一句话,只要你有能力把事情做好,那你会很轻松。但是,我当时不行啊。

最终,HS的PMS还是名存实亡了,当然,这是在我离开很长时间后听说的,我现在也为HS感到可惜。

究其原因,我认为主要有三个:

1、公司层面:传统利益方的抵制,后来还是返回了以研发主导产品发展的老路子上。

2、认识层面:还是没有理解了产品管理的本质,这个倒是有情可原,毕竟十多难前IT行业基本上都处于摸索状态,产品管理的实施都基本流于表象了。

3、人员层面:我们几个产品经理缺乏足够的能力支撑起PMS的运作。

不管怎么说,至少对于我来说,我还是第一次亲身参与了PMS的实施,学到了很多有价值的思路,经验,当然也有教训。

我的第一次PMS实践就这样告一段落了。

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

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址