想到哪，写到哪；

数据开发作为独立流程的开发流程

一、需求提出阶段

解释：产品经理提出的新业务需求

参与人：产品经理、数据分析师

负责人：产品经理

要求：

1.产品经理（数据分析师）一起给出评估产品功能效果的数据指标，及预期的指标数值范围

2.数据产品保证约定口径是可行的，并且确认现有上游数据的可用性

3.说明数据重要等级，使用人群

产出：预期收益；在wiki上的功能需求文档，必须包含业务验证阶段的埋点/数据需求；

二、技术评审

解释：产品需求进行技术评审阶段/技术发起项目进入技术评审

参与人：服务开发、app开发、数据开发，数据产品经理

负责人：服务开发/

要求：

1.数据可读性：要考虑数据应用范围，防止歧义，包括字段命名等

2.变化透明性：禁止改变现有数据（字面）的业务意义

数据服务可靠性：

1.数据监控方案评审需通过（数据组提供）

2.可执行性&简洁性：数据收集尽可能自动化，不需要人工介入

可维护性：

1.明确新添加/修改数据的意义（与业务设计的对应关系）

2.明确数据在存储/服务中的物理位置，可扩容

3.每个环节出错，都可重试或重做流程

4.明确此服务后续的负责人

5. 文档可用性：此文档要随着后续功能改进保持更新

工具支持：

元数据系统：通过查询历史关键字，进行程序变量命名，表命名的一致性；在元数据系统登记日志，表的具体实现级别意义；

产出：资源消耗（人力，机器）；元数据系统内容；

 

这个阶段需求有可能因为投入产品比等因素被打回；

三、数据开发

参与人：服务具体开发、数据组开发

负责人：数据组开发

要求：

1.针对每个数据流，都需要有数据流监控。监控纬度

a)数据流量是否正常（必须）

b)某些字段是否正常（可选）

2.数据任务，都需要有监控。监控纬度：

a)任务是否失败

b)数据是否有堆积（实时处理）

c)重复执行较大/流程长任务流，中间流程数据要监控，减少修复代价

3.各种监控发现问题要能方便排查问题原因及尽方便修复

产出：产品需求文档（链接即可）+技术详细设计文档+数据流说明文档

四、验收上线

参与人：数据组开发、需求提出方

负责人：数组组开发

要求：

1.需求提供方对数据组产出数据进行正确性验收，需要跨天（产品+研发）

2.对例行产出数据（业务指标）进行监控验收

产出：产品复盘邮件（必须附上：产品需求文档（链接即可）+技术详细设计文档+数据流说明文档）

 

在观察一段时间（可以是一两周）后，进行开发阶段产品复盘；

回顾开发中碰到问题，后续如何避免；上线后表现十分符合预期；项目是否成功

五、数据下线

参与人：数据组开发、需求提出方

负责人：数组组开发

要求：

1.数据组需要对 数据访问/业务依赖 进行 记录/登记

2.当业务下线/数据访问量很小时，进行数据下线申请

产出：数据下线邮件（附上产品复盘邮件）

回滚整个功能周期内总体收益，总体消耗，为后续迭代提供经验

 

六、 考核标准

对产品经理的考核标准：

每季度花费的总的成本，产出的效果，经过简单叠加即可；

开发人员：参与项目的叠加