火狐体育最新版:需求价值量化及优先级排序方法
来源:火狐体育娱乐平台    作者:火狐体育最新版    发布时间:2022-12-06 06:10:14

  需求源源不断,资源是一直紧缺的。我经历过的互联网企业,都是需求等人,没见过人等需求的。一旦出现人等需求的情况,那只能说岗位设置冗余,就可以考虑优化了。在此背景下,如何把好钢用在刀刃上,就愈发重要。

  需求多研发资源少的情况下,需求管理首先要解决就是需求优先级顺序的问题,对口的业务多,每个人都说自己很重要,先做没意见,后做都不满意。

  按照合作关系远近亲疏,还是按照提需求的时间,谁先提做谁的?对于产品、研发团队的管理者,不同产品经理、不同产品模块的需求放到一起抢占研发资源,该怎么安排, 会哭的孩子有奶吃 吗?手心手背都是肉啊。最终绩效考核的时候,总不能按照上线的需求数量来评判 ABCD 吧。

  但临时的需求、一些因为政策、战略等紧急的需求又在所难免,不能每次来紧急需求都要求开发加人,或者周末加班吧?

  新人产品经理往往容易被堆积如山的需求搞得手忙脚乱,需求池里躺着上百个需求,做产品规划时却无从下手。

  感觉每个都应该做,资源受限,却好像哪个都可以不做。怎样才能挑出大的西瓜,而不至于被一粒粒 芝麻 蒙蔽了双眼。

  研发人员像机器一样,持续不断地输入需求,变现需求。但却没有成就感,甚至觉得自己就是个变现工具人。

  从 人人都是产品经理 开始,就有了各种各样的需求管理的方法论。在过去 10 多年的产品工作及团队管理工作中,发现很多方法论也就停留在方法论层面,实际操作时,还需要个人的 悟性 ,悟性差的可能整个职业生涯中,都难以掌握到底什么样的需求才算是重要且紧急的需求。

  每个人都知道应该优先去做重要且紧急的需求,但问题是作为新人产品经理,重要程度和紧急程度的判断依据是什么?每个人都说自己的需求非常重要,并且想越快上线越好。

  Kano 模型按照用户对于需求的期望程度划分为基本需求、期望需求、兴奋需求等五种类别,实际操作时,该怎样客观地描述不同用户对于需求的期望程度?

  ICE 排序法按照需求影响范围、完成需求的自信程度以及开发实现难易三个维度进行需求量化评分,最终按照得分值高低,确定需求优先级排序顺序。

  对于体验优化类或者流程提效类的产品,用户影响范围的权重一样是否合理呢?比如老板用的管理驾驶舱产品,就三五个高层使用,他的价值就不高了吗?

  结合各方对于需求优先级排序的诉求以及现有需求分析模型存在的问题,结合数据产品的特点总结出一套用于量化数据产品需求价值的方法,可以为你提供一些新的思路和启发。其核心思想:

  分类:不同数据产品或同一产品的不同需求,总结下来主要分为体验优化类、流程提效类、业务增收类几个大的类别;

  权重:不同类别的需求在量化维度上的权重理应不同,比如业务增收类的需求,更应该看重带来的业务营收价值,相应的权重设置更高,在降本增效维度权重可以适当调低;

  打分:每个维度按照产品的实际情况,进行打分区间的设置,例如采用 10 分制,用户影响度,全部用户,10 分,60% 以上 8 分,30% 以下 4 分,以此类推。

  任何产品需求都是为了解决用户问题,所以需求涉及的用户范围是一个重要的评价维度,但这里需要细化不同类别的需求,比如做一个 CDP 精细化运营产品,主要的用户就是运营部、营销部的几个人,即使每天都会使用,但是 DAU 终归就那几个人。对于用户体验类的需求该维度权重可以设置 30%-50%,而流程提效类 15%~25%,业务增收类的权重可以适当降低。

  外部环境政策的变化或者公司新战略的推行,产品迭代时,也要考虑这个维度。如果只是闭门造车,按照已有的优先级严防死守,那对于公司的影响可能是致命的,比如《数据安全法》《个人信息保护法》施行后,应对安全合规检查的功能需求,会影响产品甚至公司的生死存亡。

  此外,对于老板的需求第一时间去做或者不予重视都不可取,把战略契合度加到评估维度中,则可以有效应对这一类需求。战略契合度各类需求的权重设置控制在 15 以下。

  这一维度主要用于衡量用户对于这一产品功能的期待程度,不做用户感受是怎样的,做了用户是不是对产品满意度大大提升。这一维度的评分区间划分可以基于 Kano 模型进行,基础需求 10 分,期望需求 8 分等

  对于 B 端数据产品,多数还是帮助业务提升数据决策和应用的效率,通过产品功能的迭代,到底可以带来多少降本增效的价值。

  比如基于标签的人群自动化圈选功能,没有上线这个功能时,单个营销场景耗时 3 小时(SQL 取数、数据上传等),每周至少 2 个场景应用,功能上线 分钟搞定,那么带来的提效价值就是单次操作节约时长 × 操作频次 × 统计周期,按照节约的时间成本换算成人力成本,按照价值区间进行得分。流程提效类需求,该维度权重适当增加。

  数据赋能类的需求,比如算法推荐接口、API 接口,其目标是基于数据为产品提供更加智能化的应用,按照接口调用量或者用户请求 UV 去看,都不合理,而按照对应服务可以带来的实际业务增量,换算成 钱 再去看,就更加合适。比如按照不同功能类别,划分营收或订单增量这一维度的得分区间。

  从时间成本和人力成本两个方面,如果用前面五个维度的正向得分除以成本,区间划分时,成本越大,最终得到的结果就越小,总分值就越低。

  成本两个维度主要是辅助参考,这个具体操作时,需要不需要把成本作为分母,可以根据实际需求定,因为一旦相除,可能就意味着得分降低,价值度高但是开发耗时长资源投入多的需求就一直没法做了。

  在权重设置、每个维度的得分区间划分时,要结合产品实际情况建立符合实际的标准,不能直接拿来主义。

  需求价值量化需要业务方配合,通过宣讲、需求流程优化等方式,让各方对价值量化的意义有更加清楚的认知,而不是为了拒绝需求或者增加提需难度,作为产品经理把需要业务侧提供的指标具象化,避免直接让业务去操作需求量化的结果。

  如果对于每个需求都需要人肉计算得分,势必会影响工作效率,当相关的权重、维度、得分区间沟通确认固定下来后,可以整合到需求管理系统,用户提交需求加上产品经理审核、处理需求时,完成对应的得分赋值,系统自动化计算最终的得分,在一个需求池列表中,确定优先级顺序。

  需求管理的好不仅是自身产品能力的体现,对于协同团队也会认为你是一个靠谱的人。需求先做哪个后做哪个,建立一个清晰、明确的价值量化标准,优先做对的,有价值的需求,这样才能在人力不够的情况下有更高人效的产出。结合文中提到的需求价值量化的思路,看看如何与当前的需求管理工作结合起来吧。

  数据干饭人,微信号公众号:数据干饭人,人人都是产品经理专栏作家。专注数据中台产品领域,覆盖开发套件,数据资产与数据治理,BI 与数据可视化,精准营销平台等数据产品。擅长大数据解决方案规划与产品方案设计。



上一篇:井松智能姚志坚:投身智能仓储物流 “星辰大海”
下一篇:电气ERP系统哪个靠谱?操作简单的ERP有吗?