187_粤西某省会城市供热管网智能调控系统信息系统项目团队绩效域

ONEPSOFT | 软考学习知识库

---

粤西地区某省会城市的供热管网调控长期依赖人工值守与电话调度，供热数据、管网状态、调控指令等环节分散在各热力公司与市供热主管部门手中，并发访问峰值集中在供热高峰期、性能压力大，项目周期紧、法定验收时点刚性、进度压缩明显，业务连续性要求高、割接窗口极为有限，调控不及时、供热不均、能耗偏高。为把供热管网调控业务数字化，该市供热主管部门于 2023 年 10 月发起了供热管网智能调控系统信息系统项目，经公开招标由我司承建，合同额 168.24 万元，建设周期 9 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合供热管网全流程数据，实现供热监测在线化、管网调控智能化、能耗分析精准化。建设内容包括供热监测、管网调控、能耗分析、告警处置、统计分析与报表五个模块，并与各热力公司及市供热主管部门对接。技术方案上，业务表单与流程依托低代码平台快速配置，微服务网关统一管理接口，供热数据存放于 OceanBase 数据库，消息通过 RocketMQ 异步推送，前端基于 Vue3 组件体系实现，后端以 Java 17 与 Spring Boot 编写，应用部署在市政务云环境，安全建设按等保三级标准同步实施。项目团队按矩阵型组织搭建，全队 18 人，其中需求分析 3 人、研发 8 人、测试 3 人、实施运维 3 人、数据治理 1 人，编制随模块规模动态调整，联调高峰期另调集厂商力量集中攻坚。项目于 2024 年 7 月通过终验，上线后识别准确率达到 94.6%，误报率控制在 3% 以内，线上办理率由 51% 提升至 93%，跨部门数据共享接口调用量月均突破 120 万次。

团队绩效域解决的是项目靠什么样的人、怎么把这些人带成一支队伍的问题。这个项目性能压力大、周期紧、割接窗口极有限，团队稍不带好，高峰扛不住、进度保不住、割接出乱子，项目必然受挫。下面我围绕项目推进中遇到的三道难题，说明团队绩效域的各项过程与工具是如何嵌入其中发挥作用的。

一、难题一：供热高峰并发压力大，如何把性能攻坚组织起来

供热监测数据在高峰时段集中涌入，并发访问峰值高，若性能不达标，调控指令延迟、监测数据积压，直接影响供热安全。性能攻坚不是一个人的事，而是整个技术队伍的事，我们按 " 问题—根因—归队 " 的方式组织：先用帕累托图对性能缺陷做了分类统计，按缺陷类型统计发生频次，发现约两成的缺陷类型占据了八成以上的问题，集中在数据接口响应慢与告警消息积压两类，据此把性能优化任务按优先级分配给最擅长的队员——接口优化交给网关组，消息积压交给消息组，测试组同步补充压测用例，性能优化的主攻方向一下子清晰起来。针对高峰期的并发场景，我们把攻坚任务拆成小批次：每批次明确目标、责任人与完成时限，攻关期间每天对齐一次进度，连续两周的集中攻坚后，接口响应时间由 4.2 秒压缩到 1.1 秒，并发承载能力从 800 提升至 5000 用户在线，绩效指标全部达标，供热高峰期无一例调控指令超时，市民用热体验得到明显改善。攻坚期间还有一个插曲：某天压测发现告警消息出现偶发丢失，消息组当晚定位到是消费端限流参数配置不当，连夜调整参数并补充了重试机制，次日复测通过，这样的 " 当晚闭环 " 在攻坚期出现过多次，队伍的执行力正是在一次次闭环中磨出来的。性能攻坚让我体会到：难题不可怕，可怕的是让所有人一起陷进同一个问题里，把问题归因清楚、分工到人，队伍的力量才能拧成一股绳。

二、难题二：周期紧、验收时点刚性，如何把交付节奏守住

9 个月的建设周期、法定验收时点刚性，进度压缩明显，若队伍节奏失控，验收必然延期。守住节奏，靠的不是催，而是把进度责任落到每一个人。我们把里程碑拆到周：每个模块的负责人每周报一次完成情况，偏差超过容忍范围的当场复盘原因、调整排期。针对协作中的隐性失速，我们用质量审计的方式对团队协作做了核查，抽查各模块的完成证据与接口文档，发现供热监测与告警处置两个模块之间的联调文档更新不及时，存在 " 各写各的 " 的情况，审计定位到是接口契约没有专人维护，随即指定了接口负责人，文档先行、代码跟进，联调效率明显提升。针对任务分配不均的问题，我们用帕累托图对工时分布做了统计，发现两成的任务类型占据了八成以上的工时，集中在联调与数据初始化两类，据此把资源向这两类倾斜并调整了分工，团队负荷趋于均衡，没有人长期过载，也没有人长期闲置。以验收准备为例，我们把验收材料拆成功能、性能、安全、文档四类，由专人逐类跟进，发现安全测评的准备时间被低估，随即提前启动了等保测评流程，最终验收一次通过。周节奏的制度还带来了一个副产品：因为每周都要报完成情况，各模块负责人对风险的感知变敏锐了，问题往往在变成危机之前就被报上来，队伍因此不是被动救火，而是主动排雷。节奏守住的根本，是让每个成员都清楚自己的任务在整体中的位置，人人心中有数，节奏才不会乱。

三、难题三：业务连续性要求高、割接窗口极有限，如何把割接组织好

供热业务不能中断，割接窗口极为有限，割接质量直接关系民生保障，对队伍的协同组织是严峻考验。我们把割接当成一次 " 协同作战 " 来组织：第一步，明确分工——实施组负责数据迁移，运维组负责切换执行，测试组负责切换后验证，各组的职责、时限、责任人写进割接方案；第二步，演练磨合——正式割接前组织了两轮演练，首轮演练发现数据迁移耗时过长，据此优化了迁移脚本并增加并行度，第二轮演练一次通过；第三步，正式割接——割接当天各组按方案各就各位，割接一次成功，供热业务没有中断一天。割接完成后，我们用统计抽样按供热区域与数据类型分层抽取样本，对迁移数据的完整性与准确性逐条核验，抽到的差异当场定位原因、限期修正，迁移数据全部对得上，供热主管部门对数据切换的可靠性给予了肯定。复盘这次割接，我最大的感触是：方案上的分工是一回事，队伍是否真正吃透分工是另一回事，两轮演练的价值正在于此——演练不仅验证了技术方案，更让各组在实际配合中摸清了彼此的节奏，正式割接时才没有出现 " 临时问谁负责什么 " 的情况。割接让我体会到：越是窗口窄、风险高的任务，越考验队伍的组织纪律性，平时演练到位、分工清晰，关键时刻才顶得住。

项目最终按期通过终验，识别准确率达到 94.6%，误报率控制在 3% 以内，线上办理率由 51% 提升至 93%，各热力公司与市供热主管部门对系统的认可度明显提升。复盘整个项目，我的体会是：团队绩效域的价值不在于人多人少，而在于难题面前有人扛、节奏面前有人守、关键时刻靠得住。帕累托图让性能问题有了主攻方向，质量审计让协作失速现了原形，统计抽样让割接结论经得起核查。9 个月里最深的感触是：一支队伍靠不靠得住，平时看不出来，压力时刻才见真章，而平时的归因分工、例会复盘与割接演练，正是压力时刻的底气。供热是民生工程，供热项目的团队建设同样讲究 " 热 " 字——把队员的心焐热，队伍才肯在关键时刻往前冲，这个体会比任何方法论都让我印象深刻。这套围绕三道难题展开的团队建设做法，后来被整理成公司在城市能源类项目的团队管理参考，供后续同类项目复用，也让后来的供热类项目少走了不少弯路，团队建设的价值由此得以延续。