DI团队需求处理流程图
2017-03-30 18:07:49 0 举报处理流程图是一种图形化工具，用于描述DI团队的需求处理过程。它通常包括以下几个步骤： 1. 需求收集：团队成员与客户沟通，了解客户的需求和期望。 2. 需求分析：团队对收集到的需求进行详细的分析和评估，确定需求的优先级和可行性。 3. 需求确认：与客户确认需求，确保双方对需求的理解一致。 4. 需求实现：根据确认的需求，团队开始设计和开发相应的解决方案。 5. 需求测试：完成开发后，团队对解决方案进行测试，确保其满足客户的需求。 6. 需求交付：将解决方案交付给客户，并进行验收。
作者其他创作
大纲/内容
正式上线
埋点开发，研发同学开发过程有什么问题，可随时反馈给分析师，埋点必须先上报到“测试”项目
rpt_ies_push_xx 系列hive表，负责人：傅潇
tableau报表
\b使用时长
任务流
核心数据生产
渠道数据
app log
核心埋点设计
\b新增
埋点评审：数据分析师评审是否符合埋点规范以及权限敏感性
ies_dw.stg_user_device_new_activation_day新增表
测试
看板：按需制作看板（有需要协助的提给数分，排期处理）
需求方整理需求文档，重点说明需求目的，结合业务来看，产出数据需求文档 （流程固化之后，这里可以产出模板，由分析师和产品一起完善）
埋点管理文档
研发(RD)
ies_dw.mds_bhv_didfirst_launch_day当天日活设备-首次吊起数据
核心指标列表
分析师依照数据埋点规范，产出版本埋点需求，提供给研发
其他
ies_dw.stg_dim_pushtype_info_allpush_type和gd_label映射关系
测试同学和分析师交叉测试，测试的关键点：新增的埋点事件是否有上报？新增的事件属性是否上报？新增事件属性的类型和取值是否正常？ （不确定这里是否要给测试报告，待定）
分析师评估，深入理解沟通业务需求，转换成数据/埋点需求，产出版本埋点需求，提供给研发和测试同学
需求处理完成后回复邮件，需求状态的更新没有强制的时间要求，但是要记得处理
ies_dw.mds_bhv_did_mulpush_day设备和push多维交叉行为日表
关系数据
投稿表
埋点测试校验
流程
default.dim_device_model 机型获取品牌
设备数据
\b中间层
\b产品(PM)
核心报表数据
分析师制作数据看板，check线上数据是否有异常，如有及时反馈给产品和研发，商量修复方案。如无异常，生产计算指标
\b核心角色
日活
数数埋点规范文档 （数据组提供）
\b输出
处理需求的同学则负责管理自己的看板，并全权负责数据的排期。需要强调的一点是排期已经要合理评估。
ies_dw.stg_user_device_dlu_day日活表
埋点需求：需求方提埋点需求
\b关系表
测试(QA)
埋点上报到“新冲鸭”项目，分析师制作数据看板，期间有数据问题即时反馈给产品和研发
\b和公司高层确定权限分配对象以及将生产出来的数据呈现，主要有以下三种呈现1）数数(TA) 看板2）BI 报表3）自动化推送
\b用户表
投稿数据
埋点设计：产品对接人依照数据组提供的埋点规范按需设计埋点
\b埋点验收：产品提给研发开发之后，验收埋点
开发
\b非核心埋点需求流程
double check（产品同学需要通过业务判断来评估数据准确性），无误之后开放看板权限分享
管理员将需求复制到对应处理同学命名的看板中的TO-DO中
埋点上报到“业务对应”项目，分析师制作数据看板，期间有数据问题即时反馈给产品和研发
growth.m_device_distinct_fully全量设备表
default.ttpush_merge_log_dailypush merge表
\bserver impr
分析师(DA)
指标管理文档（计算逻辑）
分析师通过对业务认知，整理出核心指标尤其需要考虑公司管理层+产品宏观+项目这三个层面关注的指标
\b需求交付
需求方发邮件
\b视频消费数据
\b埋点开发
测试同学和分析师交叉测试，测试的关键点：新增的埋点事件是否有上报？新增的事件属性是否上报？新增事件属性的类型和取值是否正常？
权限+呈现形式
提出需求
PM有可视化样式需求，在这里提出来
需求管理员在DI公共需求池中分配需求（负责人：戴欢/万里）
埋点上线
\b报表管理（内容+权限管理）
评估需求
\b指标管理文档（指标解释）
非核心这块的数据参考性对需求方有效就行，数据组不需要这里埋点准确性和报表可靠性负责
api log
收藏
0 条评论
下一页
