078_华南某区县级智慧养老服务平台信息系统项目资源管理

ONEPSOFT | 软考学习知识库

---

华南地区某区县老龄化程度较高，独居老人与高龄老人数量逐年上升，养老服务站点分散在各街道社区，服务资源底数不清、调度靠人工电话，紧急呼叫响应慢，主管部门难以掌握全区养老服务的真实运营情况。为破解这一难题，该地区民政主管部门于 2021 年 11 月发起了区县级智慧养老服务平台信息系统项目，经公开招标由我司承建，合同额 592.00 万元，建设周期 11 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合全区养老服务资源，实现服务工单、紧急呼叫、健康监测数据的统一汇聚与调度。建设内容包括老年人档案管理、服务工单调度、紧急呼叫与定位、健康监测数据接入、服务商管理与结算五个子系统，并与卫健、医保、街道社区的既有系统对接。技术方案采用服务网格 Istio 实现微服务流量管控与灰度发布，整体部署为同城双中心多活容灾架构，数据库选用 GaussDB，热点数据由分布式缓存承载；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件采用东方通 TongWeb，系统部署在区级政务云信创环境，按等级保护三级完成安全建设。项目团队共 22 人，采用矩阵型组织，除我之外配置系统架构师 1 人、需求分析师 2 人、开发工程师 11 人、测试工程师 3 人、实施与运维工程师 2 人、质量保证与配置管理各 1 人。项目于 2022 年 10 月通过终验，上线后设备在线率由 83% 提升至 98.5%，系统可用率稳定在 99.9% 以上，全年重大故障零起，识别准确率达到 94.6%、误报率控制在 3% 以内。

资源管理关注的是项目靠什么把事做成：人要到位、物要可用、职责要清晰。这个项目合同额不大，但涉及全区上百个养老服务站点、二十多家服务商与多套外部系统的对接，资源种类杂、分布散，一开始我就意识到，资源分解与任务分配这两件事做不好，后面寸步难行。下面我从理论认识、实践做法、反思改进三个层面，谈谈本项目在资源管理上的思考与作为。

一、对项目资源管理的理论认识

从理论上讲，项目资源管理包含规划资源管理、估算活动资源、获取资源、建设团队、管理团队、控制资源六个过程，其目的是确保项目在适当的时间以适当的成本获得并使用适当的资源。资源分为团队资源与实物资源两大类：团队资源指人，实物资源指设备、材料、设施与软件许可等。

从理论上讲，资源管理的两个核心工具是资源分解结构（RBS）与责任分配矩阵（RACI）。RBS 按类别与层级把项目所需资源逐级分解，回答需要哪些资源、各多少的问题；RACI 矩阵把工作包与角色关联起来，回答谁负责做、谁批准、咨询谁、告知谁的问题。两者一个管资源目录，一个管责任分工，都是规划资源管理过程的主要产出。

从理论上讲，人力资源与实物资源的管理逻辑不同：实物资源可以靠台账与合同管住，人力资源必须靠沟通与激励带好，而且人员能力与协作关系会直接影响团队绩效，因此建设团队与管理团队两个过程在资源管理中占有特殊地位。

二、资源管理的实践做法

规划资源管理是定义如何估算、获取、管理和利用团队资源与实物资源的过程。我依据项目章程与范围基准，组织需求、开发、测试与实施骨干共同编制了《资源管理计划》，明确了资源估算方法、获取方式、角色职责与管控规则，并同步编制了团队章程。在此基础上，我们形成了本项目的资源分解结构（RBS），按团队资源与实物资源两大类逐级分解：团队资源细化到岗位与人数，实物资源细化到服务器、存储、网络、终端与软件许可。RBS 简表见表 1，它回答了子题目中团队资源与实物资源各有哪些的问题。

一级	二级	三级	规模
团队资源	项目管理	项目经理 1 人、质量保证 1 人、配置管理 1 人	3 人
团队资源	需求与设计	需求分析师 2 人、系统架构师 1 人	3 人
团队资源	开发	后端开发 6 人、前端开发 5 人	11 人
团队资源	测试与实施	测试工程师 3 人、实施运维 2 人	5 人
实物资源	服务器与存储	应用服务器 4 台、数据库服务器 2 台、分布式缓存节点 3 台	9 台
实物资源	网络与终端	政务云专线 1 条、应急网关 2 套、健康监测终端 30 台	若干
实物资源	软件与许可	GaussDB 许可、TongWeb 许可、开发测试工具	各 1 套

估算活动资源是确定完成各项活动所需资源种类、数量与特性的过程。基于 WBS 活动清单，我们采用类比估算与参数估算相结合的方式：对接口联调、数据迁移等有历史经验的活动采用类比估算，对站点设备部署这类可按数量推算的活动采用参数估算。例如紧急呼叫与定位模块的联调，参照同类养老项目的经验，估算需要后端开发 2 人、测试 1 人、实施 1 人共投入 6 周。估算结果汇总形成《资源需求清单》，并与 RBS 逐项核对，确保资源目录与需求一致。

获取资源是取得项目所需人力资源与实物资源的过程。人力资源方面，项目启动时正值公司多个项目并行，人手紧张，我们通过内部预分派争取到有养老行业经验的骨干，并对外招募了两名熟悉健康监测设备的实施工程师；两名关键岗位的投入比例与交接节点，则通过与公司其他项目经理反复协商确定。实物资源方面，政务云资源、专线带宽与国产数据库、中间件许可的采购按计划推进，其中 GaussDB 与东方通 TongWeb 需要原厂技术支持，我们提前与厂商锁定排期，避免测试环境迟迟建不起来。对健康监测终端的选型，我们引入面向 X 设计矩阵，把候选设备按面向可靠性、面向易维护性、面向成本三个目标交叉评分，最终选定在弱网环境下仍能稳定回传数据的型号。

建设团队是提高成员能力、改善团队氛围以提高整体绩效的过程。针对团队中新老成员比例接近、跨条线协作频繁的特点，我重点做了两件事：一是按塔克曼团队发展阶段模型，在组建初期加大统一口径与规则明确的力度，快速渡过震荡期；二是用 RACI 矩阵把每个工作包的职责事先说清楚。RACI 矩阵是明确工作包与角色责任关系的工具，R 代表执行者，A 代表批准者，C 代表咨询对象，I 代表告知对象。以紧急呼叫与定位模块的部分工作包为例，RACI 矩阵示例如表 2。

工作包	项目经理	系统架构师	后端开发	前端开发	测试工程师	实施运维	民政业务科室
呼叫接入开发	A	C	R	I	C	I	C
定位与地图集成	A	C	R	I	C	I	I
工单调度界面	A	I	C	R	C	I	C
端到端联调测试	A	C	I	I	R	C	I
站点设备部署	A	I	I	I	C	R	I
上线试运行确认	A	C	I	I	C	R	C

矩阵发布后，谁干活、谁拍板、问谁、告诉谁一目了然，跨条线扯皮明显减少，尤其是多个人都有权拍板这类模糊地带被提前消除。

管理团队是跟踪成员表现、提供反馈、解决问题并管理团队变更的过程。项目中期，两名开发工程师因工作分配不均产生摩擦，我运用合作与解决问题的冲突处理方式，先分别倾听，再把双方叫到一起重新核对 RACI 矩阵，发现确有职责重叠，随即调整了工作包边界，矛盾随之化解。控制资源是确保实物资源按计划可用并及时纠正偏差的过程。我们建立了一周一次的实物资源巡检，用直方图统计各类资源的使用率分布，发现测试环境使用率集中在 90% 以上、接近饱和，而开发环境资源空闲较多，据此调整了环境配额，避免了联调阶段的资源瓶颈。对偏远站点网络专线覆盖不全的问题，我们采用亲和图把各站点的通信问题归类，发现多数集中在专线未铺设与信号弱两类成因上，据此为偏远节点补充了无线备份链路，设备在线率由 83% 提升至 98.5%。

三、反思与改进

项目虽按期交付，仍有值得检讨之处。其一，RBS 初稿遗漏了应急网关备件的数量，导致关键节点故障时备件不足，后期才补充采购，若在规划资源管理时多与运维人员核对一遍底数本可避免。其二，估算活动资源时对国产数据库的调优工作量估计偏低，联调阶段开发人力一度紧张，此后我推动把国产化适配作为估算的独立科目。其三，RACI 矩阵初期粒度偏粗，个别工作包只有 R 没有 A，出现了责任真空，后续统一为每个工作包强制指定唯一 A。这些经验已沉淀进公司的《经验教训登记册》。

综上，资源管理的价值不在于把表格做得漂亮，而在于让人、物、责三件事对得上：RBS 让资源目录完整可查，RACI 让责任边界清晰可依，直方图与亲和图让资源使用与站点问题有了数据分析的基础。依靠这套机制，项目在专线覆盖不全、数据初始化量大、国产化适配要求高的多重约束下按期交付，设备在线率提升至 98.5%，系统可用率保持在 99.9% 以上，全年重大故障零起，得到了民政主管部门的认可。