有条不紊,三个步骤管理好需求池·「解剖产品经理工作流

上一篇我们讨论了需求分析,主要从需求的对象、需求的意图、需求的成本三个维度去探讨,接下来我们讲一讲需求池。

需求池对于圈内产品人来说是想当然的存在,因为几乎每天都会面对,但你可曾认真想过为什么会有需求池?

在时间上,需求的收集可能比较分散,但也可能蜂拥而来,将需求传达给设计、研发还需要进一步评估、转化,这需要花费不少的时间,这时候需求池提供了一个缓冲空间,平衡了需求的供给,同时需求池也是调控项目周期的重要工具,有规划版本作用。

需求池看似简单,想做好却也不容易,我们再来了解下管理需求池有哪几个重要环节?

如果把需求池形象化,那么蓄水池再合适不过。蓄水池是一个蓄水设施,想要蓄水自然需要有水的流入,蓄水的目的是为了平衡水的流出。如果想蓄水池发挥更高级作用,那么在蓄水的同时通过滤悬浮颗粒、去除有机污染物、处理可溶无机物等工序净化水质,使其流进来的是污水,流出去的是净化水。

如同蓄水池一般,管理需求池可分为三个重要环节:需求输入、需求转化、需求输出。

下面我们针对这三个环节逐一讨论。

一、输入-需求录入

经历了前面用户需求分析,我们已经得到需求的大致样貌,需求池既然作为一个缓冲区,需要把需求基本信息清晰地记录起来,既要把原始需求描述清楚,也要把分析后的场景、服务对象记录好,等下一次再看时,能够还原需求本质而不产生歧义。

储蓄字段

需求池记录方式不限制,可以简单的用表格文档,也可以用项目协作工具,只要能把需求描述清即可,一个合格的需求池里应该有以下几个字段。

需求来源,记录需求从那个渠道获取,方便后期跟踪核对。

需求描述,记录第一手需求描述,方便后期跟踪核对。

需求场景,场景化是需求推演的重要依赖。

服务对象,需要仔细甄别,提出者与需求受益者并不一致。

本质意图,有别于需求描述,记录经过分析后的需求目标。

提出时间,有些需求存放过于长久的时需要重新取舍或再分析。

优先级,是输出版本规划的重要依据。

上面提到只是基本字段,需要根据产品性质、公司流程酌情增加。

诸如需求场景、服务对象、本质意图等在第一阶段的需求分析已经有了答案,现在只是组织言语依次填入。

比较特殊的是归类,大部分的需求池都会有,但实际上有不少的归类仅仅是为了存在而存在,对于需求的描述并没有多大帮助,有的甚至造成误导,这个需要本身工作流已经形成清晰的需求分类才考虑,这是需要注意的细节。

优先级排序

关于优先级,也有不少人总结出一套完整的流程,大致是通过KANO模型对用户满意度的分析,根据基本需求、期望需求、兴奋需求、无差异需求、方向需求五个特征给需求打分,再综合紧急程度、开发成本、研发周期等最终评定出优先级。

看起来很棒,这种精细分析针对于某个大需求或整个产品去做调研,分析效果不错,但大量运用于每个需求几乎是不可能的。

首先需求的满意度从何谈起?必须通过用户调研或数据分析才能建立模型,这样做需要花费大量的人力与时间,显然不适合应用在每个需求上。但如果不这么做,那么这个模型就只能依赖产品经理的主观经验去判定,然后打分,那何必绕一个大圈子来掩饰自己的主观意识呢?乱了思绪也乱了工作流程,因此我并不推荐。

工具方法是好,但不应该乱用,老老实实结合当前产品周期,给需求定一个需要完成的时间,通过这个时间排个序,完事。后期根据研发排期也可灵活调整优先级,坦白承认这确实依赖工作经验,但随着实践次数的增多,判断会越来越准确。

二、转化-需求转述

当我们接了许多活忙得昏天暗地时,我们肯定很想找人分担下,把一堆的需求锅丢给设计师、程序猿,给他们制造点“麻烦”,想想就是兴奋。但一股脑直接丢过去估计是要打架的,互联网八卦咋们忍住不谈,记得别这么干就是了。

转化产品需求描述

尽管在这之前我们已经确定了需求背后的意义与其基本的可操作性,从开发的角度而言,这个叫做用户需求,是关于用户意图的实际描述,然而具体怎么做,设计师、程序猿们不一定能很好的理解。

打个比方,用户的问题是“某一个页面的按钮很被难点到”。从产品的角度看,放大按钮、调整位置,似乎都有助于改善用户体验,改哪一个?一起改?这个问题的解决方法是模糊的。

实际上还有一种可能,并是不按钮太小跟位置问题,而是点击按钮时都会有短暂时间的无响应,这在用户看来就是没点着,如此一来,无论在视觉交互上怎么修改,都解决不了问题。

所以,产品经理作为用户与团队对接第一人,需要拆解问题、分析功能,将用户需求定到位,最终转义形成适合于产品开发的功能描述与产品目标,再一并传达给研发团队。

与团队先切磋

产品经理既然承载了用户与团队的沟通桥梁,多沟通是关键,避免梳理出一大堆研发团队看不懂的文档。

想在沟通层面做好,首先,要善于分享,这需要苦口婆心多次重复,越是重要的事越需要被重复提及才能被理解、被记住,有能力的管理者通过沟通将产品的核心理念清晰的往外传达。其次,要不耻下问,在沟通中保持开放,产品经理干得活不少,会面临到许多方面的问题,有些问题需要留给垂直能力突出的专业人士来处理,我们需要做的只是抛砖引玉。

也只有研发团队了解产品的核心理念,再通过他们进一步转化相关的需求描述,这样的需求描述是建立在大家共同的认知上,才能为后期避免很多因歧义产生的争论。

三、输出-版本规划

关于输出,主要是决定当前需要实现哪些需求,既是为下一步的需求评审确定好内容也是对产品的版本规划。

顶住外界压力

当我们在确定当前要实现哪些需求时,几乎每一个部门都认为他们的需求才是最重要的,包括老板,有木有?

切莫被各个部门牵着鼻子走,记住我们才是专业的,老子说了算,要有霸气,要有骨气。

当然,适当调整需求的优先级也是可以的。(猥琐,嘿嘿)

需求关联

版本规划不应该着眼一个需求,应该站在全局的角度去思考,在需求功能上下钻挖掘,在需求模块上横向联系,在理清楚需求之间存在的关联后,将有联系的需求规划在同一个版本输出。

从长期来看,关联严谨的需求集合有助于项目的快速推进。

简易文档

如果前面的工作都做好了 ,那么文档的输出就是水到渠成的事。这里需要形成的是简易文档或原型,后期再逐步深入,我们这里是启动阶段,主要以磋商为,文档也是以交流为主。

当我们做到这里,需求池管理的基本工作已经结束了,下面总结一下流程。首先,整理需求录入排好优先级;其次,与团队积极沟通形成产品需求描述;最后,联动需求规划好版本输出沟通文档。

以上就是本期内容,每个人都有属于自己的工作方式,找到合适自己的才是最重要,小龙只是抛砖引玉,希望对你能有所启发。下一期需求评审,咋们不见不散。

 往期回顾:

『解剖产品经理工作流』需求分析

『解剖产品经理工作流』立意篇


小龙将产品工作拆分为4个阶段,分别是产品启动、产品设计、产品研发、产品运营。

近期主要说说产品启动阶段,包括立意、需求分析、需求池整理、需求评审、立项。

产品千千万,思维价更高,从大局思考,从小事做起,欢迎各种探讨。

公众号:来自小龙的执着(ID:york_wu1219_office)

你可能感兴趣的:(有条不紊,三个步骤管理好需求池·「解剖产品经理工作流)