如何正确的开发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交接给运维人员时，也需要一些运维的文档——当然如果你的第三个项目文档写的很规范的话，可以节省很大的工作量。
