进入项目开发与管理阶段，企业的目标就是对照项目规划和蓝图方案，开发出BI平台、系统或应用，并且以各种项目管理手段保障开发稳步、有序进行，从而减小风险，顺利结项。项目开发与管理的细节因企业而异，因此本文仅介绍几个常规要点，包括敏捷开发、项目风险管理、需求变更管理和项目验收管理。

　　1．敏捷开发

　　敏捷开发有优点也有缺点，优点在于灵活应对需求变化，快速交付，其缺点也很明显，即需要牺牲一定的技术稳定性和美观性。所以，企业在考虑开发模式的时候要想清楚，自身的需求是变化较快还是长期不变？如果是前者，则项目必须快速交付，如果是后者，则可以慢慢开发。例如，绩效类项目就更适合敏捷开发，因为这类项目的需求一般变化频率都很高，如果在一个考核周期内没有完成开发，下一个周期需求肯定会发生变更。企业领导临时提出的一些需求也是如此，由于是领导提出来的需求，IT部门一般会尽心尽力加班加点去实现，但最后开发出来的项目，领导可能用过几次就不用了。对于这种情况，如果采用敏捷开发，先满足领导的需求，等到后续项目功能被持续使用，再优化升级会更加高效。

　　这里讲一个真实的案例。江苏省某地市电信公司开发人力绩效BI项目，在项目初期的沟通阶段，人力部门按照轻重缓急向IT部门提了80多个需求点。由于整体的需求还比较清晰，从项目实施的角度，IT部门希望能够按照规划，从底层到中间层，再到前端呈现一步步来做。人力部门一开始也没有提出异议，但是在项目开发过程中就出现了问题。对于那些不重要的需求，可以长期考虑，慢慢构建表结构，抽取数据，再优化前端的呈现效果。但是对于比较紧急的需求，人力部门希望能尽快用上功能，所以并不管当初设置的完成日期，隔三岔五询问IT部门，让人非常头疼。更麻烦的是，人力部门等不及就用Excel等工具应急，自行解决需求。等到IT部门完成开发后，人力部门非常不满意，甚至其需求已经发生变化。这给IT人员造成了非常大的困扰。

　　后来，项目团队针对每个需求，除了设置完成日期外，又额外增加了一项初步完成时间，期望借用这个时间限制来刺激开发团队快速完成开发。同时，项目团队对人力部门的需求又做了一轮梳理，选择采用敏捷开发的方式，对底层不再考虑太多完备的范式之类的问题，重点是响应前端诉求。对一些数据采集、复杂考核表之类的需求都用FineReport实现，并且不纠结于样式，直接拿着Excel样表导入FineReport，免去制表烦恼。对于数据分析类需求，则直接采用FineBI，通过鼠标拖曳操作在浏览器端快速呈现分析结果。尽管牺牲了一定的技术稳定性和美观性，但最后实现的效果也很好。并不是所有的数据分析任务都要求BI系统24小时不宕机运行，在需求急迫的情况下，还是得采用敏捷开发。

　　2．项目风险管理

　　任何项目都存在不确定性，因此尽管有完美的规划做指导，但也不可不考虑不确定性带来的风险。对风险的管理以事前管理和事中管理为佳。做项目规划时准确预测风险，实施项目时有效管控风险，都能够最大限度地避开风险或减小损失，保障项目最终落地。就BI项目而言，风险一般存在于管理、需求、数据质量、原型、硬件环境等方面，如表1所示，表中也描述了相应的规避措施。

　　3．需求变更管理

　　项目需求与项目风险类似，前期做的需求分析再完善，受到众多不确定因素的影响，项目需求也很难保证一成不变，因此项目实施过程中经常会遇到需求突然变更的情况。既然需求的变更不可避免，应对的关键就在于对变更进行更有效的控制，若控制不当会对整个项目的进度、成本、质量等产生较大影响。需求变更管理同样要求项目团队事先做好规划，避免需求变更时没有完善的应对方案而影响项目整体的进度和质量。在发生需求变更时应及时做好管控。通常情况下，需求变更要经过变更申请、变更评估、决策、回复等4个步骤，若变更申请通过则需要增加实施变更和验证变更这两个步骤。

　　需要注意的是，变更需求时一定要先申请再评估。对于发生变更的需求，首先需要识别其是否在既定的项目范围之内。如果变更在项目范围之内，项目团队应评估变更所造成的影响，并将信息传达给受影响的各方人员，然后再根据影响程度决定是否变更。若确定变更，就制订相应的应对措施，解决变更的需求。如果变更在项目范围之外，项目团队就需要与用户进行沟通和谈判，讨论是否增加费用或放弃变更。

　　4．项目验收管理

　　项目验收的目的是保证项目质量，一般由各个需求方或项目领导委员会审核及验收项目。在BI项目被验收时，项目团队除了要交付完成开发的数据应用模板，还需要交付项目过程中产生的一些资料，例如蓝图设计方案、系统测试文档、系统使用文档等。同时，验收并不意味着项目的结束，而是标志项目进入持续的运维支持阶段。项目团队需要对项目过程中的问题进行复盘和总结，并开始下一期项目的准备工作。