花两篇文章讲讲报表开发！

报表开发是数据分析师的常见工作之一，也是业务监控必备工具之一。报表监控的指标通常都是业务相关的重要指标，做报表的过程也是深入了解业务的过程。

把数据分析分为“描述、解释、预测、控制”4个层级。那么报表开发就对应“描述”这一层级，也就是要做到准确、及时地监控业务数据。

描述、解释是最常见的工作内容

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

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

但是，没有报表开发流程，这在业务庞杂的公司绝对是大问题，报表工程师会被坑埋死。

那么一个完成的报表开发流程是怎样的呢？本文将梳理报表开发的主要流程及注意事项，流程仅供参考，我知道不同公司不同业务涉及的环节可能不一样。

报表开发的主要流程

报表开发的主要流程

1. 需求提交

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

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

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

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

2. 可行性评估

提过来的需要评估，主要看3个问题：

Q1：有没有必要做？

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

Q2：能不能做？

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

Q3：是不是其他人做更合适？

数据分析师会做一部分报表，但不是所有的报表都是由数据分析师来做。做报表的目的一方面是便于及时监控业务数据，另一方面，报表相当于“自动化”的数据处理任务，所以报表也能减轻分析师的工作量。

如果是直接拉取明细数据，或者只是很简单的计数或者求和，那么是否生产库的技术人员应该可以直接做（一般生产库会对接到一个数据后台，不过功能一般比较粗糙）。

3. 建立需求评级机制，做好开发计划沟通

为什么要对需求做排期：

① 满足业务部门紧迫的功能需求

② 解决终端用户备受困扰的痛点问题

③ 避免重复开发或无效开发的低效率

④ 控制整个产品功能规划的设计节奏

在考虑报表需求的重要性、紧急程度的同时，需要对需求方进行预期管理，留够充足的时间。进入“需求排期”阶段就意味着需要登记相应的信息，比如报表编号、业务线归属、报表名称、需求方、需求提交日期、预计上线日期、开发负责人、当前进度等。

{!– PGC_COLUMN –}

其次，还要有需求评级机制。作为数据部门主管，必须掌握需求评级排队方法，这样才能白纸黑字的和业务部门交涉。作为数据部门的工作人员，必须具备需求评级意识，不能拿到需求单就下手，要按流程办事。如果积压的工作太多，及时找领导协调，不要干不完了才嗷嗷叫着自己可怜。

第一：需求工作量评级。对需求评级具体到人天。比如一个数据专员一天完成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或者发邮件)、报表名称等信息。

以上，就是报表开发的主要步骤，涉及到的技术的东西比较少，主要是流程以及信息的沟通，希望对大家有用，欢迎留言交流。