079_皖南某地市级政务热线工单系统信息系统项目资源管理

ONEPSOFT | 软考学习知识库

---

皖南某地市 12345 政务服务热线话务量逐年攀升，高峰期集中在工作日上午九点到十一点，座席应接不暇，工单登记、转派、催办长期依赖人工与纸质台账，同一诉求常被重复登记，办理进度靠电话催问，群众满意度不高。为改变这一状况，该地区政务服务管理部门于 2021 年 2 月发起了地市级政务热线工单系统信息系统项目，经公开招标由我司承建，合同额 1380.08 万元，建设周期 9 个月，我担任项目经理，负责项目的全过程管理。

项目建设目标是整合热线话务、工单流转与办理反馈，实现接诉即办、全程留痕。建设内容包括话务工单受理、智能派发与催办、办理与回访、知识库、统计分析与报表五个模块，并与公安、市场监管、供水供电燃气等十余个部门建立数据接口。系统整体采用 B/S 架构，前端以 Vue3 与 TypeScript 构建，服务端基于 Java 17 与 Spring Boot 的微服务体系，服务间经微服务网关统一鉴权限流，业务数据落在 OceanBase 分布式数据库，异步消息由 RocketMQ 承载，表单与流程依托低代码平台快速配置，中间件选用东方通 TongWeb，部署于市政务云信创环境，并按等级保护三级完成安全测评。团队按矩阵型组织运作，项目经理之下按需求、开发、测试与实施四条线分工：需求分析师 2 人、架构师 1 人，后端开发 4 人与前端开发 2 人组成开发线，测试工程师 2 人与实施工程师 1 人负责质量与落地，质量保证与配置管理岗位由专人把关，连同我在内共 15 人。项目于 2021 年 11 月通过终验，上线后关键业务响应时间由 4.2 秒降至 1.1 秒，线上办理率由 51% 提升至 93%，跨部门数据共享接口调用量月均突破 120 万次。

热线工单系统是典型的并发敏感型应用，高峰时段话务与工单并发量是平日的数倍，资源安排稍有偏差，响应时间就会明显劣化。这个项目让我深刻体会到，资源管理的关键不在于堆砌资源，而在于把有限的人与物投放到最需要的位置。资源管理贯穿项目始终，从规划到收尾，每个过程都留下了可检查的痕迹。下面我按资源管理的六个标准过程，结合本项目的实际做法逐项展开。

一、规划资源管理

规划资源管理过程解决的是资源工作按什么规矩运转的问题，其主要产出是《资源管理计划》与团队章程。编制计划时，我没有直接套用公司模板，而是先回答三个问题：资源从哪里来、怎么用、怎么控。围绕这三个问题，我召集各条线骨干逐项讨论，把话务高峰集中在工作日上午九点到十一点的时段特征写进计划，明确资源投入按波动曲线安排而不是按平均值平摊，并同步制定了团队章程，约定沟通方式、决策权限与冲突处理原则。计划经政务服务管理部门与我司分管领导确认后执行，成为后续一切资源工作的依据。同时，我在计划中明确了资源变更的审批路径：凡涉及人员增减或实物资源调整，一律先评估影响再报我审批，避免资源使用失控。

二、估算活动资源与资源分解结构

估算活动资源要回答每个活动需要什么资源、要多少的问题。以 WBS 活动清单为依据，我们对接口联调、话务数据迁移等活动参照历史项目经验估算，对数量可推算的活动则按单位工作量乘以规模得出，输出资源需求清单。估算过程中我们发现，话务高峰期的并发量是平日的四倍以上，若按平均量配置服务器，高峰时段必然出现排队，因此我们按峰值加三成冗余的原则确定了服务器与缓存节点规模，这个结论也写进了资源需求清单。在此基础上，我组织团队形成了本项目的 RBS，把全部资源按类别逐级分解（见表 1），子题目要求的 RBS 由此落实。

资源类别	资源明细与规模	主要用途
项目管理	项目经理、质量保证、配置管理各 1 人	统筹推进、过程质控与配置基线
需求分析	需求分析师 2 人、架构师 1 人	需求梳理与总体架构
开发	后端开发 4 人、前端开发 2 人	服务端与界面开发
测试与实施	测试工程师 2 人、实施工程师 1 人	验证把关与现场部署
计算与存储	应用服务器 3 台、数据库服务器 2 台、缓存节点 4 台	承载应用、数据与热点缓存
网络接入	政务云专线 1 条、座席话务终端 40 台、IVR 语音网关 2 套	接入与话务处理
软件与许可	OceanBase、TongWeb 授权与开发测试工具	运行与开发支撑

三、获取资源

获取资源是把纸面上的资源需求变成实际可用的人与物的过程。人手与设备到位是开工的前提。人力资源方面，我逐岗位与公司人力资源部门核对到岗时间表，从其他项目借调的两名骨干，与其项目经理商定了分阶段投入比例，避免两头拉锯；两名新入职的实施工程师则在开工前完成了话务终端的部署培训。实物资源方面，我把获取流程画成流程图贴在项目部：申请、审批、采购或调配、到货验收、入库登记五个环节环环相扣，任何一环缺材料都会卡住。流程画出来之后，责任人一眼可见，申请材料缺什么当场补齐，云资源、专线带宽以及数据库、中间件授权相继到位，比预期顺畅。

四、建设团队与责任分配矩阵

建设团队是提高团队成员能力和互动、提升整体绩效的过程。团队组建初期，我把新老成员混编到各开发小组，让有热线类系统经验的老人带新人熟悉业务，同时组织了两次业务科室开放日，让开发人员直接旁听座席接听电话，理解群众的真实诉求。开放日之后，开发人员对座席工作的理解明显加深，提出的界面方案更贴合实际话务场景，例如把常用诉求的回复模板内置到输入框上方，座席无需反复敲键盘，这个建议就来自一次旁听。任务分配上，我引入 RACI 矩阵来明确每个工作包的职责，矩阵中的 R、A、C、I 四个符号分别对应执行、批准、咨询与知会四种角色。以话务工单受理模块为例，表 2 给出该模块部分工作包的 RACI 分配。矩阵成了团队分工的共同语言，谁负责、谁批准、咨询谁、知会谁在开工前就已对齐，跨条线协作的摩擦明显减少。

工作包	执行 (R)	批准 (A)	咨询 (C)	知会 (I)
话务工单受理开发	后端开发组	项目经理	系统架构师、热线业务科室	前端开发组、测试组
智能派发规则配置	后端开发组	项目经理	热线业务科室	测试组
回访评价界面	前端开发组	项目经理	后端开发组	测试组
端到端联调测试	测试组	项目经理	系统架构师	实施工程师
座席终端部署	实施工程师	项目经理	测试组	热线业务科室

五、管理团队

管理团队过程关注的是成员绩效的跟踪、反馈与团队变更的处理。项目中期，测试组与开发组在缺陷分级标准上产生分歧，测试坚持按严重程度分三级，开发认为部分缺陷可以合并处理，双方互不相让，联调一度停滞。我没有急于仲裁，而是用五问法顺藤摸瓜：先问分歧的表层原因，再问为什么会形成两套标准，追到第二层发现是验收标准中对缺陷的定义写得含糊，两套理解都有出处。我随即组织双方对照验收标准逐条澄清，把缺陷分级规则补充进团队章程，分歧就此消除。这次经历让我认识到，许多团队冲突的根源不在态度，而在规则本身含糊，管理团队要做的不是当裁判，而是把规则补清楚。此后我把 RACI 矩阵的维护纳入每周例会的固定议题，凡工作包拆分或人员变动，先更新矩阵再开工，从机制上堵住责任真空。

六、控制资源

控制资源是确保所分配的资源被有效使用、并在出现偏差时采取纠正措施的过程。我们每周核对一次资源使用情况，把数据汇总成报表分析：座席话务终端的故障率一度达到 3%，且集中在老旧型号上，我们据此调整了终端更换计划，优先替换故障率最高的批次；话务高峰时段 IVR 网关的 CPU 利用率在仪表盘上长期超过 85%，我们用数据分析定位到部分话务记录未做压缩处理、日志写入量偏大，随即优化了日志策略并启用异步写入，峰值利用率回落到 60% 左右。数据让资源控制从拍脑袋变成了看指标，也让建设单位看到资源使用始终有据可查。这种基于数据的控制方式，在项目收尾复盘时也派上了用场，每一项资源投入都能追溯到具体用途。

七、结语

项目按期交付并稳定运行至今，关键业务响应时间降至 1.1 秒，线上办理率提升至 93%，接口调用量月均突破 120 万次。回顾这段经历，资源管理不是资源越多越好，而是该有的人到岗、该有的物到位、该划清的责任不模糊：资源目录因 RBS 而完整，获取路径因流程图而清晰，责任边界因 RACI 而分明，问题归因因五问法与数据分析而准确。把资源这件事管扎实，项目就有了最基本的保障。热线工单系统的顺利交付也再次证明，对并发敏感型项目而言，资源管理的价值尤其显性——高峰时段的每一分投入，都直接体现在群众的等待时间上。