如何正确的开发BI——浅谈BI项目管理

前言

在大部分的公司里，数据部门的产出主要都是提取数据和 数据可视化（BI）；提数工作无需多说，写好SQL即可。但BI则不同，即使在BAT等非常重视数据的公司中，它也是数据部门非常重要的产出；

而一个好的BI开发过程中，离不开良好的项目管理。

本文将会对 BI 的开发流程进行简单的介绍，并就其中可能遇到的问题进行探讨。

什么是BI？

在开始介绍前，笔者想先简单介绍下BI，以帮助大家对BI有一个基本的认识。

商业智能（Business Intelligence，简称：BI），又称商业智慧或商务智能，指用现代数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。

当然，读者也可以简单地讲BI理解为可快速实现的数据可视化图表，如下图。

img

项目流程

正如所有的项目流程一样，BI项目主要分为 3个部分：梳理需求，技术设计，实际开发。每个部分都有一个项目里程碑。

梳理需求：需求调研、需求确认。

项目里程碑：需求确认书
技术设计：CUBE设计、结果表设计、ETL设计、DEMO设计

项目里程碑：BI设计文档
实际开发：后端开发、前端UI调整、CUBE构建、数据源替换

项目里程碑：BI项目文档

详细过程如下

BI开发流程 (1).png

笔者会逐一进行介绍。

梳理需求

对需求的梳理，是所有项目开发的第一步，也是最重要的一步。为了避免开发完成后需求方表示“这根本不是我们要的东西”的惨剧。对需求的梳理一定要谨慎、完善。

需求调研

需求调研，即与需求方、相关干系人进行需求确认。从而保证双方对需求理解无误，及该需求是否可实现。

项目干系人

项目干系人是指与本次项目可能相关的人，不局限于产品、业务、研发。

在BI项目中，项目干系人大多如下。
- 需求发起者
- 项目管理者：即常说的PM
- BI实施：大多数情况1个就够
- 后台研发：提供数据的获取逻辑
- 相关业务方：需求发起者有时并非需求业务的负责人，于情于理都应该请该业务的实际负责业务参与。
- 高层：视必要程度
清晰的分析思路

需求发起方，大多只有模糊的分析思路。数据分析师需要协助业务人员理清逻辑。并制定涉及的指标、维度及展示图表。
数据的查询逻辑

需求调研中，需要研发确保数据有记录。并在后续向数据部门提供涉及到的库表和查询逻辑。

需求确认

在需求调研结束后，为了防止双方的理解误差。数据方必须出具需求确认书；

需求确认书应包含以下内容：

需求调研的时间、参与的人及角色。
指标、维度的定义（清晰明了不会引起歧义）。
底层数据的存储位置和查询逻辑。
需求变更流程（核心是增加需求就需要更长的开发时间）。

需求确认书大多以电子文档方式存储（如有必要也可以打印出来）。一定要获得所有干系人的确认再开始下一步的设计流程。

阶段里程碑

此阶段的项目里程碑为 需求确认书。主要起到3个作用

帮助业务梳理需求，理清思路。
确认数据的查询方式。
明确需求范围，避免无限制的需求拓展。

技术设计

在需求梳理后，就可以开始进行技术设计。

该步骤可以进行前后端并行设计；前端根据假数据开发DEMO，后端整理CUBE、底层表、ETL的逻辑。

DEMO设计

可以先根据假数据开发DEMO。以让需求提出方更快的看到成品。

后端设计

cube设计

cube是多维立方体，即从多个方面来分析对象。以订单为例：

timg.jpg

一维，如日期：年、季度
二维，如产品：不同品种、类型
三维，如地域：省份、城市等

合理的BI，应直接读取CUBE里的数据。这里需要保证CUBE的构建合理、膨胀率不能过大。
结果表设计

CUBE的构建，其实就是事实表和维度表的关联。

这里说的结果表、主要就是事实表的开发。需要制定其字段含义等信息
ETL设计

设计ETL时，要注意以下内容：
- 初始化的方式。
- 每个周期数据抽取的方式。
- 数据量是否过大。

阶段里程碑

该阶段的项目里程碑，就是TD文档。

一个好的设计文档应该有以下内容：

DEMO
CUBE设计：表关联关系的ER图
结果表设计：建表语句
ETL设计：ETL流程图

在设计文档完成后应进行技术评审，参与评审的技术人员、项目管理者应根据以上内容进行把关。

评审通过后再进行实际的开发

实际开发

开发的具体注意点基本都在设计部分处理掉了，但还有一些遗漏。

需注意点

BI的配色：每个好的BI开发者，都应有一套自己常用的配色方案（SUPERSET就算了）。
BI的查询速度：直接打开的速度、和不同图表间联动的速度都需要注意。
CUBE的膨胀率：设计阶段只能尽可能的减少膨胀率，只有接入实际数据后才知道具体。
结果表的数据量：避免过大
ETL的执行效率：应稳定在1h内。

阶段里程碑

在BI通过最终验收后，BI开发者/项目经理应腾出一些时间来，对过去的BI项目进行回顾整理。

BI项目文档应包括以下内容：

项目背景、预计开发时长、实际开发时长、实际结项日期等项目信息。
需求确认书 内容
TD设计文档 内容
需求变更记录
项目开发中遇到的各种问题等
其他内容

其他杂谈

很明显，本文的重心在于BI的开发流程，而非项目管理。实际项目中，还有其他要注意的部分。

项目排期

BI项目的项目预期，应在需求确认之后，由实际开发人员给出。并获得PM、需求确认方的认可。

个人建议给出的时间要是真实预计时间的2倍以上——你永远猜不到过程可能碰到什么幺蛾子、也永远猜不到底层数据有多离谱。

多人合作

在小型公司里，BI往往只能1个人开发。但在重视数据的公司里，一个BI往往需要多个开发人员的协力配合。如何分配工作给不同的开发人员，是对项目经理的一个考验。

软硬件环境

如果你并非在自家公司开发BI，而是以乙方的身份在甲方执行BI项目。则还需调研甲方的软硬件环境。这里也是要预留一部分时间。

BI测试

在大部分的公司里，BI需要经过QA部门的测试。如果没有的话实施人员需要自行简单测试。测试的核心是数据的准确性。

项目运维

如果BI的后续运维直接属于开发者的话可以绕过这一段。但在部分公司中，开发和运维属于不同的部门。实施人员将BI交接给运维人员时，也需要一些运维的文档——当然如果你的第三个项目文档写的很规范的话，可以节省很大的工作量。