如何进行BI项目开发与管理？
本文2800字，读完需要6分钟。
进入项目开发与管理阶段，企业的目标就是对照项目规划和蓝图方案，开发出BI平台、系统或应用，并且以各种项目管理手段保障开发稳步、有序进行，从而减小风险，顺利结项。项目开发与管理的细节因企业而异，因此本文仅介绍几个常规要点，包括敏捷开发、项目风险管理、需求变更管理和项目验收管理。
1、敏捷开发
敏捷开发有优点也有缺点，优点在于灵活应对需求变化，快速交付，其缺点也很明显，即需要牺牲一定的技术稳定性和美观性。所以，企业在考虑开发模式的时候要想清楚，自身的需求是变化较快还是长期不变？如果是前者，则项目必须快速交付，如果是后者，则可以慢慢开发。
例如，绩效类项目就更适合敏捷开发，因为这类项目的需求一般变化频率都很高，如果在一个考核周期内没有完成开发，下一个周期需求肯定会发生变更。企业领导临时提出的一些需求也是如此，由于是领导提出来的需求，IT部门一般会尽心尽力加班加点去实现，但最后开发出来的项目，领导可能用过几次就不用了。对于这种情况，如果采用敏捷开发，先满足领导的需求，等到后续项目功能被持续使用，再优化升级会更加高效。
这里讲一个真实的案例。江苏省某公司开发人力绩效BI项目，在项目初期的沟通阶段，人力部门按照轻重缓急向IT部门提了80多个需求点。由于整体的需求还比较清晰，从项目实施的角度，IT部门希望能够按照规划，从底层到中间层，再到前端呈现一步步来做。
人力部门一开始也没有提出异议，但是在项目开发过程中就出现了问题。对于那些不重要的需求，可以长期考虑，慢慢构建表结构，抽取数据，再优化前端的呈现效果。但是对于比较紧急的需求，人力部门希望能尽快用上功能，所以并不管当初设置的完成日期，隔三岔五询问IT部门，让人非常头疼。更麻烦的是，人力部门等不及就用Excel等工具应急，自行解决需求。等到IT部门完成开发后，人力部门非常不满意，甚至其需求已经发生变化。这给IT人员造成了非常大的困扰。
后来，项目团队针对每个需求，除了设置完成日期外，又额外增加了一项初步完成时间，期望借用这个时间限制来刺激开发团队快速完成开发。同时，项目团队对人力部门的需求又做了一轮梳理，选择采用敏捷开发的方式，对底层不再考虑太多完备的范式之类的问题，重点是响应前端诉求。对一些数据采集、复杂考核表之类的需求都用FineReport实现，并且不纠结于样式，直接拿着Excel样表FineReport，免去制表烦恼。
对于数据分析类需求，则直接采用FineBI，通过鼠标拖曳操作在浏览器端快速呈现分析结果。尽管牺牲了一定的技术稳定性和美观性，但最后实现的效果也很好。并不是所有的数据分析任务都要求BI系统24小时不宕机运行，在需求急迫的情况下，还是得采用敏捷开发。
2、项目风险管理
任何项目都存在不确定性，因此尽管有完美的规划做指导，但也不可不考虑不确定性带来的风险。对风险的管理以事前管理和事中管理为佳。做项目规划时准确预测风险，实施项目时有效管控风险，都能够最大限度地避开风险或减小损失，保障项目最终落地。就BI项目而言，风险一般存在于管理、需求、数据质量、原型、硬件环境等方面，如表1所示，表中也描述了相应的规避措施。
表1 BI项目风险及规避措施
| 类 别 | 风 险 | 规避措施 |
| 管理风险 | 项目中XX方组织松散，缺乏有效的协调和沟通，导致项目工作效率低下 | 需要公司领导密切关注，发挥强大推动作用，提高执行力，促进交流，提高效率 |
| 目标偏差：各级人员对项目目标的理解不一致，存在潜在第二目标 | 通过培训、交谈等方式进行互动，在对目标的理解一致后进行下一步行动 | |
| 业务人员不配合：业务人员工作繁忙，无法投入足够精力参与项目 | 项目实施期间，通过制度保证业务人员投入BI项目的时间 | |
| 需求风险 | 项目业务分析主题不明确，可能造成项目实施宽度和深度不确定 | ① 对各部门加强培训，组织内部讨论，协调资源，组建需求挖掘小组② 协调顾问，对业务进行梳理和引导 |
| 目标偏差：各级人员对项目目标理解不一致，存在潜在第二目标 | 通过培训、交谈等方式进行互动，在对目标的理解一致后进行下一步行动 | |
| 数据质量 | 数据来源：多数据源不一致、潜在的数据录入错误 | 加深对业务系统的理解，发现数据质量问题，提出合理的解决方案 |
| 类 别 | 风 险 | 规避措施 |
| 数据缺失：系统需要的数据无法获取或需要补录 | 通过完善业务系统、二次开发补录系统、直接补录等方式解决 | |
| 信息缺失：各业务系统管理软件的厂商无法提供数据源字典和技术上的支持 | 尽量获取技术支持，如果由于特殊原因无法获取支持，可以由熟悉业务系统的IT人员和实施小组共同解决 | |
| 控制失效：数据质量控制失效，业务系统负载过重，失去对脏数据来源的跟踪 | 设立业务系统隔离区，生成数据抽取批次日志，设立时间窗口，采取数据分区控制 | |
| 原型风险 | 原型设计：对业务理解不足，验收模型的基础维度和指标设计偏离正确方向 | 通过培训加强双方对业务的理解，以及对维度模型设计方法的理解 |
| 原型验证：过于关注报表样式而忽略业务含义，忽视对多维模型结构的验证 | 明确验证任务，划定讨论范围，讲解模型逻辑 | |
| 硬件环境 | 目前机房、网络及服务器的实际情况不是很理想 | 在当前条件下，优化机房资源和网络，努力保证服务器性能 |
3、需求变更管理
项目需求与项目风险类似，前期做的需求分析再完善，受到众多不确定因素的影响，项目需求也很难保证一成不变，因此项目实施过程中经常会遇到需求突然变更的情况。既然需求的变更不可避免，应对的关键就在于对变更进行更有效的控制，若控制不当会对整个项目的进度、成本、质量等产生较大影响。
需求变更管理同样要求项目团队事先做好规划，避免需求变更时没有完善的应对方案而影响项目整体的进度和质量。在发生需求变更时应及时做好管控。通常情况下，需求变更要经过变更申请、变更评估、决策、回复等4个步骤，若变更申请通过则需要增加实施变更和验证变更这两个步骤。
需要注意的是，变更需求时一定要先申请再评估。对于发生变更的需求，首先需要识别其是否在既定的项目范围之内。如果变更在项目范围之内，项目团队应评估变更所造成的影响，并将信息传达给受影响的各方人员，然后再根据影响程度决定是否变更。若确定变更，就制订相应的应对措施，解决变更的需求。如果变更在项目范围之外，项目团队就需要与用户进行沟通和谈判，讨论是否增加费用或放弃变更。
4、项目验收管理
项目验收的目的是保证项目质量，一般由各个需求方或项目领导委员会审核及验收项目。在BI项目被验收时，项目团队除了要交付完成开发的数据应用模板，还需要交付项目过程中产生的一些资料，例如蓝图设计方案、系统测试文档、系统使用文档等。同时，验收并不意味着项目的结束，而是标志项目进入持续的运维支持阶段。项目团队需要对项目过程中的问题进行复盘和总结，并开始下一期项目的准备工作。
立即沟通
