067_粤西某县域创业担保贷款管理系统信息系统项目资源管理

ONEPSOFT | 软考学习知识库

---

一、项目概况及该项目在资源方面的情况

创业担保贷款是扶持城乡劳动者自主创业的重要政策工具，但在粤西某县域，这项业务长期依靠纸质材料流转办理：申请人要在镇街窗口、担保机构和经办银行之间跑三四趟，经办人员靠手工台账记录额度和还款情况，贴息核算全凭人工比对，既慢又容易出错。为把政策红利真正落到创业者手上，该地区人力资源和社会保障主管部门于二〇二二年十二月立项建设粤西某县域创业担保贷款管理系统，由我所在单位承建，合同额一千二百六十万五千八百元，建设周期十四个月，二〇二四年二月通过验收上线。

系统围绕创业担保贷款的全链条设计，包含在线申请与资格预审、联审联办、担保额度管理、银行放款对接、贴息核算与拨付、贷后风险预警六个业务模块，另配一套面向主管部门的监管驾驶舱。交付成果包括系统软件与部署包、源代码及接口文档、历史台账迁移数据集、操作手册与培训课件、等级保护测评报告和竣工验收资料共六类。技术方面，业务表单与审批流程通过低代码平台配置，以适应政策口径的频繁调整；各微服务经统一网关完成鉴权、限流与路由；数据存储采用 OceanBase 分布式数据库；跨系统的放款与还款消息通过 RocketMQ 异步投递，避免银行侧接口抖动影响本地业务；前端使用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件选用东方通 TongWeb，整体部署于政务云信创环境，安全防护按网络安全等级保护第三级建设。项目采用矩阵型组织，团队十三人，我担任项目经理，主持全过程管理并直接负责资源的筹划与调度。系统运行后，人工重复录入工作量下降百分之六十八，风险预警事件的平均处置时长缩短百分之五十五，申请人平均业务办理时长由三点五个工作日压缩至零点八个工作日。

就资源而言，本项目有三个先天不利条件。一是全县十九个镇街中有六个尚未实现政务网专线全覆盖，偏远节点通信稳定性不足，现场实施人员往返成本高、有效工时低；二是近八年的纸质台账共两万七千余卷，数据初始化的录入与校核工作量巨大，短期内需要成倍的人力投入；三是国产化替代要求下，数据库与中间件必须整体适配，具备相应经验的工程师在本地市场十分稀缺。资源的紧张不是均匀分布的，而是集中爆发在特定时段和特定岗位上，这就要求资源管理必须与时间线紧密咬合。下面我按项目的前期、中期、后期三个阶段，说明我是如何开展资源管理的。

二、项目前期：把资源的盘子先算清楚

在项目启动与规划阶段，需要定义如何估算、获取、管理和使用团队资源与实物资源，这一工作被称为规划资源管理。二〇二二年十二月至次年一月，我先后组织了三轮研讨，参加者包括主管部门的业务处室负责人、担保机构和经办银行的联络人以及本单位人力和采购部门。以项目章程给出的资金边界和范围基准所界定的交付内容为依据，我们形成了资源管理计划，其中明确了四件事：资源如何识别、通过什么渠道获取、由谁对什么负责、何时释放。与此同时，团队共同商定了团队章程，把值班规则、镇街出差的报备方式、分歧升级的路径和决策权限一一写明。考虑到实施人员长期在外，我特意在章程中约定了远程参会的纪律与日报制度，避免出现管理真空。

在明确管理规则之后，需要估算执行项目所需的团队资源以及材料、设备和用品的类型与数量，这一工作被称为估算活动资源。数据初始化是本项目最难估的一块。我没有让团队直接给总数，而是先抽取三个镇街做试点录入，实测出每卷台账的平均处理工时，再按卷数推算总量，同时用标杆对照的方法，调取本单位两年前承建的邻县社保档案数字化项目的人均日录入量作为参照。两组数据相互印证后，我们把数据初始化的人力需求定为外部协作录入人员十二名、校核人员三名，持续四个月。设备方面估算出实施用便携工作站十台、便携式打印扫描一体机六台、临时数据服务器两台，以及应对偏远节点的无线路由备用链路设备若干。这些结论连同其他工作包的口径一并写入资源分解结构和资源需求文件，成为后续采购与调人的唯一依据。

三、项目中期：把人拉齐、把设备铺开

进入执行阶段，需要获得项目所需的团队成员、设施、设备、材料和用品，这一工作被称为获取资源。人力方面，具备国产化适配经验的数据库工程师是最难求的一环，本单位内部仅有一人且已排满档期。我一方面向公司技术委员会申请把这名工程师以每周两天的方式分时投入本项目，另一方面通过外部技术服务合作补充一名中间件适配顾问，两人以线上评审加现场攻坚相结合的方式协同工作。录入与校核人员则通过与本地人力服务机构签订短期协作协议解决，签约前我明确了保密义务与质量责任。实物方面，实施装备通过比选采购获得，到货后逐台清点接收并编号登记，形成设备台账与资源日历，谁在哪个镇街用哪台设备一目了然。

队伍拉齐只是开始，能不能打硬仗还要靠带。此时需要提高团队工作能力、促进成员互动、改善整体氛围，这一工作被称为建设团队。我把每月最后一个周五定为集中回炉日，上午由数据库工程师讲适配踩坑实录，下午由镇街实施骨干讲现场应对经验；同时把攻关贡献纳入月度表扬名单并给予相应奖励。对外部协作的录入人员，我安排了统一的上岗培训与考核，未通过者不得独立作业。三个月后，团队处理同类适配问题的平均耗时下降了近三成，录入人员的一次通过率也从起初的八成一升至九成六。

四、项目后期：把队伍稳住、把资源盯牢

后期是矛盾最集中的时候。此时需要跟踪成员表现、提供反馈、解决问题并管理团队变更，这一工作被称为管理团队。项目第十个月，实施组与开发组因偏远镇街反复返工产生了明显对立：实施组抱怨版本不稳定害得他们白跑，开发组则认为现场反馈描述不清无法复现。我没有各打五十大板，而是把双方叫到一起还原了最近十二次返工的全过程，随后调整了两项规则：现场问题必须附带日志与录屏方可提交；每个版本发布前须在模拟弱网环境下跑通全流程。规则落地后，返工次数迅速回落，两组关系也随之缓和。对连续在外作业的实施人员，我协调安排了轮休与交通补助，把士气稳住。

与此同时，需要确保按计划分配实物资源、监督其实际使用情况并按需纠偏，这一工作被称为控制资源。我以资源日历为基准按周比对计划与实际。为了看清趋势而非只盯单点，我把每周的实施人均有效工时绘成控制图，设定上下控制界限。第十一周和第十二周连续出现落在下控制限以下的异常点，说明这不是随机波动而是系统性问题。我随即组织团队用因果图从人、机、法、环四个方面追查，最终锁定两条主因：一是六个未通专线的镇街依赖临时无线链路，中断频繁导致数据回传反复重试；二是实施排班按行政区划顺序推进，未考虑路线距离，路上耗时过长。对症下药之后，我为无线链路增配了本地缓存断点续传能力，并按地理邻近重排了走访路线，同时把闲置在县城的两台工作站调剂给现场组使用。第十四周起，人均有效工时重新回到控制界限之内，整体进度追回了七个工作日。项目收尾时，我按计划及时释放了短期协作人员和租用设备，未发生资源闲置空耗。

五、心得体会

本项目按期通过验收，各项指标均达到预期。这段经历让我体会最深的有三点。第一，资源估算不能拍脑袋，试点实测加标杆对照这两条腿走路，得出的数字才敢用。第二，资源管理必须跟着时间线走，前期定盘子、中期铺人力、后期抠效率，每个阶段的着力点完全不同，用一套办法从头管到尾必然失灵。第三，发现资源异常要善用趋势工具，控制图让我在第十一周就看出了苗头，而不是等到进度真正滞后才被动救火。今后我会继续在资源投入的量化监控上下功夫，让偏差在萌芽阶段就被识别出来。