ONEPSOFT | 软考学习知识库
一、我参与管理的项目概况及本人承担的工作
浙东某经济开发区内有四条成规模的商业街区,入驻商户逾八百家。过去开发区判断商圈冷热、调整招商结构、确定租金档位,靠的是商户自报营业额加上管理人员实地走访,数据滞后、口径不一,招商决策常常凭经验拍板。为了让运营决策有客观依据,该商贸集团数字化中心于二〇二一年三月发起建设浙东某经济开发区商圈客流分析平台,由我所在单位承建,合同额四百二十五万元,建设周期十三个月,二〇二二年四月通过验收交付。
平台交付四个子系统与一套硬件采集网络:四个子系统为客流采集与识别、商圈热力分析、商户经营画像、运营决策支持;采集网络包含布设于各出入口和主动线的一百二十六个视频采集点位和四十二组无线探针。全部交付成果共六类,分别是系统软件与部署包、源代码及接口文档、数据治理规则库、点位图与验收报告、运维手册、培训材料。技术上,服务间通过服务网格 Istio 完成流量治理与故障隔离,数据层选用 GaussDB 并以分布式缓存支撑高频热力查询,整体按多活容灾架构部署以保障连续可用;前端使用 Vue3 与 TypeScript,后端基于 Java 17 与 Spring Boot,应用中间件采用东方通 TongWeb,运行于政务云信创环境,安全防护按网络安全等级保护第三级建设。项目为矩阵型组织,团队十二人,我担任项目经理,负责总体计划与交付,其中投入精力最多的正是资源的估算、调配与盯守。系统上线后,数据自动核验比例由百分之四十二提升至百分之九十一,系统可用率稳定在百分之九十九点九以上,全年重大故障零起,业务差错率由百分之二点七下降至百分之零点三。
这个项目的资源难题不在总量而在结构。其一,历史客流与商户经营数据来自多个源头,质量参差,治理规则难以统一,数据岗位被长期占用;其二,识别算法在强光、逆光和雨雾天气下表现不稳定,调优要投入多少人力事先谁也说不准;其三,参与集成的第三方厂商水平不齐,集成测试反复返工,把联调环境和测试人员的档期一拖再拖。三重压力叠加,让资源管理成为本项目最需要经营的一块。下面我按题目设问依次作答。
二、资源管理的过程
所谓项目资源管理,指的是识别、获取并管理项目所需的各类资源,以保障项目按目标完成的一整套工作,它由规划资源管理、估算活动资源、获取资源、建设团队、管理团队、控制资源六个过程构成。这六个过程在本项目中不是孤立执行的,我把它们串成了三步:先算得准,再拉得来,最后稳得住。
第一步,算得准,落在规划资源管理和估算活动资源上。 项目一启动,我便约集团人力部门、开发区物业方和采购部门坐到一起,把资源这件事先说清楚。产出的资源管理计划回答了四个问题:资源怎么识别、从什么渠道拿、由谁负责、什么时候释放;同步签署的团队章程则约定了值班安排、决策权限和分歧处理的规矩。角色分工上,我按四个子系统加一套采集网络确定五名模块责任人,再用责任分配矩阵把关键活动落到具体角色,保证每项活动的最终负责人有且仅有一人。
| 关键活动 | 算法工程师 | 数据治理岗 | 集成工程师 | 测试负责人 | 现场实施 |
|---|---|---|---|---|---|
| 识别模型调优 | A | C | I | R | I |
| 治理规则库建设 | C | A | I | R | I |
| 第三方接口集成 | I | C | A | R | I |
| 点位勘察与布设 | I | I | C | I | A |
注:A 为最终负责,R 为具体执行,C 为需咨询,I 为需知会。
算量的环节最容易出偏差,尤其是算法调优。我没有让工程师凭感觉报数,而是把这项工作拆成场景勘察、样本采集、样本标注、模型训练、现场实测五项活动,逐项估工时、估设备,再逐层归集到工作包和整个项目;随后又拿本单位以往做过的两个视频分析类项目做参数比对,两条路子给出的数字相差不到一成,我才把结论定下来。最终这一块需要算法工程师两名、标注支持三人月、图形计算服务器两台,以及夜间实测用的照明辅具与车辆若干。这些结论连同其他工作包的口径,一并落进了资源分解结构和资源需求文件。
第二步,拉得来,落在获取资源和建设团队上。 设备侧,采集终端与训练服务器通过比选采购获得。吸取识别准确率不稳定的教训,我在比选条件里加了一条硬杠杠:投标方必须提交强光与雨雾条件下的第三方实测报告,没有报告一律不进入下一轮。设备到货后逐台清点接收,编号登记进设备台账,做到账实对得上。人员侧,集团提前分派了一名视频算法方面的资深工程师,标注这类阶段性用工则通过短期外部协作补齐;后期算法专家因集团另一处业务需要不能常驻现场,我随即改用远程协作加固定评审窗口的方式保住其深度参与,并指定一名工程师做现场对接与信息接收。队伍拉起来只是开头,能不能打仗还得靠养。我把每月最后一个工作日定为复盘日,让踩过坑的人讲坑,让攻下难题的人讲法子,同时把攻关贡献写进月度认可名单公开表扬并给予相应奖励。三个月下来,团队处理同类缺陷的平均耗时明显缩短,人心也拢得更紧。
第三步,稳得住,落在管理团队和控制资源上。 集成阶段矛盾最集中:测试组和第三方厂商为返工责任互相推诿,团队内部也因加班分配不均憋着情绪。我的处理办法是不回避、摆事实、共同求解——先把每一次返工的事实过程还原清楚,再重新划定接口责任边界,把值班轮次调匀,同时对第三方交付物开展了两次质量审计,核查代码规范执行、单元测试覆盖率和缺陷闭环情况,共开出不符合项十四项并限期整改复核,从源头削减返工。设备与环境这一侧,我按周核对实际占用与计划的差距。第七个月发现联调环境几乎被返工吃满,我调出近三个月的返工工单共九十六条,按成因归类做成帕累托图,发现接口定义不一致与测试数据失真两类合计占比接近八成。对症下药:接口契约统一归口并版本化管理;清洗后的历史数据引入统计抽样把关,按数据来源和时间段分层随机抽三百条人工逐条比对,准确率达标才准许进入联调。两招之后,环境占用回落到计划水平,项目重新回到节奏上。
三、实物资源和人力资源在资源获取和管理控制方面的不同
上面六个过程同时管着两类资源,但这两类资源的脾气差得很远,把它们当成一回事,正是许多项目资源失控的起点。结合本项目的教训,我认为差别集中在下面几处。
其一,来源和挑选的办法不一样。设备、材料、场地这类实物,靠采购、租赁或者内部调拨就能拿到,挑选时看参数、看价格、看交货期,标准摆在明面上,打分记录可以留档复查。人不一样,人是靠预分派、谈判、招募或者组建虚拟团队争取来的,除了技能和履历,还得掂量对方愿不愿意投入、能腾出多少时间、跟现有团队合不合得来,这些东西很难量化,靠的是沟通和谈判的功夫。本项目买识别设备,凭一份实测报告当场就能拍板;争取那位算法专家的档期,我却前后谈了四轮。
其二,能不能换、好不好补不一样。实物大多是标准化的,同规格产品彼此可以顶替,缺了加钱加量就能补上。人身上带着经验和默契,一个熟悉商圈业务口径的骨干走了,接手的人纵然技能相当,也得花不短的时间摸清门道。所以对关键岗位必须提前备份、提前带教,对关键设备只需盯住供货渠道就够了。
其三,花钱的方式不一样。实物多是一次性投入并形成资产,闲置的损失相对有限,用完还能归还或者转作他用;人却是按时间连着计费的,到岗却没活干是纯粹的浪费。这就决定了排班和任务衔接的精细程度,直接写在人力成本的账单上。
其四,盯住它们靠的东西不一样。盯实物靠的是台账、盘点、损耗统计和使用率分析,本项目用的抽样核验、返工归因都属于这一路,看的是数量够不够、状态好不好、用得值不值,本质上是让数据说话。盯人靠的是绩效反馈、分歧疏导、认可激励和带教辅导,看的是干得怎么样、劲头足不足、配合顺不顺,本质上考验的是领导力。
其五,出了问题的样子和补救的路子不一样。实物出问题表现为缺货、损坏、参数不符,补货、维修、更换就能解决,见效快、结果可预期。人出问题表现为效率下滑、质量起伏、摩擦增多,成因往往是能力、动机、关系搅在一起,换个人通常不解决问题,甚至把局面搞得更僵,只能靠谈心、调职责、改激励一点点疏通。正因为两者的差别到了这个程度,标准过程才把实物资源的日常盯守单独放在控制资源里,而把人的表现与关系交给管理团队来处理,这一分工不是文字上的讲究,而是两类资源本性使然。
四、心得体会
本项目按期通过验收并稳定运行至今。回头看,资源管理最考验项目经理的地方,是能不能同时用好两套完全不同的思路:对物要精细核算、拿数据说话;对人要将心比心、用信任换投入。这两件事分开对待、各用其法,资源才能真正变成交付能力。今后我打算在人员技能画像和设备调度可视化上再往前走一步,让资源配置从凭经验判断,转到靠数据支撑。