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

最近整理了下所负责产品的需求清单,整理完之后,整个人感觉轻松多了,于是,想分享下这短暂的愉悦。

原本标题想叫:如何做需求管理?感觉题目太大了,由于个人产品经历的局限性,我充其量就能分享下自己的做法,仅供参考。

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

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

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

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

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

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

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

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

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

好了,扯远了。

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

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

建立需求池

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

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

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

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

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

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

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

版本规划

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

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

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

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

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

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

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

top Created with Sketch.