ONEPSOFT | 软考学习知识库
2023 年 1 月,我作为承建方项目经理主持了晋中某地市域网格化社会治理平台建设项目。建设单位为该地区城市管理主管部门,合同额 536.04 万元,建设周期 9 个月,团队 20 人。平台基于低代码平台、微服务网关、OceanBase 数据库与 RocketMQ 消息中间件构建,前端为 Vue3 与 ECharts,覆盖网格事件采集、智能分派、协同处置、督办核查与考核评价五类业务,服务全市 1876 名专兼职网格员与 42 家职能部门。项目面临办理高峰时段并发压力大、存量老系统接口文档缺失致改造边界难以厘清、网格员信息化基础薄弱三大难点。本文按题目设问分节论述:先概述项目情况与我承担的工作,包括我在项目初期为沟通活动分配时间与预算资源的做法;再论述沟通管理的规划沟通管理、管理沟通、监督沟通三个过程,其间运用流程图、五问法与数据分析支撑决策;最后论述干系人管理的四个过程并给出一份具体的干系人管理计划。项目于 2023 年 9 月通过验收,平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日,数据自动核验比例由 42% 提升至 91%,设备在线率由 83% 提升至 98.5%。
一、我参与管理的项目概况及承担的工作
该地区自 2019 年推行网格化管理,将建成区划分为 1243 个基础网格,但事件流转长期依靠电话加微信群,存在三类突出问题:事件上报后无回告,网格员不知道办没办;跨部门事件靠人情协调,平均办结需 3.5 个工作日;考核数据靠人工汇总,月底集中补录。建设单位据此立项,目的是建成 " 一网统管 " 的市域网格化社会治理平台,实现事件从采集到结案的全链路闭环与全过程留痕。
项目于 2023 年 1 月启动,9 月完成终验,周期 9 个月,合同额 536.04 万元。建设内容包括五个业务子系统、与既有城管执法、12345 热线、视频监控三套存量系统的接口改造、网格员移动端 App,以及配套的数据迁移与培训。组织上采用项目型结构,团队 20 人,其中我方 15 人(需求 3 人、开发 8 人、测试 2 人、实施 2 人),建设单位与三个试点区抽调业务骨干 5 人参与需求确认与验收。交付成果包括平台软件、移动端 App、三类接口、《需求规格说明书》《测试报告》《操作手册》《运维手册》等五类文档,以及面向 1876 名网格员的分批培训和 6 个月运维服务。我担任项目经理,负责计划编制、范围与进度管控、干系人协调与验收组织。
本项目干系人层级跨度极大,从建设单位分管领导到社区兼职网格员共九个层级,且 42 家职能部门彼此并无隶属关系,仅靠行政指令难以推动。鉴于此,我在编制项目管理计划时就把沟通当作一项需要投入的正式工作来对待:进度上将三区试点座谈、分批集中培训、接口方联席会设为独立工作包排入网络图,合计 31 个人日,同时锁定每周五下午为固定沟通时段、不得被开发任务侵占;成本上在预算科目中划出 14.8 万元专项,涵盖场地、印刷、通信与差旅,约合同额 2.8%,并规定专款专用。正因为工期与经费都提前留足,后期赶工时这部分工作才没有被第一个牺牲掉。
二、我对项目沟通管理过程的认识与实践
所谓沟通管理,指的是为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、监督和最终处置所需的各个过程,它包含规划沟通管理、管理沟通、监督沟通三个过程。
在规划沟通管理中,我要基于干系人的信息需求和可用的组织资产制定沟通方式与计划。项目启动第二周,我组织建设单位信息科、三个试点区网格中心负责人与我方需求组长开展调研,先用流程图把事件的完整链路画了出来:从网格员 App 上报,经网格中心初审、智能分派、部门签收、现场处置、结果回填、网格中心核查,到最终结案共七个信息交接点。绘制过程中我们发现了三处信息断点——部门签收后无节点告知上报人、处置超期后无自动提醒、核查不通过后退回原因不回传网格员。这三处断点恰恰是网格员长期抱怨 " 报了没下文 " 的症结。据此,沟通管理计划不再按部门罗列,而是按这七个交接点逐点明确信息内容、发送方、接收方、渠道、时限与升级路径,并规定断点处必须补齐系统自动回告。计划经建设单位签字确认后与项目管理计划一并发布。
在管理沟通中,我要确保信息按计划及时收集、生成、发布并妥善处置。执行阶段最棘手的是存量系统接口改造。三套老系统建设年代不同、接口文档缺失,改造边界始终扯不清,联调会开了三次仍无结论,三方各执一词。我没有继续开会,而是采用五问法追查症结:一问为何联调无法推进,答曰双方对字段口径理解不一致;二问为何理解不一致,答曰没有书面依据,全凭口头约定;三问为何没有书面依据,答曰原厂已撤场、文档缺失;四问为何缺文档还能上线,答曰当年由运维人员按经验维护;五问为何不能重新确认,答曰无人愿意为口径承担责任。根因清楚了——不是技术问题,而是责任界面未书面化。我随即推动建设单位牵头召开联席会,形成《接口责任界面确认书》,逐字段列明提供方、字段含义、更新频率、异常处置责任人,由三方运维负责人与建设单位信息科四方会签。此后接口联调在两周内全部完成,未再发生扯皮。
在监督沟通中,我要监督并调整沟通活动以确保满足干系人的信息需求。我要求所有沟通渠道产生可统计的数据,并按月开展数据分析:统计通知触达率、回执率、事件回告及时率、培训后测评合格率四项指标。首月数据显示,事件回告及时率仅 67%,且集中在三个远郊区县;进一步按网格员年龄段分组分析发现,50 岁以上网格员的 App 回告及时率仅 41%,明显低于其他年龄段。据此我们采取了两项措施:一是在 App 中增加语音回告与一键结案功能,二是对该群体安排一对一帮扶培训。第三个月复测,事件回告及时率提升至 94%,50 岁以上群体达到 89%。全项目累计开展数据分析 9 轮,形成沟通改进措施 17 项。
三、项目干系人管理过程与本项目的干系人管理计划
所谓干系人管理,指的是识别能影响项目或受项目影响的人员与组织,分析其期望与影响,并制定策略促进其有效参与的一系列过程,包含识别干系人、规划干系人参与、管理干系人参与、监督干系人参与四个过程。它与沟通管理相辅相成:沟通管理解决信息怎么流转,干系人管理解决态度怎么转变。
在识别干系人中,我通过组织结构图分析、文件分析与专家判断,识别出干系人 11 类共 318 名代表,记录其岗位、诉求、影响力与当前态度,形成干系人登记册。在规划干系人参与中,我采用权力利益方格与参与度评估矩阵,标注各方当前参与度与期望参与度的差距,形成干系人管理计划。在管理干系人参与中,最突出的矛盾来自 42 家职能部门中的六家,他们认为平台会 " 把责任固化到部门头上 ",因而消极对待;我的做法是与建设单位协商,在系统中增加 " 分派异议申诉 " 与 " 多部门协同处置 " 两类流程,让确非本部门职责的事件有正当退出通道,同时在考核规则中把协同处置计入正向分值,六家部门的态度由抵制转为配合。在监督干系人参与中,我按月更新参与度评估矩阵,共触发策略调整 5 次。
干系人管理计划(节选)
| 干系人 | 分类 | 当前参与度 | 期望参与度 | 主要诉求 | 参与策略与措施 | 频率 | 责任人 |
|---|---|---|---|---|---|---|---|
| 建设单位分管领导 | 权力高利益高 | 中立 | 领导 | 按期上线、考核数据可信 | 月度汇报会+书面月报,重大事项即时呈报 | 每月 | 项目经理 |
| 市网格化管理中心 | 权力高利益高 | 支持 | 领导 | 事件闭环率、结案标准统一 | 每周专题例会+需求确认签字 | 每周 | 需求组长 |
| 42 家职能部门联络员 | 权力中利益高 | 抵制(6 家) | 支持 | 不愿责任固化 | 增设分派异议申诉与协同处置流程,协同计入正向考核 | 每两周 | 项目经理 |
| 三个试点区网格中心 | 权力中利益高 | 中立 | 支持 | 操作不增负担 | 试点先行+现场驻点+纪要回执 | 每周 | 实施经理 |
| 一线网格员 | 权力低利益高 | 不支持 | 支持 | 年龄偏大、不会操作 | 语音回告与一键结案功能、一对一帮扶培训 | 每月 | 实施组 |
| 存量系统运维方 | 权力低利益中 | 中立 | 中立 | 不愿为老接口担责 | 接口责任界面确认书四方会签 | 按里程碑 | 架构师 |
四、心得体会
项目于 2023 年 9 月通过验收并全面上线。平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日,数据自动核验比例由 42% 提升至 91%,设备在线率由 83% 提升至 98.5%,事件回告及时率稳定在 94% 以上,干系人满意度测评为 9.2 分。
回顾全程,我有三点体会。第一,沟通资源必须在项目初期以工期和预算的形式硬性落实。本项目把 31 个人日与 14.8 万元单列出来,才使三轮试点座谈与分批培训在赶工压力下没有被砍掉,而这些恰恰是网格员愿意用系统的前提。第二,沟通计划应当围绕信息流转的交接点来编制,而不是围绕组织架构来罗列。流程图揭示的七个交接点与三处断点,使计划直接对准了真实的信息淤积处,这比 " 每周一封邮件 " 式的计划有效得多。第三,很多看似技术性的僵局,根子在沟通的责任界面不清。接口改造之所以拖了三次会议,五问法追到底是文档缺失导致无人担责,一份四方会签的确认书就化解了;如果一味在技术层面加派人手,问题只会更僵。
这三点都指向同一个判断:把沟通做实,靠的是机制而不是热情。至于本项目的教训,主要是我在规划阶段只按组织层级划分了沟通对象,忽略了年龄结构这一实际影响信息接收的变量,直到第一轮数据分析才被动发现。今后我会在编制沟通管理计划时,把使用者的年龄、岗位负荷、终端条件等特征一并纳入分组依据。