供电所平台软件项目需求管理优化
陈旭
郑州大学 管理学院 工程管理专业 河南郑州 450001
0 引言
随着电动汽车、充电桩等新能源技术的快速发展与应用,供电服务面临更高的要求,供电企业管理向精细化、智能化转变,作为供电服务体系的最前端单元,供电所对可视化、智能化、数字化系统平台需求日益提升,数字化转型业务推进愈加频繁。然而在软件开发过程中,由于对软件系统知识的缺乏,尤其是在需求制定过程中,需求制定方法不够科学,容易仅单一参考管理层人员的管控要求,未充分考虑基层员工的实际需求,造成系统上线后与基层实际应用脱节,项目成效无法达到预期效果。因此本文通过具体实例探讨供电所软件需求管理的优化方法,以期为同类型系统需求制定及功能开发提供理论参考。
1 需求管理相关理论
1.1 软件项目需求管理定义
按照 PMI( 项目管理协会,Project Management Institute) 对于产品需求的定义,需求是指产品所必须拥有的一项功能特性,这个特性一般用于解决客户的特定问题,或者是给客户带来额外的价值 [1]。而软件项目需求管理是指为了实现线上化系统功能,而进行的业务场景的描述说明和确认的过程,在实际项目执行过程中,往往存在因未能准确确认需求、需求收集不全、需求频繁变更等问题,容易导致系统上线后功能应用率不高的情况,有资料表明,软件项目中 40% ~ 60% 的问题都是在需求制定阶段埋下的隐患[2],因此需求管理对于系统能否成功交付及其重要。
1.2 需求分类
需求一般分为业务需求、用户需求、功能需求、非功能需求[3]。业务需求是指项目方或者业务管理方建设系统之初提出的对项目的整体规划,用户需求是目标用户应用系统能够实现的业务使用场景,功能需求是指系统开发人员需要实现的页面、流程、指标等具体的功能项,非功能需求是指系统的安全性、兼容性、响应速度等等保障系统正常运行的要求。
1.3 需求优先级理论
为确保项目资源的最大化利用,需求的优先级评估尤为重要,一般对于需要对于重大的、紧迫的、基础的、独立的需求优先上线,其余的内容可在后期考虑实现。优先级的评估不能靠项目管理方主观判断,需要科学的判断方法,常见的需求优先级评估方法有 MoSCoW 法则、kano 模型等 [4]。
1)MoSCoW 法则:将需求分为四类进行评估,Must Have:核心功能或特性,保障项目的基本运行;Should Have:有价值但非必需的功能,可用其他方式实现;Could Have:可提升体验但非必要的功能;Won'tHave:目前不考虑实现的功能。
2)Kano 模型:Kano 模型是从用户角度出发考虑,将需求分为五类进行评估,必备型需求(Must-be):用户认为产品“必须有”的功能期望型需求(One-dimensional):用户明确表达的需求,其满足程度与用户满意度呈线性正相关。魅力型需求(Attractive):超出用户预期的功能,不提供时用户无感,但提供后会带来惊喜并大幅提升满意度。无差异型需求(Indifferent):无论是否提供,均不影响用户满意度。反向型需求(Reverse):提供后反而降低用户满意度。
1.4 需求流程
需求流程主要包括需求收集、需求分析、需求规格说明书编制、需求验证与确认等阶段[2]。
1)需求收集
需求收集是对软件项目的相关人收集需求的过程,作为需求流程的第一步,需求收集需和软件项目所有相关干系人进行充分沟通 [5],同时为了项目的长远性及先进性考虑,还要对本行业发展趋势以及竞品进行调研,为需求的确认提供参考,需求收集一般采用线上会议、问卷调查、竞品调研、行业分析等多种方式。
2) 需求分析
需求分析是对在收集需求基础上进行整理归类,由于各方所站的视角和立场不同,提出的需求内容往往存在一定的差异性,乃至存在互相矛盾的情况。同时,新的系统如何建设可能存在描述模糊不清的情况,对于开发人员来说,这些原始的需求无法直接转换为开发程序,在需求收集后,需要对收集的需求进一步分析,对于无效的需求予以剔除,对于不够模糊的需求予以细化,对于同类的需求予以合并等。
3) 需求规格说明书编制
编制《软件需求规格说明书》作为需求分析的成果物,国家标准GB/T8567《计算机软件文档编制规范》明确了需求规格说明书编制的模板可供项目管理者参考 , 规格书中需要明确项目的应用对象、业务项描述、功能需求描述、非功能需求描述等。在实际工作中,系统迭代优化过程较为灵活,因此上线一些临时性的功能时,需求规格说明书文档一般简化为需求单。
4) 需求确认
软件需求规格说明书编制后,组织对需求进行评审确认,项目管理方应组织专家、业务方、用户等达成一致意见,一个完整的需求具备一致性、全面性特征,为保障程序合规,在组织需求评审的过程中,最终的需求内容需要相关干系方签字确认。
2. 案例分析
2.1 供电所软件平台
供电所前端服务作平台是将供电所日常使用的营销系统、用电采集等业务信息系统整合,实现了多部门数据归集和联通共享。主要实现三大特色:一是“千人千面”营配融合监控看板,汇聚供电所营销、配网业务数据和运营指标,满足“千人千面”差异化管理需求;二是供电所标准化晨会一张图,供电所员工在每日班组会中,自动获取今日考勤,会议中通过派发自主工单安排今日工作,会后自动生成晨会报告;三是异常自动分析预警,汇集采集失败、停复电失败等 7 项供电所日常待消缺事项,自动分析、预警异常,实现异常问题线上全过程闭环管控。
2.2 当前需求管理存在问题
1)需求收集不全面
供电所平台在项目需求收集时,仅考虑专业管理方意见,未对基层供电所员工进行详细的需求收集,需求收集的对象和方式较为片面,例如基层实际需要查看具体数据明细并且能够支持导出和排序,但在需求制定之初未能充分考虑此类实际需求。
2. 需求描述不清楚
业务方提出产品需求不够清晰,例如某项指标数据展示,业务方仅提出展示指标的规则,未明确更新的频次,由于项目人员不具备足够的业务知识,对业务方提出的内容进行机械化执行,另外,业务方在设计的时候往往仅考虑功能需求,未能充分兼顾非功能需求,例如系统查看明细响应的时间不应大于 3 秒等,造成功能上线后,系统出现点击反应时间慢、用户登录过多并发崩溃等问题。
3. 需求未划分优先级
在项目开展过程中,未对需求进行优先级评估,造成需求在后续的开发和设计阶段未能有效区分和排序。项目团队仅管控需求上线的进度,部分非核心紧要的例如二级页面优先上线,核心需求例如业务流程等被推迟,系统上线后功能不完善造成用户体验感差,严重影响业务的正常开展。
4. 需求变更缺乏管控
项目在推进过程中缺乏有效的需求变更管控,随着业务的发展,各级领导的要求、基层的诉求会随着业务的变化而不断变化,业务方提出的需求变更仅通过口头形式告知项目人员,未能够组织开展综合评估,造成后续开发计划和测试进程被打乱,影响项目木整体的进度和质量,增加项目风险。
3 优化措施及成效
3.1 优化措施
1. 组建需求团队
组建包含基层供电所员工、管理层、业务方、项目对接人员、设计人员、开发人员、测试人员的需求团队,明确功能目标对象,通过问卷调查、实地调研、线上会议等多种方式收集需求,组织需求团队召开线上评审会,对需求进行评审,确保达成一致意见,设计开发和测试人员提前介入也能够及时消除理解差异的风险隐患。
2. 明确需求管理流程
完善需求单编制模板,在原有内容基础上增加业务场景、使用对象、功能需求、非功能需求等内容,确保需求内容描述清晰、完整,同时建立严格的需求变更审批流程,开发人员未接收到签字确认的需求单不得直接进行开发。
3. 制定需求优先级
按照 kano 模型进行需求分类,通过组织专家评审共同确认需求的优先级范围,将系统必备核心功能作为纳入一级优先需求,将基层期待的对于提升日常工作效率的功能纳入二级优先需求,将创新性的功能纳入三级优先需求,剔除非必要、可有可无的需求。
3.2 成效
通过一系列优化管控措施,供电所平台项目在二期功能上线后,功能高频应用率达到 90% 以上,上线后系统缺陷数量下降 30% ,用户满意度达到 95% 以上,项目二期取得预期成效。
4 结语
当前,数字化平台技术已经成为业务管控的重要抓手,传统行业对于数字化项目的科学管理仍需强化,通过本次案例可知,供电企业在推进数字化转型过程中,不能盲目的按照业务想法随意增加功能需求,需根据业务开展的实际情况,建立一套规范的软件需求管理机制,实践表明,通过一系列措施的落实,显著提升了用户满意度和项目开发质量。
参考文献:
[1]Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK
Guide)[M]. 6th ed. PMI, 2017.
[2] 陈 丽 杰 . 浅 析 软 件 项 目 管 理 中 的 需 求 管 理 [J]. 科 技 资讯 ,2007,(14):208- 209.DOI:10.16661/j.cnki.1672- 3791.2007.14.177.
[3] 软 件 工 程 的 需 求 分 类 .https://blog.csdn.net/boonya/article/details/14447485
[4]Leffingwell D. Agile Software R equirements: Lean R equirements Practices for T eams, Programs, and the Enterprise[M]. Addison- W esley, 2011.
[5]Gottesdiener E. T he Software R equirements Memory Jogger: A Desktop Guide to Help Business and T echnical T eams Develop and Manage R equirements[M]. Goal/QPC, 2005.