274_川东某地市域信号控制与诱导一体化平台信息系统项目资源管理

ONEPSOFT | 软考学习知识库

---

2024 年 5 月，为提升市域路网通行效率、缓解早晚高峰拥堵，我所在公司中标川东某地市域信号控制与诱导一体化平台项目。建设单位为该地区交通运输主管部门，合同额 536.46 万元，工期 15 个月，我任乙方项目经理，团队 20 人，下设需求组 2 人、开发组 7 人、算法组 2 人、集成组 3 人、测试组 3 人、实施与培训 3 人。系统需覆盖信号自适应控制、干线绿波协调与出行诱导发布，技术栈采用服务网格 Istio 治理微服务、多活容灾保障连续性、GaussDB 承载路网主数据、分布式缓存扛并发查询。项目难点在于第三方厂商交付质量参差致集成测试反复返工、线下流程长期依赖纸质台账致数据初始化工作量巨大、算法识别在复杂光照与天气条件下准确率不稳定。

鉴于本项目涉及多厂商协同、算法与工程双线并行，我深刻认识到：资源管理是项目交付的基石，必须靠规划把资源种类数量摸清、靠获取把稀缺资源锁住、靠建设与控制把团队与实物盘活。本文按前期规划估算、中期获取资源、后期建设控制三阶段论述做法。

在前期阶段，需要先把 " 要什么资源、有多少 " 想清楚，这一工作被称为规划资源管理。我依据项目章程与范围基准，采用责任分配矩阵梳理了项目经理、算法负责人、各组组长的汇报与执行责任，制定了《资源管理计划》，明确采用矩阵型组织、内部调配与外包采购并举的获取渠道，并附人员培训与遣散方案。规划资源管理是定义如何估算、获取、管理和利用团队及实物资源的过程，其作用是在整个项目期间为资源管理提供指南。在估算活动资源时，我组织核心成员依据工作分解结构，采用自下而上估算量化人力与实物：团队资源拆为算法 2 人、开发 7 人、集成 3 人、测试 3 人等共 20 人；实物资源明确需配置信创 GPU 推理服务器 5 台、分布式缓存节点若干、第三方测评服务。为让层级一目了然，我构建了资源分解结构，其核心内容为两大层级——团队资源下分研发类（算法、前后端）、支撑类（集成、测试、实施）；实物资源下分算力设备（GPU 服务器）、信创硬件（缓存节点、终端）、第三方服务（等保测评、路况数据接入）。这张 RBS 后来成了获取与控制资源的精准地图，也让甲方在评审时一眼看清钱花在了哪类资源上。值得一提的是，正是 RBS 把 " 算力设备 " 单独拎出来，才让我们在后续获取阶段没有漏算 GPU 服务器的配套机柜与散热，少走了很多弯路。估算时我特意留出百分之十的余量应对厂商返工，事后证明这余量恰好兜住了最紧的那段工期。借助这张结构，我把原估的二十人团队逐岗落到资源分解结构的叶子节点，发现实施与培训组三人同时背初始化与现场两头，立刻在计划里把两人的职责切分，避免了上线期一个人被撕成两半的窘境。

在中期阶段，需要把规划中的资源真正落到项目上，这一工作被称为获取资源。本项目有两类典型稀缺资源。其一为兼具交通业务知识与 AI 工程能力的算法工程师，市场难以快速招募。我采用预分派与虚拟团队结合：投标阶段即要求方案锁定 2 名核心算法专家姓名与履历，规避 " 挂名换人 "；同时与高校交通实验室签合作协议，以远程协作引入研究生团队完成样本标注，突破本地人才瓶颈。有次暴雨天气样本极度稀缺、模型在雨天识别率骤降，正是靠虚拟团队里的研究生连夜补标了三百段雨雾视频，才把准确率拉回基线，这件事让我确信远程协作买的是弹性而非将就。虚拟团队最怕沟通断档，我专门设了每日站会与共享标注平台，把歧义控制在当天，没有让远程协作变成甩锅现场。其二为受供应链影响的信创 GPU 服务器。我采用多标准决策分析，建立涵盖信创兼容认证、算力指标、交货周期、全生命周期成本四维的评分矩阵，对主流信创服务器逐一比选，最终锁定综合最优方案并以框架协议固定供货节点，确保算力底座按期部署。考虑到信创设备交货普遍偏慢，我在合同里写死了最晚到货节点并约定逾期按日扣款，把供应链风险转回给厂商，而不是押注在自己催货上。预分派锁人、虚拟团队补人、框架协议锁货，这三招合起来，稀缺资源这道坎才算真正迈过去。为验证到货质量，我用统计抽样对到货的 5 台服务器做上电与压测抽检，发现 1 台散热不达标当即退换，避免了后期训练降频隐患。值得一提的是，抽样时我特意覆盖了不同批次，确保结论对整批到货有代表性，而不是只看一台样机就签字验收，这种 " 抽样不取巧 " 的习惯后来救了我们不止一次。

在后期阶段，需要让团队高效协作并盯紧实物余缺，这一工作被称为建设团队与控制资源。建设团队是提高工作能力、改善团队氛围以提升绩效的过程。面对算法与工程并行、厂商反复返工的压力，我用双周技术分享与阶段性团建推动团队由震荡期走向规范期，并以里程碑达成给予绩效认可，团队士气在第三个月明显回升。我还在团队里推行 " 问题认领制 "，谁发现的瓶颈谁牵头解决，既锻炼了新人也让老员工从救火里抽身做更难的事。控制资源是确保实物资源合理分配、及时识别缺乏或剩余的过程。为找出资源瓶颈主因，我用帕累托图统计了导致进度延误的各资源因素分布，发现 " 算法 GPU 算力不足 " 占四成、" 集成测试人力被厂商返工占用 " 占三成二，两类合计超七成，据此把备用算力优先倾斜算法组、并增派 1 名测试工程师专跟厂商返工。我把这张图贴在作战室，每周更新，让所有人看见资源到底卡在哪，而不是各凭感觉喊缺人。同时，我用质量审计检查了资源台账与培训记录的规范性，发现两处人员变更未书面报批，立即补流程堵漏。资源审计不是挑刺，而是给台账做体检，早发现问题比上线后救火便宜十倍。项目收尾时，原估算的缓存节点出现剩余，我及时登记闲置并移交甲方运维，避免了资源空转。有次算法组为赶模型训练私自占用集成组缓存节点，我靠资源台账的实时记录当场定位冲突，重新切片分配，既没耽误训练也没拖慢联调，这件事让团队都认同一句话：资源台账不是摆设，而是化解抢资源的裁判。

经过 15 个月建设，并发承载能力由 800 提升至 5000 用户在线，识别准确率达到 94.6%、误报率控制在 3% 以内，人工重复录入工作量下降 68%，系统顺利通过终验。回顾全程，资源管理不是简单的人数与设备清单，而是用规划摸清家底、用获取突破瓶颈、用建设控制盘活余缺。三个过程对应三阶段，靠责任分配矩阵、多标准决策分析、统计抽样、帕累托图与质量审计把资源决策从拍脑袋变成有据可依，这正是我把资源管理做实的体会。说到底，资源管理的核心是把有限的人与物精准匹配到关键路径，这十五个月走下来，这条线越扎越实。闭环的意义是让每一份资源都有始有终，而不是招进来就闲置，这一点我们做到了。把资源当成会流动的活水而非死清单，哪缺补哪、哪余收哪，项目才真正转得动。资源管理这门课，我最大的收获是学会 " 用结构代替混乱、用数据代替感觉 "，这十二个字比任何工具都管用。项目结束后，甲方把这套资源分解结构与获取策略要去做内部规范，说明这套打法经得起检验。我也把 " 前期规划估算、中期获取、后期建设控制 " 的三阶段写法沉淀下来，成了部门资源类论文的模板。往后带新人做资源类项目，我都会先让他们画一张资源分解结构，因为结构清楚了，后面的获取与控制才有抓手，否则全是眉毛胡子一把抓。