【系列推荐】转型与重构-产品经理们如何为企业构建产品管理体系-第三篇:定型工作(上)

在设计工作完成后,也就意味着我们理论层面的工作阶段完成了。

但是,这并不意味着我们就可以马上开始进入到实施阶段,也就是工程阶段了。

在这两个阶段之间,还有一个必须要做的工作就是定型工作,这个工作有点像我们做产品时的“概念筛选”,也就是说,在这个阶段,公司的老大们要对你做的PMS设计方案进行评审。

公司在做产品的“概念筛选”的时候,会基于公司的资源现状和实现目标,从多个产品概念中找到最合适的,而不是最好的,同理,我们的做实施方案同样也要经历这样的选型过程。

但是PMS设计方案和产品概念在这个过程中最大的区别是概念是从多个中选择一个,而设计方案通常只是一个,当然,也有一种不太普遍的情况,就是有些大的公司也会采用背靠背的模式,让多个团队来做,然后从中进行筛选。

不过,对于大部分的公司来说,还是会基于你的PMS设计方案进行评估,并作出最后的决定。

那么,在这个过程中,通常我们都要面对哪些工作呢,在本篇中,我们就来讲一讲这些。


工作1:达成方案的内部共识


这个工作有点类似“准备工作”中的“思想上的统一”,目的都是为了在公司内部形成共识,区别在于“思想上的统一”的目的是形成对产品管理体系认知上的共识,而“方案的内部共识”则是要形成产品管理体系落地的共识。

打个比方,前者的目的在于向公司内部的利益相关人说明“这是个好东西”,而后者的目的在于向他们说明“我们怎么把这个好东西做出来”。

可能有些朋友认为这个工作不是什么难事,但就我这些年来的经历来看,这其实是个比较有挑战的工作。

在电影《私人订制》的结尾,葛大爷和记者有过这样一段对话:

记者:“如果你有一百万,你可以捐出来做慈善吗?”

葛优:“可以!”

记者:“如果你有一千万,你愿意捐吗?”

葛优:“我愿意。”

记者:“如果你有1亿呢,你愿意捐吗?”

葛优:“别说一个亿,十个亿我都愿意捐。”

记者:“如果你有一辆车,你愿意捐吗?”

葛优:“我不愿意。”

记者:“十亿你都捐了,为什么不舍得捐一部车?”

葛优:“因为我真的有一辆车………”

其实道理很简单,就是人可以为自己没有的东西随意承诺,而对自己有的东西会小心翼翼。

同样,我们做的PMS的方案设计,本质上是一种理论,只是纸面参数,对于利益相关人而言,那是你产品经理的事,我们只是看看,是个旁观者,但是一旦要落地了,那就是大家的事了,我就不是看客了,而要琢磨落地是否会影响我的利益了。

其实这就是“你做我看”和“大家一起做”的区别,只要一起做,就一定会有各种利益纠缠在里面。

因此,在工作1中,我们在达成PMS方案共识的时候,关键点不在于你如何去讲方案,而在于你如何从落地的层面考虑清利益相关人的诉求。

但是,我也承认,这个说起来容易,做起来难,因为我们是基于企业整体利益来设计的,这种设计不应该是对各种利益方的妥协的产物,那么,具体该怎么来做呢?

说实话,这是没有通用的模式的,毕竟这根本上是在和人打交道,我只能说一个我的案例供大家参考。

我曾经在某家以技术起家的企业做过PMS体系的实施,在方案定型的时候,我们老大就和我说,我们的爆破点应该在技术口,一般来说,技术起家的企业,技术部门很大程度上是强势部门,我们的老总就是典型的技术狂人,平时对技术部门也非常照顾,按说应该挑软柿子捏,比方说先搞定市场,但是为什么我们要选择技术口呢?

因为只要先搞定技术口,其实也就向其它部门暗示了大老板的态度,其它部门就比较容易和我们达成方案共识了。

当然,这个过程也是需要一点策略的,比方说我们在和技术口沟通的时候,采用的是“逐步推进”的策略,比方说,我们会和他们说,在实施方案中,我们要做的第一步只是明确产品体系和研发体系之间的接口规范,而在这个步骤中,并不会影响到现有研发体系的任何本质改变,双方之间只需要明确各自的输入/处理/输出的内容就可以了,这样,一方面不会太大影响研发体系现有的工作,另一方面,也会让研发体系愿意参与到实施中,毕竟双方的工作规范一些对研发是有好处的,毕竟研发是受够了混乱的苦的。

这样,我们就从研发体系参与方案的成本和可获得的收益两个方面打动了他们,当然,随着方案实施的逐步推进和效果的逐渐体现,他们的信心,积极性和利益获得都会促使他们继续参与到实施过程中。

因此,我们在介绍落地方案的时候,第一,要找到关键突破口,第二,要对突破口采用“润物细无声”,而不是“泰山压顶”的策略。


工作2:合理处理被引导出来的诉求


产品经理在管理需求的时候最怕什么,我想应该是当需求数据已经冻结,还有没完没了,源源不断的需求被提出来。

这分为两种情况,一种是主动性的,一种是被动型,前者来源于客户的主动思考,后者来源于一定条件下的引导。

而我们在进行方案定性的时候,几乎都会遇到后者,也就是说,公司内的利益相关人会在方案定型过程中被我们现有的方案引导出各种各样的想法。

这就有点像我们做市调的工作,我们都倾向于设计封闭式的选择题,而不愿意设计开放式的问答题,除了选择题更方便进行数据统计和分析外,还有一个重要的原因就是开放式的问题往往会让受访者思路大开,产生各种各样合理或不合理的想法。

同样,在工作2中,因为利益相关人对于产品管理(包括理论设计和方案构型)的不专业以及工作1带来的影响,因此,我们在这个工作中,几乎无法避免这种被我们的方案引导出来的各种各样的诉求。

还是上一家企业,我们在和研发沟通方案的时候,在聊到产品需求文档内容规范的时候,研发就被这个文档的内容引的脑洞打开,他们对我们说,既然你们要通过这个文档来向我们说明要做什么,那就这样吧,在这个文档中你们产品经理把产品的数据结构也加进去,我们直接按照这个数据结构来做数据库就行了。

大家看到了吧,这就是典型的利益相关人的需求被引导出来了,因为在研发看来,既然你们是产品经理,是负责产品整体规划和设计的,那这事就好办了,产品编码以外的事都归到你们产品经理那里就可以了。

其实通过这个案例,我们也知道,这是一种典型的“不合理”的需求,因为产品经理对产品的“设计”并非是研发所理解的“设计”,产品经理的“设计”更多的是指“商业/业务”的设计,而非产品具体开发规格的设计,但是从研发的理解看,产品的设计也应该包括技术上的设计。

当然,除了这种“不合理”的需求,自然还有“合理”的需求,在本文中,我还是主要说说如何面对“不合理”的需求。

有两个处理原则需要把握:

1)在面对不合理需求的时候,不要纠缠于口舌之争,而是要基于你的方案逻辑来说明需求的不合理性。

比方说,面对要求产品经理设计数据结构的需求,如果你只是强调产品经理不是技术岗,不应该涉及这个工作,显然是不太容易说服对方的,因为对方会反问你,产品经理为什么不涉及技术,你不是说过嘛,产品经理要懂技术的,既然懂技术,那做做这个工作也未尝不可的,如果你沿着这个思路聊下去,那就被动了,因为你不得不去解释产品经理为什么要去学习技术知识,如果这样的话,这个沟通就算是彻底跑偏了。

别忘了,我们和利益相关人进行方案的沟通,目的在于尽可能快的针对方案的落地达成共识,而不是普及产品管理和产品经理是什么。

因此,我们要基于我们所设计的方案来进行沟通,比方说,你可以通过你所设计的工作流程和工作关系来进行说明,告诉对方,产品经理做PRD的目的在于提供给研发尽可能准确和全面的产品需求,这是产品经理义不容辞的责任,在PRD通过评审后,就意味着产品体系向研发体系输入的最核心成果完成了,接下来就是研发体系的事了,也就是说,一个产品,“做的对不对”在产品体系,“做的好不好”就在研发体系了。

这样沟通的话,就能够让对方理解两个体系各自最核心的责任在哪里。

2)必要的时候,一定要做出一些适当的让步。

比方说,研发理解了双方的核心职责,也承认产品经理不需要过多涉足具体“做”的过程,但是,他们又提出,你设计的这个PRD规范太多,太长了,他们没有太多的时间去看这些,这又该怎么办呢?

如果你觉不松口的坚持必须按照PRD来,那么,就算最后通过了(从规范的角度看,你并没有任何问题),也会让研发心理上很不舒服,也可以预料到研发在看到你的PRD时的那种愤懑。

因此,这个时候,我们必须充分考虑到研发的心态,毕竟我们之间打交道肯定不是短期的,那怎么办呢?

也简单,就是基于PRD做些改进,比方说,基于PRD的核心内容,你完全可以搞一个LoF(List of Functions/Features,功能/特征列表)出来,简单说,就是把文字化的PRD变形成研发喜欢和习惯看的数据化表格,当然了,这个LoF是可以不断优化的。

这个看起来是增加了我们的工作量,似乎也缺乏了一定规范,也好像是没有坚持我们的方案,但是细细想想,这会有伤大雅吗,显然没有,仅仅是制作一个列表,或者说只是用另一种方式来呈现PRD而已,但是,你得到的却是研发的认可和支持。

好,关于在方案定型中要做的事我们就先说两个,在下一篇中,我们再来讲两个和定型有关的工作。(未完待续

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

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址