我是如何做需求管理推进产品迭代的?

 

最近整理了下所负责产品的需求清单,整理完之后,整个人感觉轻松多了,于是,想分享下这短暂的愉悦。 原本标题想叫:如何做需求管理?感觉题目太大了,由于个人产品经历的局限性,我充其量就能分享下自己的做法,仅供参考。

需求一定是做产品的第一步,这一点无关什么产品,也无关什么阶段的产品,都是一样的。

我这里的背景是,一个被项目拖拖拽拽、断断续续做了 2 年的 toG 产品。在交到我手里的时候,已经是 2.1 的版本了,而从上一个产品经理接过来的需求清单,竟然是一个不到 20 行的 Excel 文件,那需求描述就跟市场宣传材料一样的颗粒度,让我一度怀疑自己的理解能力有问题。

很显然,之前的版本根本就没有做过需求管理,大概是看一步走一步做出来的。

脑补一下这个产品被创造出来时的情形,某天市场部门接到客户的一个项目,售前赶紧召集产品、技术开会,商讨一下,这个项目能不能做?怎么做?做到什么程度能应付项目的要求?售前准备技术相关文档,产品开始做需求分析,做原型设计,研发开始评估做这个系统需要多长时间。

还没见着实际用户的产品经理,就开始对着项目技术要求文档(标书),按照自己的理解,猜测客户的意图,拿着之前的产品原型,开始拼凑该项目的原型。

研发拿着原型,开始评估工作量,由于时间关系,来不及提前跟产品核对产品逻辑,于是,边开发边在群里沟通「这块咋实现,那块啥逻辑」,产品解释,基本功能开发完成之后,开始测试,测试也在群里问「这块什么逻辑?那块为什么这样显示」,产品解释,研发解释「这块就是那个逻辑,当初就是那么设计的」,测试「哦,这样啊」。

群里一片热闹场景,大家都忙得不可开交,领导看到,嗯,团队最近氛围不错。

不了解 toG 产品的朋友可能很疑惑,怎么是这样呢?

嗯,实际就是这样的,toG 的产品可不就这样嘛,哦,toG 没有产品。

好了,扯远了。

即便环境如此,但还是要按照自己的工作方法,尽量做到最好,不然工作可就太无趣了。

下面简单聊下,我是如何做需求管理推进产品迭代的?

建立需求池

接手的第一件事,就是建立一个公共的需求池。把 Excel 干掉,因为我实在是太讨厌各方信息不同步这件事情了,这都什么年代了,信息同步基本靠吼?

根据 Excel 的原始输入,我一项一项的拆分需求点,录入到内网的 wiki 系统中,由于数据保密,不能用第三方工具,内网 wiki 系统虽然难用点,但也还凑合。

手动录有手动录的好处,每一条需求都重新过了一遍脑子,加深对每一条需求的了解,对后面排优先级是有很大帮助的。

需求池里的需求,自然不是固定的,除了第一次录进去的那批,还会有好多场景下的输入,例如:

1.试用产品时,发现的一些改善点 2.领导临时加塞的需求 3.市场从客户那边获得的需求 4.竞品调研时,别人做得不错的点 5.长期规划中的需求

只要有新的需求,我都会及时往里面录入,简单记录:时间、类别、来源、功能模块、描述、解决方案等字段信息。空下:优先级、版本号、状态等字段信息,因为这个阶段还不知道这些信息。

需求池使用的工具就是一张共享表格,一定要是共享的,大家都可以看到,甚至是添加编辑。

版本规划

有了需求,不应该是做需求评审的嘛。对于 toG 的产品来说,往往不是这样的。

因为根本无法确定,需求池里的需求到底什么时候做,行业环境所致,这里的产品是在项目的夹缝中生存,是被项目推着往前走的,如果没有对应的项目,那么,对不起,对应的产品永无出头之日。

所以,需求之后的版本规划很重要,版本规划就像是产品经理的一把剑,插入项目之中,抢夺研发资源。

做版本规划之前一定要为要该版本立好名头,也就是为什么要做?能带来什么价值?成本也就是研发周期是多少?

然后围绕着这个名头,开始扒拉需求池里的需求。就是要把高优先级的需求拎出来,转换为该版本要实现的功能。

这一步,我通常用到两个工具,一个是 word,用来写规划方案;另一个工具是 xmind,用来梳理整理需求。

将需求池里拎出来的需求,按照产品逻辑,整理成带有层级关系的功能点。

版本规划方案部分使用文档工具,需求整理使用思维导图工具。

需求评审

方案有了,紧接着是方案汇报的环节,这一步就不说了,主要就是给领导汇报是否要做这件事情。

我们假定方案通过,接下来就是需求评审了,这应该是产品经理的受虐环节。

我们拿着 xmind 需求文件,手握 rp 原型文档,在研发测试的怒目注视下,开始讲解该版本要做的事情。

讲的时候,通常没人吭声,当你讲完,礼貌性的问大家有没有问题,以为要结束的时候,你会发现评审会现在才刚刚开始。

接下来就没啥可说的了,主要两种结果:一是你凭着三寸不烂之舌说服全场,按照既定的规划完成所有的需求;二是你的需求清单被砍的体无完肤,你默默的捡起被砍的需求,重新扔进需求池,一声不吭的回去改原型了。

一般情况都不会是这两种极端,砍肯定会砍的,原型肯定是要修改的,但情况应该不会太差,也不必担心,更不要抱怨,因为很多时候,产品经理的能力就是在这种环境下锻炼出来的,经历得越多,你会发现,自己做产品的手感越稳,这其实就是基本功的锻炼。

研发排期

通过评审之后,就是研发的排期了,需求被拆成功能到这里之后,会被研发进一步细化成实现的路径。

例如,要做账号管理的功能,研发层面就要设计数据库、开发调用接口、前端页面设计等等。

这一步的需求不再是需求,而是一条条的开发任务。

这个环节一般使用项目管理类的工具,需要有任务分配、状态管控、团队协作等等功能。

我们用的是 jira,哎,其使用体验简直一言难尽。我总是疑惑,为什么大部分公司,使用的效率工具都那么难用呢?

到了研发排期,对于产品经理来说,大部分就是项目管理的工作了,一般会用到项目管理的工具。

需求变更

研发过程也不会是一帆风顺的,仅仅一次评审会是根本不可能把每个需求对应的功能点讲明白的,所以,在研发的过程中,总是会有各种各样预期之外的情况出现。

即便是被划到研发排期里的一些需求,也不一定是都能实现的。很多时候,我们更加在乎的是什么时候上线。在限定的时间内,对需求的取舍是产品经理需要做的决策。

另外,在实现一个需求或者功能点的时候,往往还会产生其他的需求,这部分也可能是设计之初没有考虑到的。

针对这类需求,如果不影响整体使用流程,可以直接扔进需求池;如果涉及到整体流程的问题,那么就要「加塞」实现了。

怎么加塞呢?只能是舔着脸跟研发说好话呗,还能怎么办,产品狗产品狗嘛,不就是这个意思嘛。

谁叫你当初没有想清楚,这种情况出现得多,说明你做产品的「手感」还欠锻炼。

需求变更的环节,是产品经理职场沟通能力的体现。如何处理自己设计问题导致的需求变更?如何妥善处理领导临时加塞的需求?这些都是职场沟通技巧。

复盘总结

版本上线之后,通常会有产品发布以及复盘总结的环节。

产品发布是针对市场做产品新特性的介绍或是使用培训。复盘总结就是团队内部的自我检查了。

针对需求这块的复盘,我通常都会做一个统计。主要包含以下几个方面内容:

1.规划之初,池子里有多少需求,这个版本规划了多少需求 2.评审之后剩下多少需求,被砍了多少需求 3.最终实现了多少需求,又新增了多少需求

统计这些数据,并不是为了统计而统计,而是想要盘活这些数据,定期的过一遍,进一步加深对这些需求的了解,对后面的版本规划或者优先级决策,都会有帮助的。

前面做的每一项细节工作,在后面的流程中都会起到促进作用。有些人做事情,越做越轻松,就是这个道理,而有些人永远都在混乱中忙碌。

需求是产品的第一步,做好它的管理,尤其重要,它是后面每一个决策的重要参考依据。