【指标需求思考】如何做好指标类需求建设

简介: 大家一直所说的【需求】究竟有哪些?用户需求、业务需求、系统需求...... 但是今天我要给大家介绍一种我自认为一种别出心裁的需求!【指标类需求】在庞大的需求体系里,一个完整的系统设计流程是非常必要的,好则效率百倍,坏则加班熬夜。本文尝试以另一种需求管理方式来处理一种特殊的需求【指标类的需求】,希望大家能所有收获一起成长。当然不积跬步无以至千里,不断的进阶才是王道!欢迎大家一起交流!

image.png

作者 | 轩北
来源 | 阿里技术公众号

一 前言&序

大家一直所说的【需求】究竟有哪些?

用户需求、业务需求、系统需求...... 但是今天我要给大家介绍一种我自认为一种别出心裁的需求!【指标类需求】

在庞大的需求体系里,一个完整的系统设计流程是非常必要的,好则效率百倍,坏则加班熬夜。

本文尝试以另一种需求管理方式来处理一种特殊的需求【指标类的需求】,希望大家能所有收获一起成长。当然不积跬步无以至千里,不断的进阶才是王道!欢迎大家一起交流!

二 指标类需求

1 什么是指标类需求?

指标类需求,顾名思义也叫分析性需求,是需求的一种变种,本人在商品开发中负责品规的阶段,如果把整个供给侧划分成一个战场那么品规侧承载着制造五花八门弹药的使命,在制造弹药的过程中,我们要做到以下几点!

  1. 分析市面上有什么好的弹药?(参考)
  2. 最近制造什么类型的弹药更能影响战场?(分析)
  3. 最近哪些弹药卖的好还便宜,日均销量不错的,gmv不错的!(找到)

2 for example

如下需求:

给我计算 各种维度 = 月日均+爆品数+订单分层+类目分层+质量分层+排行榜+品控+gmv+人标签+店铺+使用率+渗透率xxxxx等等等等......

冰山一角!不足1%,可想而知多么可怕。

总结来说业务的视角看,品规承载着以下几点:

image.png

①行业的洞察能力
②竞对分析能力
③标签能力
④规划能力....

总结来说,数据驱动供应链变革,把数据变成钱 。

在当前的阶段品规侧,计算了大量的指标。据不完全统计,我已经计算了大概不亚于几千个指标,本人对于这种需求也是一脸懵!月日均,爆品数,订单分层,类目分层,质量分层,排行榜,品控,gmv,人群,应季,趋势,增长率,曲线,复合曲线...... 哪一个拿出来都够喝俩壶了。

3 指标类需求难点?

在海量的指标需求下,总结来说有以下几个问题?(在当PM熬过无数个日夜决定痛定思痛)

  1. 如何进行数据口径定义?
  2. 如何保证指标的开发无误?
  3. 如何进行指标开发?
  4. 如何进行指标验证?
  5. 如何保证开发时间不被数据check打扰?(正在开发功能说数据不对,check数据导致功能延迟加班熬夜!)

以下是我在进行了一定的指标需求后得到的一点点经验,希望和大家一起分享下!

三 如何解决

剑道有守破离三层境界:

守——按照既定套路出招

破——试着突破创新,让自己进化到更高境界

离——看透本质,大道至简,无招胜有招

对于这种需求不破不立我们可能要打破原有的需求设计的规则单独定制一种规则,下面这个图是我通过不断地踩坑总结出来的一种方式。

1 需求阶段(开发侧)

我把整个指标分析型需求拆解为俩段:

指标开发+功能开发(单独拆开以下是流程)

image.png

image.png

指标开发几个阶段:

1)指标初步确认阶段

在指标初步确认阶段我们要做的需要几步:

  1. PD+开发+测试 从prd中提炼出要开发的指标
  2. 确认指标开发口径

2)指标计算阶段

在指标计算确认阶段我们要做的需要几步:

  1. 开发按照口径进行指标数据开发
  2. PD+开发+测试 验证指标
  3. 开发修改指标
  4. 继续验证循环过程直至完成

3)指标最终确认阶段

  1. PD+开发+测试 指标确认完成check
  2. 开发侧产出数据指标对焦sql

总结来说:

  1. 开发测试PD统一根据prd统一确定指标与指标口径
  2. 开发先去计算指标计算完成-----> 测试和PD验证
  3. 开发修改-----> 测试PD再去验证
  4. 保证在正常功能开发前,指标数据确保无误

测试与PD在指标计算时,提前介入,开发提前计算,提前测试,在正常功能前保证数据指标完整

2 需求阶段(PD侧)

三个要点(个人的三个建议)

image.png

1)指标要具有确定性

爆品定义是什么?分层的定义是什么?口径要先定义清楚,方便后面开发!

2)指标要具备可开发性

3)指标与功能匹配性

需要所有的需要的指标要全覆盖避免漏指标,指标再次计算往往耗费人力更为可怕!

3 需求阶段(测试侧)

参与开发指标的全流程的对焦,开发侧在产出数据后进行数据验证sql产出。

四 经验思考

1 数据前置

指标数据分析型需求我们需要拆解,把数据开发测试校验前置,可以有效避免在开发功能时,数据check影响整体进度,往往找一个指标的错误,会比功能错误难上几倍!在大数据的情况下尤为如此!所有前置条件做好可以有效避免项目的判断失误,可以让项目有效的进行!

2 数据分析

在测试与PD要介入确定问题时,可参考以往数据!避免重复对焦不准确。

如何与测试建立指标的测试规范下一篇文章我可能会继续迭代出来!让指标的验证不仅仅有迹可循,也让错误无处遁形!

3 如何减少指标计算

既然指标计算无可避免那么我们应该如何去减少指标计算,节省人效,之后我会去分享下商品开发&运营 品规侧在计算了无数指标后,痛定思痛,如何尝试与数据应用团队结合来提高我们的指标计算效率!节省人效,非常nice!就不用大量的人工计算不同层级维度的指标,环比数据等等,这期间品规域我与同事进行了很多的尝试。

大概思路为:

image.png

人效从4天左右 - 2天左右!

五 完结

在做指标类需求过程中,从小白到一个数据开发值得信赖的数据开发者,是一个痛苦和漫长的过程!在这过程如何保证开发数据的周期,如何更快的承接需求,如何更高效的计算指标,减少人效是值得深思的地方,希望本文能够帮助你!


阿里云镜像站体验官招募中,Airpods耳机等你来领!

镜像站体验官第二期招募回归, 在各大社区平台分享相关内容累计积分就可赢得Airpods耳机和移动硬盘等奖励,银牌体验官的奖励人数不设限

image.png

相关文章
|
设计模式 IDE Java
谈谈过度设计:因噎废食的陷阱
写软件和造楼房一样需要设计,但是和建筑行业严谨客观的设计规范不同,软件设计常常很主观,且容易引发争论。
3451 4
谈谈过度设计:因噎废食的陷阱
|
缓存 前端开发 Java
是什么让一段20行代码的性能提升了10倍
性能优化显而易见的好处是能够节约机器资源。如果一个有2000台服务器的应用,整体性能提升了10%,理论上来说,就相当于节省了200台的机器。除了节省机器资源外,性能好的应用相对于性能差的应用,在应对流量突增时更不容易达到机器的性能瓶颈,在同样流量场景下进行机器扩容时,也只需要更少的机器,从而能够更快的完成扩容、应急操作。所以,性能好的应用相对于性能差的应用在稳定性方面也更胜一筹。
是什么让一段20行代码的性能提升了10倍
|
存储 前端开发 关系型数据库
浅谈DDD中的聚合
在我看来并不是MVC的基础上增加领域层,使用充血模型,解耦基础服务,我的代码就符合DDD了。
浅谈DDD中的聚合
|
存储 程序员 项目管理
六年团队Leader实战秘诀|程序员最重要的八种软技能
笔者在带团队的六年中发现,程序员们在职场都有一个共同的困扰:“好像写代码都没什么问题了,日常工作基本上都是应付业务需求的开发,好像找不到其他的更大的附加价值了,我应该找一些什么样的发力点才能让我的价值更突出呢?” 。本文将和大家聊聊程序员的软技能。
六年团队Leader实战秘诀|程序员最重要的八种软技能
|
弹性计算 运维 监控
稳定性与高可用保障的工作思路
稳定性与高可用性是老生常谈的两个词。凭借经验和感受我们知道,提高系统的这两项指标,系统会更加健康,产品也会有更好的用户体验。但是如果要给稳定性和高可用性下一个定义该如何表述?稳定性和高可用性这二者又有何区别和联系?我认为首先要理解好这两个问题,才能够设定清晰的目标,系统地制定完整可行的方案。
稳定性与高可用保障的工作思路
|
架构师 前端开发 流计算
阿里10年沉淀|那些技术实战中的架构设计方法
上周我写的一篇文章《关于技术能力的思考和总结》引起了大家的关注,好多读者的评论“以写代想、以想促真、以讲验真”,大家的感受很深刻,基于上次的文章,这篇文章我其实更想跟大家聊聊一些常用的思考方法,思考问题的方式对了,往往可以帮助大家少走弯路。
阿里10年沉淀|那些技术实战中的架构设计方法
|
架构师 C++ 开发者
团队管理|如何提高技术Leader的思考技巧?
技术Leader是一个对综合素质要求非常高的岗位,不仅要有解具体技术问题的架构能力,还要具备团队管理的能力,更需要引领方向带领团队/平台穿越迷茫进阶到下一个境界的能力。所以通常来说技术Leader的技能是虚实结合的居多,繁杂的工作偏多。为此我把自己在工作中经常用到的思考技巧也做了一个整理,算是对《关于技术能力的思考和总结》中提及第三阶段的补充。
1790 1144
团队管理|如何提高技术Leader的思考技巧?
|
JavaScript Serverless 定位技术
从业务开发中学习和理解架构设计
在设计代码目录划分方案的过程中,看了一些工程结构设计的资料,读了一些关于架构设计的书,对于架构有了一些理解。本文是对这段学习和任务完成过程的思考和沉淀。希望能够解答“架构到底是什么?架构和业务之间的关系?”,“好的架构的设计出发点是什么?好的架构应该是什么样的?”这几个问题。
从业务开发中学习和理解架构设计
|
运维 监控 容灾
安全生产-系统稳定性建设
安全是产品的底座,是体验的基础,也是企业的一项核心竞争力。安全生产是一项系统性的工作,同时也是一件比较琐碎的事,需要做方方面面的考虑尽一切可能保障系统安全稳定运行。
安全生产-系统稳定性建设
|
架构师 程序员 开发者
关于技术能力的思考和总结
要解释清楚什么是技术能力还得看透技术能力的本质,从源头上来做剖析。本文将挑选几个程序员日常的工作问题来做个剖析比对,从我们的日常感观中来辨识下哪些是有技术能力的做法,哪些是没啥技术能力的做法。
关于技术能力的思考和总结