建立「需求管理机制」的流程和要点

编辑导读:需求,是戴在每一个产品经理头上的紧箍咒。产品经理每天要面对大量的需求,建立需求管理机制能够帮助产品经理更好地工作。本文作者对此进行了分析,希望对你有帮助。

产品经理每天都需要面对大量需求,很多朋友会通过“需求池”对零散需求进行统一、高效、有序的管理。但需求池只是需求呈现的载体和工具,并不能包治百病,实际操作中会出现各种意外,比如:

  • 无效的需求记录:不是指需求记录的不清晰,而是指明显不符合产品定位、场景不明确的需求未经筛选就被记录。

  • 超量的高优先级:需求方都认为自己的需求更重要更紧急。面对多方的各种催促,出现了大量高级别需求,导致等级制度失效。

  • 短视的版本规划:将迭代周期内的需求塞满即可。把需求、设计、上线做成了下意识的循环,缺乏产品整体层面的发展规划。

为了避免需求管理的效果打折扣,接下来根据需求的流转,依次讲解需求处理过程的管控要点。

超级产品经理

01 需求的有效采集和过滤

需求是产品的源头,产品是需求的解决方案。所以,有效采集需求是需求管理的第一步。虽然每个产品所处的环境存在差异,但是为了不在需求阶段迷失其中,需要从全局角度对需求来源、采集方法、需求筛选(初步)有整体的认知,便于后续对不同需求采取更合适的应对策略。

1. 需求获取渠道

不同产品的适用场景和使用角色都不一样,造成了需求来源较为复杂的现象。可以通过渠道通用属性的方式进行分类。

分类目的在于全面了解产品的相关方,避免遗漏。毕竟不是每个角色都会主动反馈问题和需求,更多情况下需要产品经理主动沟通和挖掘。产品经理不要忘记“沉默的大多数”。

渠道分类的维度也多有不同,本文以内外渠道区分为例:

  • 内部同事:组织内任何和产品相关的角色都有提建议的权利。比如:Boss、销售、运营、技术等。

  • 外部客户:客户通过对应渠道反馈产品需求或问题。在项目中客户也区分决策人、使用人等多种角色。

  • 产品经理:基于对产品、用户、发展战略的观察、分析等行为,进而得出需求。

2. 需求采集方法

需求获取的方法是多样的,有的是产品经理通过设计进行获取,有的是客户主动进行反馈。具体方法如下:

  • 产品方获取:由产品方主动获取需求的方式。如:行业研究、调研问卷、实习轮岗、数据分析、现场访谈……(详见:B端需求调研:客户访谈操作详解)

  • 客户方反馈:由客户方主动反馈需求或问题的方式。如:客服咨询、用户投诉、意见建议、公开渠道的评价(微博、垂直社交媒体……)

超级产品经理

客户主动反馈时,产品经理并不能改变采集方式。针对产品经理主动获取情况下,采集方式应当如何选择?我们知道每种方法各有优劣,要结合实际情况灵活选用。影响选择的关键因素有哪些呢?我认为至少考虑以下3方面:

  • 用户是否接受此方式?面向不同角色,或同一角色的不同场合。用户对各方式的接收程度都是不一样的。有时我们希望面谈,但客户总是没时间……

  • 资源是否支持此方式?公司的时间、人力等资源都是有限的,产品经理需要在合理资源限度内完成采集。比如实习轮岗,可以较深入的了解现场,但耗时太长,通常采用的比较少。

  • 能否达到采集的目的和效果?如果调研后没有达到目标,意味着采集无效以及投入资源的浪费。

3. 需求初步筛选

通过各个渠道获取需求后,就进入的记录阶段。会发现需求总是源源不断的过来,但是产品经理的精力以及公司的资源都是有限的。所以要辨别需求的真伪和潜在价值,把不符合要求的需求剔除,不计入该产品的需求池中,避免后续资源的无效投入。

筛选的过程是“砍需求”的过程,是对需求潜在价值判断的过程。除了要对产品本身有所了解,也需要专业能力的支撑才能更加准确的判断。事实上,从需求收集到研发上线之间会经过多次“砍需求”。

此时作为初步筛选,要求并不严格。只需要做2件事:需求场景还原,需求属性分类。

1)需求场景还原

需求有对应的完整场景是筛选的第一步,如果还原不了场景,则认为需求是假需求。场景还原只需要问几个问题,能回答出来且逻辑自洽即可——谁(角色)在什么情况(背景)下,遇到了什么问题(需求)?当前的处理方法是什么?

场景还原时需要将相关的场景进行穷举,避免因场景遗漏导致后续产品设计时出现漏洞。

需要注意的是,有的需求场景还原完整,但不符合本产品定位,此类需求对本产品无价值,但需求本身没问题。建议记录在另一张需求池表单中,作为外延产品的需求储备。

2)需求属性分类

除了需求基本的信息记录,还要判断需求的类型,为后续的需求评级和需求分析提供支持。比如:核心需求,基础需求,衍生需求,技术需求,运营需求,体验需求……

需求分类同样没有标准答案,存在多种维度的分类方式。重点在于你定义的需求类型,在后续分析中是否存在对应行动策略,如果仅作为需求池的统计查看使用,意义不大。

存在潜在价值的需求将被一一记录在需求池中,等待下一轮的筛选和价值分析,直到被某个版本选中……

02  优先级的制定和维护

初步过滤可以把部分需求排除在外,剩余需求将被纳入到需求池中。至于选择哪些需求进入实现阶段,则根据需求的优先级来排序。每个团队都应该有自己的优先级评估标准——你的优先级评估标准是什么?评估标准又是怎么维护的?

1. 区分需求所属类型

在制定具体的优先级规则之前要先区分需求类别,不同类型的等级制定策略存在差异。可以基于“产品管理权”和“需求确定性”来划分需求类型。

1)基于“产品管理权”划分

在公司内部,一款产品的管理权限通常是由多个角色共同组成。不仅有产品经理,还有运营、上级领导等其他角色也具备管理权。

  • 响应性需求:对应角色行使自己对产品的管理权限,产品经理没有拒绝的权利,根据具体要求排期和执行即可。比如运营同事策划了一场活动,需要在产品中实现。此时产品经理没有拒绝的权利,只要建议的权利。

  • 自主性需求:当产品经理在处理自己管理模块内的需求时,其他角色也不能拒绝(领导可以拒绝)。其他人同样可以提供建议。并不是要产品经理刚愎自用。

2)基于“需求确定性”划分

针对自主性需求也要区别对待,首先是判断需求实现结果的可控性,面对可控和失控的需求要制定不同的策略来应对。

  • 不确定需求:对需求实现的结果预测精准度过低,不具备参考价值。常见于全新业务情况,没有过往数据和历史经验作为参考。面对此类需求通常采取MVP策略。

  • 确定性需求:对需求实现的结果预测相对准确的,可以将需求代入制定好的优先级等级,进而找到优先级顺序。(本文针对此类需求的优先级进行讲解)

2. 制定优先级标准

优先级标准是判断各需求实现先后的依据。比如Bug优先还是需求优先,实际上当然不会如此粗犷。可以用常见的重要紧急程度、KANO模型等方法帮助我们建立和细化等级标准。

1)重要程度:以产品目标为中心

假设有2个需求,实现需求A可以带来新用户10000人,实现需求B可以提高活跃用户10000人。可使用的资源有限,只能实现1个需求。你会选择那个需求实现呢?选择依据是什么?

需求重要程度的判断依据是“产品目标”,契合产品目标的需求就是重要的需求,偏离产品目标的,不论能够带来多大的收益,都不能称之为重要。

产品目标是根据公司战略、产品定位、发展规划、领导决策、用户反馈(KANO模型 – 期望型需求)等综合因素制定的。产品目标落实到执行层面,会反应在某项数据指标的变化上。比如:产品/某活动/某功能的拉新;产品/某功能的促活;某环节/某功能模块转化;商业化指标……

需要注意区分用户目标和产品目标。提升效率、降低成本、优化体验等以用户视角提出的诉求都是用户目标。需要把用户目标转化转为为产品目标。比如,在满足了提升效率的用户目标后,会达成产品目标数据指标A的变化。

2)紧急程度:以严重程度为中心

假设产品目标是提升拉新数据,现在有2个需求,需求A可以带来新用户10000人,需求B会带来新用户1000人。可使用的资源有限,只能处理其中1个。你认为那个更紧急呢?

很显然,多个需求都满足产品目标时,效果越好的越优先(紧急)。

假设产品目标是提升拉新数据,现在有1个需求和1个Bug,需求可以带来新用户10000人,Bug会造成流失用户5000人。可使用的资源有限,只能处理其中1个。你认为那个更紧急呢?

处理Bug时不考虑产品目标(重要程度),只考虑紧急程度。把需求和Bug的紧急程度放一起对比,之后再根据各自评估的严重程度来决定先后顺序。通常采用如下的紧急程度标准:

P1:处理需求,获得良好的正面效果

P2:处理Bug ,避免持续的严重损失

P3:处理需求,获得一定的正面效果

P4:处理Bug ,避免持续的轻微损失

3)其他代价:关联指标的变动

经过重要紧急程度的筛选,我们可以得到重要(符合产品目标)的需求和Bug,并根据紧急程度进行排序。实际操作中还需要注意需求实现后的其他代价!

这里的代价不是指实现需求的成本,而是指需求实现后对产品目标之外的其他数据的影响。正面影响也就罢了,需要格外注意负面影响,负面影响会改变需求的价值。

假设产品目标是提升营收,现在需求A是向用户端投放广告,预测能够获得50万营收,但是会造成3万名用户的流失。这时候需求A还是高优先级的需求吗?

3. 需求等级的动态调整

产品目标不是一成不变的,产品目标变更后对应的优先级标准也同步变化。标准变更后,各需求的优先级也要重新评估。

比如:产品目标从原来的提升“活跃”数据,变成了现在的提升“拉新”数据。对需求A的结果预测是能够拉新1000人,促活100人。需求A对拉新显然价值更大。结合产品目标来看,需求A的价值随着产品目标变更而同步变更,从低优先级转变成高优先级。

产品目标的变更有什么规律?变更的影响因素和建立时一样,此时更关注目标变更的触发点。基本分为2种:定期变更、临时变更。

  • 定期变更:通常以1个季度为周期,定期检查产品所处环境和发展进度是否符合计划。出现脱节时要及时调整,避免发展偏航。

  • 临时变更:通常是因为市场、政策、竞品、产品自身发展突然出现重大变化,所以需要及时关注产品相关的重大事件,便于及时应对。

03 契合优先级的需求序列

当我们获取了有效需求,建立了优先级规则。各个需求具体的优先级顺序如何排列呢?大部分公司都有自己的优先级制度,但是为什么执行总是不如人意?可能是因为执行力松散,也可能是因为对需求价值的判断失误。

一旦实现的需求选择错误,会造成数据结果不能满足产品目标。意味着投入的时间,人力等资源的浪费,也可能导致产品在瞬息万变的市场上失去竞争机会。所以要建立更加细化的规则,进而量化需求的价值。

超级产品经理

1. 判断需求属性

对“确定性需求”的优先级排序,首先根据“优先级”的重要程度判断需求属性——即:需求是否符合产品目标。

需求的实现会影响产品的多项数据表现,列出受需求影响程度较高的数据项和产品目标进行匹配。选取匹配程度更高的需求进入当前版本的“待定清单”中。

比如:产品目标是提升拉新数据;需求A有效提升活跃数据,拉新数据影响不大;需求B有效提升拉新数据,活跃数据影响不大。所以会选取和产品目标更匹配的需求B。

通常1个版本中只有1个产品目标,更有利于增强目标的实现效果。如果设立了多个目标,则需要先对各目标本身做优先级排序,并分配对应的权重。估算需求的对各目标的效果后,结合目标权重再重新进行需求排序。

2. 量化需求价值

假设需求A、B、C都进入了本版本的待定清单中,现有的资源有只能够实现2个需求。那么淘汰谁?剩下的谁先谁后?只有对需求价值或Bug的影响进行量化,才能够得出较为客观的结论。换言之对产品所带来的正向数据变化就是需求的价值所在。

需求价值的计算过程中,需要充分考虑关键影响因素。公式表达:需求价值 = 潜在用户数 x 转化率 x 使用频次 x 用户价值 – 关联指标负面影响

1)潜在用户数

  • 评估需求会影响的用户类型,再估算对应类型客户的数量。

  • 用户类型根据企业内部对客户的分类。比如:普通用户、会员用户、活跃用户。

  • 估算对应用户数量时,注意用户的存量数据和增量数据。

2)转化率

  • 预估潜在用户使用该需求对应功能的转化率。

  • 转化率一般按照活跃度来计算,不同类型用户的活跃度不一样。

3)使用频次

  • 估算目标用户一定时间内使用该功能的次数。针对不同类型的需求采用不同的时间长度计算。

  • 见效快的需求,计算时间周期短,如1~3月;见效慢的需求,计算时间周期长,如3~6月。

4)用户价值

不同类型的用户价值需要分别计算。比如:普通用户和VIP用户对产品的贡献是有巨大差别的。

5)关联指标的负面影响

  • 考虑效果时不仅要考虑正面收益,也要考虑需求实现对关联指标的负面影响。

  • 计算收益要减去需求关联bug负面影响。比如:需求A可促活3000用户,bug可导致1000用户流失。所以预估效果应是促活2000用户。

  • 特别需要注意需求实现付出的其他代价。比如:添加广告可以提升收益数据,但是会降低活跃等数据。

3. 需求的性价比

计算出需求价值后,按照价值高低排序就是我们要的需求优先级了吗?这样的想法依然过于片面。做决策不仅要考虑收益,也要考虑成本和性价比。

1)需求成本估算

这里的成本是指实现需求所需要投入的人力成本。同时为了计算方便,一般会将不同岗位的人力成本设定为同一个价格。用公式表达:人力成本 = 所需人天 x 单位人天费用。

比如:需求A实现需要产品设计3天、UI设计2天、研发测试5天,人力成本是500元/人天,则需要A的人力成本是5000元。

2)实现的性价比

最后一个步骤就是计算需要实现的性价比。根据性价比排序,性价比越高则排序越靠前。到此,完整的需求优先级才算制定完成。用公司表达:性价比 = 需求价值 / 人力成本

比如:需求A的需求价值50000元,实现需求的人力成本5000元,则性价比是10;需求B的需求价值20000元,实现需求的人力成本1000元,则性价比是20。综合来看,虽然需求A更有价值,但是需求B的性价比更高。因此需求B的优先级高于需求A。

附:“需求池”概况介绍

超级产品经理

1、创建方式

需求池的创建方式并不固定,团队内保持一致即可,使用Excel或项目协同软件都行。比如:Teambition、禅道……

2、表单字段

需求池的具体字段可根据团队关注的要素自行调整,也可以把部分字段转移至关联文件中,比如在“产品版本”文件中记录各环节的负责人、计划用时和时间段、实际用时和时间段等信息。主要包含以下:

  • 基础信息:需求方、提出时间、需求编号、需求概述、需求详情

  • 需求属性:所属模块、所属功能、需求类型、需求状态、重要程度、紧急程度、需求等级、产品负责人、产品版本

3、补充说明

  • 需求详情:完整需求的描述较多,通过图文等形式呈现,不便在excel上呈现。通常会用独立文档记录。通过“需求编号”检索查看“需求详情”。需求详情同时会记录需求方、提出时间等信息。

  • 所属版本:版本规划属于项目管理内容,在对应“项目管理”表单中会标记需求实现各环节的负责人、交付物、计划和实际用时、开始和结束时间等信息。

作者 @耳目不染

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击下方“内容举报”进行投诉反馈!
立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部