分析师视角下的新业务数据项目流程

此文基于某金融市场运营部门实践，将在发现市场机会时，报审，协调资源，IT开发协助的大致过程，总结如下：

1) Initial - 业务方，识别机会，写proposal， 找fund

	除了找业务部门要钱之外，会找market，找外部合作商例如Master card拿钱。
	部门内预算充足另说，不充足时，会优先考虑计划内的重点项目，新的项目去其他地方找钱比较容易通过

2) 业务方报审汇报项目，拿approval，业务方协调IT资源，

	确定所需要的资源，预算，以及各system的ready时间，以便做单独test， regression test
	这里需要一个IT的project manager来推动，IT内部对于系统IT/数据IT比较了解，分析师跟业务会接触多点， IT project manager 或者叫 scrum master 对整个项目的 IT 部分，负责分解/跟进以及同步。

3) 业务基于proposal，确定 BRD业务需求文档

	关键目标key objective确定需要监测的指标 KPI， 过程中的各项转化率（maybe），跟业务方确定一个 Business requirement document （ BRD业务需求文档，这个对于MI简单，但对于product会比较复杂）
	
	a. 用户角度，customer engagement， 用户的参与量，新客导入量。 沉睡客户激活量
	b. 活动角度，参与度，次数，点击 
	c. 消费，总体消费，eligible 消费，
	d. 分析拆分， 用户维度-(关心的 一些客群，rev/spd， persona，NTB/ETB，age，gendar，bank seg）
			卡片维度-（卡种，MKT-CODE进来的，P/S， open month )
	e. 利润/收入

4） 分析师对BRD进行review，对BRD定义进行明确使其能转化为 data 衡量的问题

	这里确定需求字段时，其实有求快MVP跟求全的balance，但实际中可适当的多加一些 变量进来，根据经验确定一些潜在的最有可能的分析字段，考虑IT一批可以做的最大容量以及存储资源。
	
	因此一般在review时，会同时协调 IT 进组，了解其工作模式跟时间节点。这里一般会有几轮协商。对于新技术/新平台，还存在一个学习探索期，存在一些技术不确定性，可能导致延期或其他问题

	业务一般都比较清楚自己想要看的重点，分析师交流的重点在确定定义，问题，以及拒绝掉不合理/无可能的/数据上非常不好处理但又非必须的指标，以及了解进一步潜在的分析需求。

5) 确定BRD后， 转化为DR-Data requirement后，跟IT 进行协调，确定系统抓取数据字段，以及优先级

note：
	(这个花非常多时间）- 主要在于系统IT团队跟数据IT团队不是一方，本身raw数据到数据库进行了一次转化，并非原始数据了。
	另外系统IT 到数据库的存在更新形式（依据键值一直保存更新？），数据保存时间，替换或更新？“字段的possible value是否于现存的逻辑一样）
	
	能力点：对一项业务涉及到的几个table
	
	（case ：IT 提供了8个基础表，跟其他10多个表。D&A 根据BRD的字典，与IT一起确定data feasibility，过程中，需要多次跟Business开会，clarify 字段定义/范围/业务）

6）对于digital 类业务，可能涉及埋点涉及，跟数据集Test验证的过程

7）核心 的数据需求文档 Data Foundation Documents

两种方式： 1）IT有基础，提供给D&A这边 全部能提供的数- Data Ingestion Sheet (DIS)， 分析师对表进行筛选确定一个list - Source to Target Mapping (STM)。能提供的提供，不能提供的，往上游IT提需求- Data Requestor Sheet (DRS)
			Day 1 requirement-可及时提供的daily master
			Day 2 requirement-滞后的 IBB，利润
		 2） 无IT基础的，从0开建，这种没做过，这就需要考虑埋点，确定所有table的架构，比较难
			一般也不是完完全全从0，参考其他的类似业务，基本上结合一些特性，确定
			
		分析一些这8个大表

8） UAT模拟测试，

跑通各项数据包的数据管道是否通顺，提取逻辑是否正确，能否满足day 1/2的DRS
数据完整性：（时间，覆盖业务范围，保存时间，更新）
	数据库的存在更新形式（依据键值一直保存更新？），数据保存时间，替换或更新？“字段的possible value是否于现存的逻辑一样
数据一致性：1）变化时，怎么处理？ 
			（case 1： 以及inactive/demised的客户，继续保存多长时间 -不定 ）
			  （case 2： activated date 只保存3个月 ）
		  2） 是否跟业务场景一致，找案例进行story解释
			（case 1： 出现了 大量physical activated =2024，token activated = 1900）
		3）与现有数据表有关联的部分，是否存在一致的行为。
			（case ： Deal code 与现有的不匹配）
			case： 测试中出现的数据没法在production环境中模拟出来
		
数据质量：1）字典与实际的数据是否匹配  （HCC 给出的字典与实际test的不一致，
		2）缺失率，有效值valid检查, （实际中出现了 单双引号的问题）

9）整个 PROD 的回归测试，系统用真实数据测试

进一步确定逻辑