本文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项目被验收时,项目团队除了要交付完成开发的数据应用模板,还需要交付项目过程中产生的一些资料,例如蓝图设计方案、系统测试文档、系统使用文档等。同时,验收并不意味着项目的结束,而是标志项目进入持续的运维支持阶段。项目团队需要对项目过程中的问题进行复盘和总结,并开始下一期项目的准备工作。
数据分析 BI
原创文章,作者:306829225,如若转载,请注明出处:https://blog.ytso.com/219196.html