【重磅系列】跟着老汤一步一步建立产品管理体系-第四篇-系统管理体系-需求管理系统(上)

需求有多重要,这个就不用多说了,大家都知道的,其实甚至可以这样说,产品管理的工作是“始于需求,终于需求”的。

道理都懂,但是一到实际的实施中就走样了,就和40岁的中年大叔一样。

有朋友会说了,有你说的那么严重吗,不就是搞搞需求吗,我每天都在做,感觉没啥问题啊。

果真如此吗?

接下来,我就说三个非常小的情况,看看大家平时都做的怎么样。

情况1:知道BRD、MRD、PRD,你真的会写吗?

我们知道,产品经理有四大文档,分别是BC、BRD、MRD、PRD。

BC暂且不说,因为就我了解,几乎没有产品经理去做这个,因为老大们都帮咱们做了这个事情了(尽管不对,但事实如此),就说其它的三个吧。

BRD,商业需求文档,这个文档是干什么的呢,很简单,说明产品的商业发展计划

具体都包括哪些内容呢?大家看图1:

看起来内容似乎不多,但我和大家说啊,哪一项都不好写,具体怎么写我就不讲了,就提一点,在BRD中,几乎全是要求产品经理回答“策略性”内容的问题,直白点说,就是你得在这个文档中明确的告诉企业,我想做的产品如何能够最终支持企业战略的实现。

MRD和PRD也不多说了,因为针对如何写这两个文档,我专门写过文章了,大家可以看一下。

手把手教 · 如何写一份更神的 · PRD:http://www.chinapm.com.cn/?p=522

手把手教 · 如何写一份神一样的 · MRD:http://www.chinapm.com.cn/?p=519

那么,讲这三个文档和需求管理系统又有啥关系呢?

各位,这三个文档中的第二个字母-R-可就是需求啊,其实咱们都不用讲大道理,从这三个文档就能看出产品经理要面对的需求是什么:

1、商业需求:战略级的需求,说明产品战略和企业战略是如何结合的。

2、市场需求:市场级的需求,说明市场的问题、机会、风险都是什么,以及我们要提供的解决方案是什么。

3、产品需求:产品级的需求,说明基于解决方案,我们的产品应该解决哪些现实问题。

当然,再往下,就是FRD了,这个就是功能级的需求了,明确详尽的功能规格是什么。

大家看到这里,应该就明白了吧,咱们平时做的所谓的需求管理,或者需求分析的事,更多的是在产品级的和功能级的,至于市场级和战略级的,我想大部分的朋友是木有去做的。

也正是因为这个原因,才导致我们认为需求管理很简单,把产品级和功能级的需求分析一下,把功能考虑一下,然后做个原型出来,就算完事了,市场级和战略级的需求怎么通过原型来表现呢?

因此,这就是为什么在RPM的系统管理体系中要把需求管理系统作为第一个系统的原因了,我们日常做的需求管理的工作(收集-整理-分析-设计-分配-执行-验证),其实是系统流程化的表现,但是所有的流程都是运行在体系中的,而这个体系不仅仅包括需求管理系统,还要和其它的系统有关系。

比方说,你在考虑商业需求的时候,就一定会涉及到组合管理系统,因为你的产品,和公司的其它产品,都是要为企业战略的实现服务的,那么,产品之间如何形成合理的组合,商业层面的考虑是非常关键的,比方说会不会出现同类相食的情况,会不会出现定位缺乏差异的情况,从需求的角度看,这都属于商业需求。

因此,RPM所涉及到的需求,不同于我们现在看到的项目管理、研发管理等这些管理思想所定义的需求,当然,在具体的某些工作中会有一些类似,比方说功能级别的需求就很大程度上同项目、研发涉及的需求接近,但是从体系的角度看,则是完全不一样的。

但是,现在很多的企业,在需求管理上则是照搬了其它管理思想的需求管理模式,这样带来的直接后果就是产品经理事实上成了这种需求管理模式的附庸,比方说现在有一些所谓的需求管理工具,本身是为项目或研发设计的,但是产品经理却不得不也得使用这样的工具。

当然,就和我说到的,如果只是功能级别的,用一用也无伤大雅,但是如果是产品级、市场级、战略级,那么,怎么办?

这就是我要提到的RPM中需求管理系统在现实中的第一个问题:需求缺乏战略性的指导。

因此说,在产品管理中定义并要求产品经理去写这几个文档,并不是谁心血来潮编出来的,而是从产品管理的价值和对产品经理的工作要求定义的,如果理解了这点,其实也就明白为什么说产品经理要面对的需求必须是要有战略性指导的了。

如果只是玩玩功能级的需求,说实话,没产品经理之前,难道别人就不会做吗?同样,其它级别的需求,没产品经理之前,也同样有人做,但是,但是,能够把这些不同级别的需求有机的结合起来,并基于企业战略进行管理的,只有产品经理。

哦,不对,以前也有人做,是公司的老板,这不是老板忙不过来了,才有的我们吗!

情况2:需求的优先级排序,顺序不重要,关键在于依据是什么?

我们在做需求(通常只是情况1中提到的功能级需求)分析的时候,都少不了一个工作,就是对需求进行优先级排序,我不知道各位是怎么做的啊,只说说我的情况。

公司会给你一个优先级说明,无非就是分为什么1、2、3,或者A、B、C,再或者起个通俗易懂的名字,必做的、可做可不做的、不做的,基本上就是这样。

然后我就拿着一堆需求,按照这个说明给需求排序,这个是A,那个是B,就这样搞。

各位肯定会说了,这不是很正常嘛,对啊,是很正常,那我们被怼也就很正常了,因此大家也就别有什么怨言了。

真的很正常吗?

很不正常。

如果需求的优先级排序是这样的逻辑,那么,各位是否想过,同样的需求列表,交给十个人去排序,那么就会出现十种排序情况,那么,听谁的呢?

看看,问题来了吧,这也就是为什么你拿着排序好的需求并形成功能的时候,被研发那边怼回来的根本原因,因为你认为优先级高的需求,研发的伙计却认为不高,而你们都有自己的理由。

为什么会出现这种情况呢?

原因很简单,就是优先级说明只是排序的一个结果,而不是依据,也就是说,优先级顺序的得出依据的是什么,其实你并不知道,你知道的只是1、2、3,A、B、C,但是怎么得出的这些数字或字母,并把这些优先级对应到每个需求上,你是不知道的。

其实在规范的需求评估中,关键不在于结果到底是什么,而是产生结果的过程是什么,过程规范和科学了,那么结果自然而然就会产生。

就如同你要计算什么样的和值为2,如果不加限制,也就是没有规范,那么可能性就太多了,无穷尽的。

但是,如果你把这个过程规范了,比方说,只能是两个数的和值,两个数只能是整数,两个数可以重复,那么就只有1+1=2了。

我说的这个情况仅仅是需求评估这个工作,在整个需求管理系统中,从市场问题导入,到问题如何导出需求,再到需求评估和筛选,再到需求的分配,执行、验证,以及可能涉及到的变更,每个工作都是需要相应的规范来处理的,如果缺失一些规范,那么,就等于需求管理中的某个环节的输出结果是有问题的,而这个输出则又是下一个环节的输入,输入都有问题了,还能保证输出能正确吗?

这还仅仅是从纵向的流程表现来看,如果再看横向的系统关系来看,那么问题就更大了,影响也就更深了。

比方说需求管理系统和创新管理系统,你通过需求管理系统拿出的需求本身就和市场真实情况有很大的差异(事实上,需求完全适配市场只是理想状态,我们要做的只是不断努力,无限接近),那么,你基于需求设定的产品概念本身就已经有了问题,那么,最终你解决的可能就是一个所谓的“伪需求”了。

这也就是为什么好多产品经理或创业者在反思产品失败的时候,几乎都会提到一点,就是解决了一个“自己想出来的”,或者“在市场上不是那么刚性”的需求。

整体看来,企业是很重视需求的,但是需求的管理过程却是像筛子一样的,漏洞百出,漏洞百出的直接后果就是需要不停的补漏洞,最典型的表现就是需求变来变去,一会要加,一会要减,产品经理睡个觉,老大就会和你说,我想了一晚上,那个需求还是先别做了,你心里只能骂一句MMP,老子昨天刚把功能设计出来。

这就是我要提到的RPM中需求管理系统在现实中的第二个问题:需求管理过程不规范。

规范不仅仅包括工作流程上的,还包括工作方法上的,现在的问题是,很多企业两个都不规范,这就是个麻烦事了。

好,关于需求管理系统的构建看来得分成上下两篇来介绍了,今天就先讲到这里,咱们下一篇继续!



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

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址