9步教你玩转报表开发！

发表于 2019-9-25 20:15:50

马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据

您需要登录才可以下载或查看，没有帐号？立即注册

x

花两篇文章讲讲报表开发！报表开发是数据分析师的常见工作之一，也是业务监控必备工具之一。报表监控的指标通常都是业务相关的重要指标，做报表的过程也是深入了解业务的过程。
把数据分析分为“描述、解释、预测、控制”4个层级。那么报表开发就对应“描述”这一层级，也就是要做到准确、及时地监控业务数据。

描述、解释是最常见的工作内容有不少人反馈说自己做报表开发，流程比较混乱，经常对一张报表改来改去。提需求永远是明天要，有的还找领导加急。

这是一个非常典型的需求管理问题。实际上不止数据分析部门，所有的支撑部门，比如品牌推广、系统开发，都会遇到这个问题。业务方（市场部或者运营部）永远是：加急！加急！加急！你让他走流程，他想着办法的绕过流程。

但是，没有报表开发流程，这在业务庞杂的公司绝对是大问题，报表工程师会被坑埋死。那么一个完成的报表开发流程是怎样的呢？本文将梳理报表开发的主要流程及注意事项，流程仅供参考，我知道不同公司不同业务涉及的环节可能不一样。报表开发的主要流程

报表开发的主要流程1. 需求提交
报表需求发起人就是业务方(通常也称为“需求方”)，一般需求方是产品或者运营的同事。提交需求时，要提供的信息如下：

业务背景；
报表字段及统计口径；
关注数据周期，如当前年、当前月、近7天、近30天等；
报表发送频率，如月报、周报、日报、时报、实时等。

建议制作需求模板让需求方填写各项信息，主要用途有两个：

帮助需求方想清楚报表的背景和目的，同时过滤掉一部分不靠谱的需求；
规范填写的信息，以减少沟通成本。

2. 可行性评估提过来的需要评估，主要看3个问题：Q1：有没有必要做？

是否其他系统或报表上可以获得需求方要的数据？
报表的价值或者重要性大不大？
报表的使用频率是不是够高？如果只是偶尔一次，手动取数应该就可以了。

Q2：能不能做？

一方面要考虑技术上是否可以实现，比如有些报表要求实时展现，这就需要IT技术人员实现，分析师通常只提供统计口径；
另一方面要考虑权限、合规、安全上的问题，比如报表中是否涉及敏感字段，需求方是否有足够的权限获得这些数据。

Q3：是不是其他人做更合适？数据分析师会做一部分报表，但不是所有的报表都是由数据分析师来做。做报表的目的一方面是便于及时监控业务数据，另一方面，报表相当于“自动化”的数据处理任务，所以报表也能减轻分析师的工作量。如果是直接拉取明细数据，或者只是很简单的计数或者求和，那么是否生产库的技术人员应该可以直接做（一般生产库会对接到一个数据后台，不过功能一般比较粗糙）。
3. 建立需求评级机制，做好开发计划沟通为什么要对需求做排期：① 满足业务部门紧迫的功能需求
② 解决终端用户备受困扰的痛点问题③ 避免重复开发或无效开发的低效率
④ 控制整个产品功能规划的设计节奏在考虑报表需求的重要性、紧急程度的同时，需要对需求方进行预期管理，留够充足的时间。进入“需求排期”阶段就意味着需要登记相应的信息，比如报表编号、业务线归属、报表名称、需求方、需求提交日期、预计上线日期、开发负责人、当前进度等。其次，还要有需求评级机制。作为数据部门主管，必须掌握需求评级排队方法，这样才能白纸黑字的和业务部门交涉。作为数据部门的工作人员，必须具备需求评级意识，不能拿到需求单就下手，要按流程办事。如果积压的工作太多，及时找领导协调，不要干不完了才嗷嗷叫着自己可怜。第一：需求工作量评级。对需求评级具体到人天。比如一个数据专员一天完成2份需求，这一批需求的人天就是1/2=0.5人天。需求的人天评估是后续排版、沟通、开发资源通告的基础。没有量化的人天评估，就无法拿出合理的理由要求增加人手，延长工期。第二：需求排班机制。大部分业务部门领导，是不知道同时并行的需求有多少、都是谁的需求的。因此编辑需求排班表就非常必要。在提需求时，就直接展示需求排版计划，本周一共需完成20份需求，每份预计耗费X个人天时间，因此新需求预计在X号完成。在业务部门沟通需求的时候第一时间聊清楚这些，帮助业务部门正确评估工作量。第三：需求沟通机制。如果遇到需求撞车，特别是开头讲的有些需求都是老版特批加急的，就直接向上协调资源。毕竟干活的人就那么多，总人天资源就那么多，短时间内都是老板的需求，那就请老板协调看哪个先做哪个后做。数据部门的主管在这时一定要强硬。即使最后还是要加班才能解决问题，一定要让老板先知道：我们为了支撑这些需求加了X小时班。未来要增加支撑能力，要么花钱上更强大系统，要么花钱增加人力，否则总人力资源就这么多，是无法支撑的。这也是为什么同样是主管，有些人拼死拼活干最后还背黑锅，有些人轻轻松松部门越做越大的原因。没有骨气据理力争的，就让自己的钱包为软弱买单吧。第四：开发资源日常通告。以周或者月为单位，定期向业务部门公布可用开发资源数量。特别对于需求排队比较密集的时间段，提前预警。提示需求部门要么早点准备报表，要么做好需求排队的准备。最好定期对去年或上个季度的工作进行回顾，梳理哪些部门，哪些节点会临时产生大量需求。在公布开发资源的时候主动和业务部门沟通，了解业务部门计划，提前做出准备。4. 数据抽取

可以简单的把企业数据按用途分为3类库：生产库、分析库、报表库。

生产库，是生产数据直接存储的地方，非开发人员一般是不能直接访问的，生产库的数据通常称为“源数据”(也就是数据源头)；
分析库，就是将生产库的数据ETL处理后，放到一个地方集中供数据部门直接使用，数据分析师的日常工作通常依赖于这类库；
报表库，则是存放各业务线报表数据的数据库，通常报表库会对接到各数据产品(比如报表系统、数据展板、自助分析平台等)。

数据抽取，也就是将数据从生产库抽取到分析库。一般业务发展成熟时，报表开发所需要的大部分源数据表都已经抽取过，所以该步骤不一定需要执行。如果是某个业务刚上线或者报表需要用到的表没有被抽取，那么就可能需要执行该步骤：

联系业务线的负责人以确认源数据的技术接口人；
然后技术接口人提供库名、表名(英文及中文)、建表代码等源表信息；
接下来，将源表信息传递给数据ETL的同事进行数据抽取。

5. 代码编写这里的代码主要指SQL，也就是用SQL取数据表写SQL最重要的是统计口径要准确，其次：① 取数代码要有必要的注释、版本信息，注意对齐和命名规范；② 做好文档管理，便于后期的报表维护以及统计口径整合，建议：

代码放到企业网盘备份或者托管到企业内部的git平台；
记录好报表的相关信息，比如报表名称、负责人、代码、数据字典等。

③ 建中间表，如果有需要，那就建立中间表，将常用字段整合到一张表，以便于统计分析和口径维护。常见的中间表有3类：用户宽表、订单宽表、维表。
6. 数据验证数据验证主要是核对数据是否准确、完整。一般的方式如下：

自检代码逻辑，字段相互验证；
和其他系统的数据比对验证，比如生产库的数据；
由测试人员进行验证；

数据验证阶段，发现的问题通常在3个地方：

统计逻辑，例如隐藏前提，交叉标签等；
数据抽取，例如数据增量抽取时依赖update_time字段，而该字段在生产库没有同步更新，这种情况下要么改抽取方式为“全量抽取”，要么生产库的字段更新逻辑要进行调整；
生产库改动，例如生产库的业务逻辑改动(业务分流)，或者先前的表的字段已被弃用(不再更新)；

如果数据核对不上，则建议按上述的顺序一一排查。7. 前端展示这个步骤就涉及最终报表的交付形式了，报表的交付形式是在“可行性评估”这个环节确定的。按报表展示的载体可以大致分为3类：

自动定时邮件；
网页展示、PC端展示或者是移动端；
独立应用，比如移动端app；

该环节需要使用到呈现数据的工具(不一定可视化工具，大多数情况还是会用表格展示)，这些工具可以是企业内部开发的数据工具(平台)，也可以是购买的FineReport这种成熟的报表软件。但工具不是最重要的，更重要的是呈现的数据能突出重点、准确反映问题。比如下面的这张dashboard，理想的数据展示应该是选用了恰当的展示方式，按业务逻辑、有层级地组织了数据，并讲述了一个完整的故事。

8. 报表验收在正式上线之前要先对报表进行“自测”，比如：

邮件是否能正常定时发送；
图表是否能正常显示，是否有添加必要的说明提示（如统计口径等）；
显示的数据格式是否OK（如小数点后位数，单位，坐标轴范围等）；
需求方需要用到的功能是否正常（如筛选、交互等）；

完成上述工作后，就可以交由需求方验收了，后续可能需要根据需求方提出的建议做适当的调整，当需求方确认OK时就准备上线。9. 报表上线报表验收通过，接下来就是正式上线。如果是自动邮件，则要确认发送的频率、收件人等信息，邮件中最好有相应的计算口径说明如果是网页或者在独立应用中展示，通常需要申请权限，那么报表上线后需要告知业务费报表申请路径(走OA或者发邮件)、报表名称等信息。以上，就是报表开发的主要步骤，涉及到的技术的东西比较少，主要是流程以及信息的沟通，希望对大家有用，欢迎留言交流。作者：启方
来源：数据分析不是个事儿

帐号		自动登录	找回密码
密码			立即注册

9步教你玩转报表开发！

马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据

站长推荐 /1