1.1.4 数据交付

数据交付包含数据分析师按照分析方案得到的数据表格、可视化图表、分析结论等，有时还包含分析业务背景和分析过程的数据分析报告。总的来说，交付物往往存在交付不完整、交付形式不能满足需求、不能周期性交付等问题。

1）交付不完整。数据分析师与业务方反复确认的过程会涉及多次数据发送，最终确定一个交付稿。实践中，很多数据分析师会使用企业内部的即时通信工具交付过程稿，而以邮件形式发送最终的交付稿。这样，其他分析思路和结果并没有体现，不容易探究最终方案的形成原因，也无法将这些分析思路沉淀下来。

案例：数据分析师小A负责对某业务的用户留存率下降原因进行分析。在向运营人员了解了近期的运营动作后，他制定了一个数据分析方案。在分析过程中，他又与运营人员讨论了其他几个分析方案并实施，最终选择了一个大家比较认可的方案作为最终交付。但业务方按交付结论对业务采用运营手段进行干预后发现效果不佳。此时运营人员想到之前在做数据分析时得出过更符合当前结果的结论，但由于没有规范的过程文档管理，此方案的文档未保留，无据可查。

2）交付形式不能满足需求。业务方对于交付形式也有一定的需求，比如需要进行一定的可视化，需要定期收取，需要存在变量的数据（如每天收到前一天的数据），数据可分发给其他同事，等等。多样的交付形式可以大大提升数据的使用效率，但并不是总能得到很好的支持。

案例：A公司新上线了一项业务，在上线前确定了此业务的几个核心指标，并要求了解这些指标每小时的变化。数据分析师已经完成了SQL脚本的编写，但由于公司没有对自动化数据交付功能的系统支持，他只能每小时运行SQL脚本并将数据发送给业务方。

3）不能周期性交付。对于一些非高频数据，用户希望仅在需要的时候主动获取；对于一些周期数据，希望可以订阅、取消收取等。但很多系统并不能很好地支持这些功能。

案例：A公司开发了一个社交App，每次发版后都需要了解Android和iOS系统的更新比例。运营人员无法自主获取此数据，需要找数据分析师通过数据查询获取。