074_西北某省级保障房运营维护系统信息系统项目资源管理

ONEPSOFT | 软考学习知识库

---

保障房建成交付后的运营维护，长期是住房保障工作中最琐碎也最容易失守的一环。西北某省保障房存量达数十万套，房源状态、租户资格年审、租金收缴、维修工单等信息分散在几套年代不一的老系统里，口径不一、更新不同步，主管部门每季度出全省报表都靠人工汇总核对。为改变这一局面，该单位信息管理部门于 2021 年 7 月发起了省级保障房运营维护系统信息系统项目，通过公开招标确定我司为承建方，合同额 285.32 万元，建设周期 9 个月，我担任项目经理，负责项目全过程管理。

项目的目标是把全省保障房的房源、租户、合同、资金、维修五类数据归并到统一平台，实现资格年审自动核验、租金台账自动生成、维修工单闭环流转。建设内容包括房源与合同管理、租户资格核验、租金收缴与对账、维修工单调度、运营监测五个模块，并与民政、公安、社保、不动产登记四个部门建立数据共享接口。系统前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，服务治理引入服务网格 Istio 实现流量管控与灰度发布，数据库选用 GaussDB，热点数据由分布式缓存承载，整体部署为同城双中心多活容灾架构，应用中间件采用东方通 TongWeb，运行于省级政务云信创环境，按等级保护三级完成建设与测评。项目团队共 12 人，采用矩阵型组织，成员包括我在内，另有系统架构师 1 人、需求分析师 2 人、开发工程师 5 人、测试工程师 2 人、实施与数据治理专员 1 人。项目于 2022 年 4 月通过验收并投入运行，跨部门数据共享接口调用量月均突破 120 万次，数据自动核验比例由 42% 提升至 91%，人工重复录入工作量下降 68%。

这个项目的合同额并不算大，团队规模也偏小，但资源紧张的感受却贯穿始终。九个月工期、十二个人、五个模块、四个外部接口，任何一处资源错配都可能拖垮整体节奏。回过头看，项目在资源管理上真正花了力气的，是围绕三道难题展开的三轮攻坚。下面我以这三道难题为线索，说明项目资源管理的基本过程是如何落地的，以及实物资源与人力资源在获取和管理控制上的差别。

一、第一道难题：历史数据质量参差，人和物究竟该往哪里排

项目启动后的首次现场踏勘就暴露了一个棘手情况：四个地市移交的存量数据格式各异，同一个 " 房源编号 " 在三套老系统里有三种编法，租户身份信息的缺项率在部分区县超过三成。数据治理规则一天定不下来，开发就没法确定接口字段，测试也无从准备用例。更麻烦的是，这项工作的工作量到底有多大，谁也说不清。资源如果按经验拍脑袋分配，很可能出现前松后紧的局面。

化解这道难题的第一步是规划资源管理。规划资源管理的产出是《资源管理计划》，它要回答的是资源如何估算、如何获取、如何使用与如何管控。我依据项目章程和范围基准，参照公司同类政务项目的组织过程资产，把资源分为团队资源与实物资源两大类，并明确了一条原则：数据治理属于高不确定性工作，采用滚动方式投入资源，先投一个小组做样本摸底，摸清规律后再决定后续投入量。计划中同时编制了资源分解结构，把服务器、存储、测试终端、办公场地、软件授权等实物资源，与架构、开发、测试、实施等人力资源按层级列清，形成后续跟踪的结构化框架。计划经建设单位信息管理部门与我司分管领导确认后执行。

第二步是估算活动资源，即确定完成各项活动所需资源种类、数量与特性的过程。我们没有直接对整体估算，而是先由数据治理专员带两名开发，用两周时间对四个地市各抽取一千条样本记录做清洗试点，记录实际耗时与缺项修复率。随后我把八个批次的试点数据绘成散点图，横轴为缺项率，纵轴为每千条清洗耗时，图形呈明显正相关，且缺项率超过 25% 后耗时陡增，说明高缺项数据不能与普通数据按同一标准估算。据此我们把全省数据按缺项率分为三档，套用不同单位耗时系数，自下而上汇总出总投入约 1080 人天，其中数据治理占 210 人天，比最初经验估计高出近八成，促成我们及时向建设单位申请延长了数据准备阶段的时间窗口。

二、第二道难题：国产化整体适配，资源怎样才能真正拿到手

估算清楚只是纸面上的事，资源能否按时到位是另一回事。项目明确要求数据库与中间件整体替换为国产产品，GaussDB 与东方通 TongWeb 的采购、政务云资源的开通、原厂技术支持的排期，环环相扣。项目进入第三个月时，我们发现测试环境迟迟建不起来，开发提交的版本堆积在集成队列里无法验证。

我组织了一次根本原因分析。团队沿着 " 测试环境未就绪 " 这一现象逐层追问：为什么未就绪，因为政务云资源未开通；为什么未开通，因为申请单在主管部门内部流转了三级审批；为什么流转慢，因为申请材料中缺少信创产品适配性说明；为什么缺少，因为我们默认这份材料由云平台方提供，而云平台方认为应由承建方出具。分析追到第四层就找到了症结：并非资源不足，而是获取路径上存在一个没人认领的职责空白。找到原因后，我当天补齐材料并请建设单位出面协调，四个工作日内完成开通。这次经历让我深刻体会到，获取资源过程的难点常常不在资源本身，而在获取路径的通畅程度。

获取资源是取得项目所需的团队成员、设施、设备与材料的过程。经过这次波折，我把两类资源的获取路径分别做了梳理：实物资源的获取以采购、招标、租赁与到货验收为主要手段，关注技术参数匹配、供货周期可控与验收标准明确，成败取决于合同条款与流程节点；人力资源的获取则以内部预分派、跨部门谈判、外部招募与虚拟团队组建为主要手段，关注技能匹配度、可用时间窗口与协作意愿，即便人员到岗，产出也需要磨合期才能稳定。本项目中，两名熟悉 GaussDB 的开发工程师是从公司另一个收尾项目谈判调入的，我与对方项目经理反复协商，最终商定前一个月按半天投入、后续全职投入，这种弹性在实物资源获取中并不存在。

对比维度	实物资源	人力资源
获取方式	采购、招标、租赁、调拨，到货后验收	内部预分派、跨部门谈判、外部招募、组建虚拟团队
获取关键	技术参数匹配、供货周期、合同条款与验收标准	技能与经验匹配、可用时间窗口、参与意愿与协作关系
到位判定	以验收单与实物清点为准，结果客观明确	以到岗并通过能力确认为准，需经历磨合期
管控手段	台账登记、领用归还、使用率统计、盘点与报废	绩效观察、任务跟踪、能力建设、激励与冲突处理
主要风险	交付延期、参数不符、损坏丢失	人员流失、能力不足、投入被其他任务挤占
退出方式	归还、移交或按资产制度处置	归建原部门或转入后续项目，需做知识交接

三、第三道难题：用户信息化基础薄弱，队伍怎么带、资源怎么控

第三道难题出现在实施阶段。保障房运营维护的一线操作人员多为社区与街道工作人员，年龄结构偏大，长期习惯纸质台账与线下核验，对新系统抵触情绪明显。培训做了两轮，实际使用率却上不去。这个问题表面看是用户侧的，实质却直接冲击项目团队：一线反馈的问题量激增，开发被频繁打断，团队情绪也随之波动。

应对这一局面，我在建设团队与管理团队两个过程上做了针对性调整。建设团队是提升成员能力、改善团队氛围以提高整体绩效的过程。我把按技术模块划分的小组临时改组为四个 " 地市对接小组 "，每组一名开发搭配一名测试，直接对口一个地市的用户群体，技术人员轮流到街道坐班两天。效果超出预期：开发人员在现场看到老同志如何操作后，主动把七处多级跳转的界面改成一步直达。团队建设上，我按塔克曼阶梯模型的规律，改组初期加大统一口径与规则明确的力度，磨合稳定后再逐步放权，并设每周现场故事分享会，让四个小组交换见闻。

管理团队是跟踪成员表现、提供反馈、解决问题并管理团队变更以优化绩效的过程。改组带来了新的摩擦：两名资深开发认为下沉现场是浪费时间，与实施专员发生了争执。我采取的处理方式是先分别倾听，再把双方约到一起，用数据说话——现场坐班两天带来的界面优化，使该地市的工单提交平均耗时下降了四成。事实摆出来后，分歧自然消解，这属于典型的以合作与解决问题的方式处理冲突，比强制服从更能保住团队士气。

控制资源是确保实物资源按计划可用，并根据资源使用情况对比计划采取纠正措施的过程。为防止后期失控，我在项目中期建立了一份逐项检查清单，每周由质量保证岗对照执行，涵盖存储占用率、终端领用归还、软件授权数量、云配额剩余、投入人天偏差与关键人员安排等十二项。逐项检查不依赖记忆与自觉，照单核对就不会漏项。第六个月的一次检查发现分布式缓存实例规格已接近上限而无人察觉，我们据此提前一个月完成扩容申请，避免了上线初期的性能事故。

需要说明的是，两类资源在管理控制上的侧重同样不同。实物资源控制偏向客观核对，手段是台账、盘点、使用率统计与阈值预警，偏差通过补充采购、调剂或规格调整即可纠正，见效快；人力资源控制偏向主观观察与互动，手段是绩效跟踪、一对一沟通、能力培养与激励设计，偏差往往表现为效率下滑或情绪低落，纠正需要时间且不能简单替换，因为更替本身就带来知识流失。本项目中，服务器配额不足四天内即完成扩容，而一名测试工程师因家庭原因效率下降，我们调整任务难度并安排同事补位，用了近三周才恢复节奏，这个对比很能说明问题。

四、结语

项目最终按期交付并稳定运行至今，数据共享接口调用量月均突破 120 万次，自动核验比例由 42% 提升至 91%，人工重复录入下降 68%，季度报表由人工汇总十余天变为系统自动生成。回顾这段经历，资源管理的六个过程并非照本宣科走流程，而是在每道难题面前找到合适的抓手：散点图让不确定的工作量变得可估，根本原因分析找出了资源获取路径上的职责空白，逐项检查清单把控制资源从依靠自觉变成依靠机制。同时我也认识到，实物资源可以靠合同与台账管住，人力资源必须靠沟通与信任带好，把两者的差别想明白，资源管理才算真正入了门。