ONEP软考智能体 | 软考论文自动生成与批改专家
· 论信息系统的规划绩效域管理
1.概要叙述你参与管理过的一个信息系统项目(项目的背景、项目规模、发起单位、目的、项目内容、组织结构、项目周期、交付的成果等),并说明你在其中承担的工作(项目背景要求本人真实经历,不得抄袭及杜撰)。
2.请结合你所叙述的信息系统项目,围绕以下要点论述你对信息系统项目规划绩效域的认识,并总结你的心得体会::
(1)规划绩效域的绩效要点
(2)影响规划的因素有那些
3.请结合你所叙述的项目,阐述规划绩效域如何执行效果检查!
· 论北方某市智慧工地监管平台项目规划绩效域管理
2022年4月,我作为项目经理负责北方某市住房和城乡建设局智慧工地数字化监管平台项目,合同金额226万元,建设周期12个月,团队采用项目型组织架构,配置14人:我担任项目经理统筹管理,需求分析2人、架构1人、开发5人(后端3人/前端1人/算法1人)、测试2人、交互设计1人、质量管理1人、配置管理1人。该平台面向主城区及重点区县40个标杆工地,服务80余家施工企业、800多名监管人员,日均处理数据约60万条。建设内容包括统一门户、质量安全监管、危大工程监测、设备运维、环境监控、预警中心、BIM协同、决策驾驶舱、移动端应用9个子模块。技术上采用SpringCloud微服务架构,通过Vue.js实现前后端分离,MySQL集群存储业务数据,Redis缓存高频访问数据,Nginx作为负载均衡中间件,RabbitMQ处理异步消息队列。服务器部署采用4台阿里云ECS配合2台边缘节点,保障系统在高并发场景下的稳定性。项目于2023年5月上旬通过验收并正式投入使用,政府巡查工作量减少35%,流程审批提效40%,设备故障平均响应时间从4小时缩短至1.5小时,受到用户一致好评并获行业数字化转型示范案例。
本项目包含183个功能点的开发,涉及政府监管部门、设计、施工企业等多方干系人,存在微服务架构与国产化技术适配等难点,“凡事预则立,不预则废”,规划可以帮助明确项目目标、范围,进度,成本等关键内容。本文结合我在把控规划绩效域的实践经验,从以下几个方面论述规划绩效域对于项目成功的重要性:1)目标导向,以终为始,注重规划绩效域的预期目标管理2)切实专注于规划相关的绩效要点,包括考虑规划的影响因素,合理的项目估算,规划项目团队和实物资源,沟通规划,变更规划,定义合理的度量指标,最后总结心得体会。
一、为了做好规划绩效域,我和团队首先定义了以下6个预期的目标:
1)项目以有条理、协调一致的方式推进;
2)应用系统的方法交付项目成果;
3)对演变情况进行详细说明;
4)规划投入的时间成本是适当的;
5)规划的内容对管理干系人的需求而言是充分的;
6)可以根据新出现的和不断变化的需求进行调整。
二、为了快速高效达成以上6个目标,我和团队重点关注了以下绩效要点
1、考虑规划的影响因素,选择合适的方法,进行合理估算
规划绩效域管理的核心在于全面识别项目内外部约束条件并制定应对策略,由于每个项目的独特性,规划的时间、数量和频率也不尽相同,通常影响规划的因素包括开发方法、可交付物、组织条件、市场需求、法律法规要求等。例如项目启动阶段,我们针对开发需求对比了瀑布型、敏捷型、混合型三种开发方法,过程中我组织项目团队、住建局姚主任以及工地代表进行3次专项会展开讨论,发现政府监管质量安全(如等保2.0三级要求)需求明确,而施工方在BIM协同等功能需求方面仍待细化,团队最终采用混合型开发方案:对统一门户、数据安全等基础模块采用传统分阶段开发方式并设立明确里程碑节点;对危大工程与设备运维、AI安全预警与BIM协同、决策驾驶舱与移动端应用模块采用Scrum敏捷开发,共设置了3个迭代周期,每个迭代周期中以2周为一个冲刺周期。通过该方法,项目得以按期交付并在过程中采纳了23项用户优化建议,获得好评。
|
发布版本 |
主要目标 |
包含冲刺数 |
交付方式 |
|
V1.0 |
完成需求分析与架构设计,搭建基础平台(包含统一门户、质量安全监管等基础应用开发) |
3个里程碑 |
定期交付 |
|
V2.0 |
实现危大工程与设备运维、AI安全预警与BIM协同、决策驾驶舱与移动端应用开发 |
14个冲刺 |
持续交付 |
|
V3.0 |
测试、试运行与交付 |
3个里程碑 |
定期交付 |
2、项目估算
项目估算是量化项目资源投入的基础,并且随着项目的发展,估算可能随之变化。以环境监测模块开发估算为例,我和团队将其拆解为6个核心部分:PM2.5数据采集、温湿度监测、噪音超标预警、设备对接协议开发、数据可视化看板和报警消息推送。采用三点估算法测算总工作量为320人时(40个用户故事×8人时),其中PM2.5监测算法开发原估算80人时,过程中开发组长老杨引入CodeGeeX自动生成数据清洗代码,节省约20%工时。相应的,在硬件部署方面团队初期采用类比估算规划3台服务器,但在环境监测模块模拟1000个工地传感器并发上报数据时发现负载超限,我发起紧急变更流程经CCB评审确认后调整为"4台服务器+2台边缘节点"方案并追加预算8万元,使并发数据处理响应时间优化至0.5秒,该模块也成为了首批通过验收的核心功能。
|
层级 |
名称/内容 |
时间范围 |
总工时 |
详细分解 |
|
版本 |
V2.0发布版 |
2023.7.1-2023.9.30 |
1,200人时 |
包含迭代1(危大工程、设备运维、环境监测) |
|
迭代 |
迭代1(环境监测模块) |
2023.7.1-2023.9.30 |
320人时 |
划分6个冲刺,其中冲刺5-6专用于环境监测 |
|
冲刺 |
冲刺5(核心功能开发) |
2023.8.14-2023.8.27 |
160人时 |
-PM2.5数据采集(50人时)-温湿度监测(30人时)-设备对接协议(80人时) |
|
冲刺 |
冲刺6(预警与展示) |
2023.8.28-2023.9.10 |
160人时 |
-噪音超标预警(60人时)-数据可视化看板(70人时)-报警消息推送(30人时) |
3、项目团队组成与结构规划
规划项目团队的组成和结构时,要考虑项目工作所需的技能组合,项目团队在同一地点开展工作的必要性。当聘请外部人员时,需要平衡人员技能带来的收益与项目成本。本项目组建14人的项目型团队,我作为项目经理统筹团队。在协作过程中,4名开发人员每天在住建局驻场,主责平台搭建与功能开发;聘请1位建筑数字化专家,通过视频会议解答BIM协同模块的行业应用问题答疑(一次性费用5万,比全职招聘节省大笔费用)等。通过外聘内调的方式,所有团队成员技能都得到严格匹配,人岗匹配度≥95%,部分人员配置如下:
|
岗位 |
人数 |
主要能力 |
工作方式 |
|
研发工程师 |
4人 |
系统搭建、模块开发、数据处理等 |
全程驻工地现场 |
|
算法工程师 |
1人 |
智能预警模型开发 |
现场+远程支持 |
|
建筑数字化顾问(外聘) |
1人 |
建筑3D建模与轻量化技术咨询 |
线上会议支持 |
4、沟通规划
沟通是争取干系人有效参与的最重要的因素,对沟通进行规划时,需要与干系人绩效域进行关联,包括干系人识别、分析、优先级排序和参与的内容。我和团队基于干系人权力利益方格制定的沟通管理计划如下:
|
沟通需求 |
沟通的信息 |
时限/频率 |
发起人 |
接收人 |
技术/方法 |
地点 |
|
掌握平台开发进度 |
周报、风险清单 |
每周五下午3点,1小时 |
项目经理 |
住建局负责人、公司高层 |
视频会议 |
公司会议室 |
|
团队日常协作 |
任务进展、问题记录 |
每日上午9点,15分钟 |
项目经理 |
项目团队成员 |
站会 |
项目办公室 |
|
需求变更确认 |
变更申请及影响分析 |
变更提出后48小时内 |
需求分析师 |
住建局业务代表、项目经理 |
邮件+会议纪要 |
线上/线下混合 |
|
阶段性成果验收 |
模块演示、测试报告 |
每模块开发完成后 |
项目经理 |
住建局技术组、监理单位 |
现场演示 |
客户会议室 |
|
紧急问题处理 |
故障描述、解决方案 |
问题发生1小时内 |
运维工程师 |
项目经理、客户技术支持 |
电话+即时通讯工具 |
线上 |
|
1、沟通原则及注意事项: |
||||||
5、实物资源与采购规划
实物资源指人力资源以外的任何资源,包括材料、设备、软件、测试环境、许可证等,而采购活动可能发生在项目的任何阶段,预先规划有助于明确目标,确保采购过程顺利进行,更为项目作好资源保障。例如,选针对环境监测模块服务器方案,我和团队经过分析比选后采用"4台阿里云ECS+2台边缘节点"混合方案,相比初期计划的3台服务器方案虽增加8万元,但成功支撑上千个传感器并发,避免了上线后二次扩容成本;另外,在AI环境数据分析模块选用科大讯飞环境监测SDK(首年授权费9.8万元),PM2.5预警功能通过SDK接口3天即完成对接,具体如下:
|
资源类型 |
配置方案 |
对比分析 |
节省/提升 |
案例说明 |
|
服务器 |
4台阿里云ECS+2台边缘节点 |
原计划3台服务器→升级混合方案 |
支撑上千并发(原先负载超限) |
避免上线后二次扩容,节省潜在成本50万元 |
|
AI环境分析 |
科大讯飞环境监测SDK |
自研需2人×3个月(36万元)→采购费9.8万元 |
节省26万元,提速3个月 |
PM2.5预警功能3天完成对接 |
6、变更规划
本项目开发过程中会发生很多变更,由于采用混合型开发方法,对于统一门户等传统分阶段交付模块,我和团队仍然建立了变更流程机制并在公司层面设置CCB进行评审,并采用Jira工单跟踪;同时针对AI智能监测预警等采用敏捷Scrum开发的功能,核心原则是价值驱动,变更需要快速高效,这块的处理原则相对灵活:对于新的变更,要去全部加到待办事项列表,按照价值进行优先级排序,先行处理优先级高的变更。
7、度量指标和一致性
度量指标是规划、交付和度量工作之间存在的自然联系,确定度量指标、基准和临界值,以及确定测试和评估方法及流程是规划绩效域的重要工作。我和团队基于混合型开发方法,确定了“系统可用性不低于99.9%”等关键度量指标,在项目开展过程中按照度量指标进行检查和测试,确保一致性,部分测试数据如下:
|
测量指标 |
测量标准 |
测量方法 |
实测结果 |
测试日期 |
测试版本 |
备注 |
|
测试覆盖率 |
功能100%/接口≥95% |
自动化测试报告分析 |
100%/88% |
2023.08.10 |
V2.1.0 |
接口文档不全,自动化脚本未覆盖倾斜预警等3个关键API |
|
测试覆盖率 |
功能100%/接≥95% |
自动化测试报告分析 |
100%/96% |
2023.09.05 |
V2.2.0 |
|
|
数据准确率 |
≥95% |
随机抽取2万条数据人工核验 |
81.50% |
2023.12.25 |
V1.3.0 |
温湿度传感器因低温环境影响,8%的数据出现异常波动 |
|
数据准确率 |
≥95% |
随机抽取10万条数据人工核验 |
98.20% |
2024.2.15 |
V1.5.2 |
|
|
设备正常率 |
≥98% |
物联网终端运行日志监控 |
99.10% |
2023.11.01 |
V3.1.0 |
|
|
整改及时率 |
100% |
问题闭环系统跟踪(JIRA) |
100% |
2023.06.25 |
V1.2.0 |
|
|
系统可用性 |
≥99.9% |
监控平台统计 |
99.97% |
2023.12.05 |
V3.2.0 |
|
|
A级缺陷率 |
≤0.01% |
缺陷管理系统统计 |
0.01% |
2023.08.20 |
V2.1.3 |
|
|
故障密度 |
≤0.05% |
运维故障台账统计 |
0.03% |
2023.10.10 |
V3.0.0 |
|
针对部分初期测试不达标的问题,我和团队进行了快速响应。例如,部分工地低温传感器在-12℃下出现数据异常,团队分析发现是传感器硬件不耐低温且采购流程缺少极端环境测试导致。我和团队通过应急处理,完善传感器设备低温测试标准并对问题设备进行及时替换成功解决,在最终测试中数据准确率达到98.2%。
三、执行效果检查
在项目的整个生命周期过程中,我和团队每个冲刺应用Jira管理工具对规划绩效域的执行效果进行了检查,确保有效执行并实现预期目标,具体检查方法如下表:
|
预期目标 |
指标及检查办法 |
|
项目以有条理、协调一致的方式推进 |
①按三个发布计划(V1.0基础平台块/V2.0功能模块/V2.0迭代优化)推进,每2周召开冲刺评审会议; |
|
系统性交付成果 |
①每个冲刺交付可部署的微服务组件(如预警中心、环境监控); |
|
需求演变可追溯 |
①通过Jira记录183个功能点变更,闭环率100%; |
|
规划投入时间成本合理 |
①每冲刺开展挣值分析(CPI=1.02); |
|
充分响应干系人需求 |
①邀请15家施工代表企业参加原型评审,需求采纳率≥90%; |
|
灵活应对需求变化 |
①通过CCB处理23项变更(如边缘节点扩容); |
项目于2023年5月顺利完成验收,智慧工地监管平台成功实现设备故障响应效率提升62.5%、安全事故率同比下降25%的目标,并获评省级“智能建造示范项目”。智慧工地项目的成功印证了开发方法与生命周期绩效域管理在复杂信息系统建设中的关键作用。通过混合型方法的应用,项目在需求稳定性与灵活性、技术规范性与创新性之间找到平衡点,而分层交付节奏与工具化协同机制则保障了效率与质量的双重目标。尽管项目成果显著,仍存在改进空间:例如硬件设备兼容性风险未能完全预判,导致部分传感器数据异常等。未来,团队计划进一步优化开发方法融合机制,例如在前期需求阶段引入设计思维提升用户参与度,同时探索低代码平台加速非核心模块开发,以应对更大规模的全市工地接入挑战等。通过不断提升能力,精进业务为建筑行业数字化转型客户提供更加优质的服务。
ONEPSOFT Use AI, Beyond AI