024_粤北某区县级公证业务办理系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

2024 年 8 月，我作为承建方项目经理主持了粤北某区县级公证业务办理系统建设项目。建设单位为该地区公安司法主管部门，合同额 786.32 万元，建设周期 6 个月，团队 19 人。系统采用服务网格 Istio、多活容灾架构、GaussDB 数据库与分布式缓存，前端使用 Vue3 与国产浏览器内核适配组件，覆盖申请受理、材料审核、承办出证、收费结算、远程视频公证与电子档案六类业务。项目有三个突出难点：公证处日常办理不能中断，现场改造须与在线业务并行；工期仅 6 个月且验收时点受年度考核刚性约束；国产化替代要求数据库与中间件整体适配。三个难点都直接指向范围——边界划不清则不敢动工，范围排不开则赶不上验收，适配范围藏在暗处则中途爆量。本文以这三个难点为纲，逐一说明我如何运用范围管理的六个过程加以化解，给出核心范围对应的需求跟踪矩阵与分解至五层的 WBS，其间运用逐项检查、散点图与根本原因分析支撑判断。项目于 2025 年 2 月按期验收，线上办理率由 51% 提升至 93%，公证费结算差错实现连续 12 个月零发生，业务差错率由 2.7% 下降至 0.3%。

一、项目概况与我的职责

该区公证处年办证量约 2.6 万件，此前依靠单机版办证软件加纸质卷宗运转，存在三类突出问题：申请人须到场多次、线上办理率仅 51%；收费与出证分属两套台账，对账依赖人工，差错时有发生；卷宗全部纸质存放，调阅一件平均耗时 40 分钟。建设单位据此立项，要求建成覆盖全流程的公证业务办理系统，并同步完成国产化环境迁移。我方于 2024 年 7 月中标，我被任命为项目经理，负责范围、进度、质量、成本与干系人管理，团队 19 人，含需求 3 人、开发 10 人、测试 3 人、实施 3 人。交付成果包括六个业务模块、与不动产登记、市场监管、人口信息三类外部数据源的查询接口、历史卷宗数字化服务、国产化环境部署，以及操作手册、运维手册等五类文档与三个月的驻场支持。

二、难点一：业务不能中断，范围边界从哪里划

公证处每个工作日受理约 110 件业务，窗口一旦停摆即产生实际的社会影响，因此建设单位在需求座谈中反复强调 " 新系统上线前老流程一件都不能耽误 "。这句话看似是进度约束，实质是范围问题：哪些工作必须在建设期完成、哪些属于运维期、哪些根本不该由本项目承担，如果不在开工前定清楚，后续每一次现场协调都会演变成加需求。

为此我首先完成规划范围管理，即编制说明将如何定义、确认和控制项目范围与产品范围的文件。依据项目章程与招标文件，我组织建设单位办公室主任、两名资深公证员、我方需求组长与架构师召开三次专题会，在范围管理计划中明确了三条硬规则：产品范围以双方签字的《业务事项清单》为准；凡涉及现场施工影响窗口办理的工作，一律安排在非办公时段并事先书面报备；确认范围采取按业务模块分批预验收、整体终验的方式。

随后开展收集需求，即为实现项目目标而确定、记录并管理干系人需要和需求的过程。我采取的主力方法是逐项检查：由需求组会同两名公证员，把公证处正在使用的全部 47 类业务表单、23 项收费项目、16 个审批环节逐条列表，对每一项标注 " 保留原样 "" 线上化改造 "" 合并简化 "" 不纳入本期 " 四种处置意见，逐条会签。这项工作耗时 9 天，却换来了极高的确定性——第 16 项 " 涉外公证认证转递 " 因依赖上级机构的外部系统尚未开放接口，被明确标注为 " 不纳入本期 " 并写入除外责任；第 31 项 " 遗嘱保管登记 " 因涉及实体保管柜改造，被划入建设单位自行实施范围。逐项检查共收集需求 214 条，其中核心范围需求 56 条，全部登记入需求文件与需求跟踪矩阵。正因为边界在开工前逐条落定，整个建设期现场施工与日常办理并行推进，未发生一次因范围争议导致的窗口停摆。

三、难点二：工期仅六个月，范围如何排得开

本项目自合同签订到法定验收时点只有 6 个月，而需求侧的 214 条需求若照单全收，按初步估算需要 9 个月。范围必须被有序压缩而不是被随意砍掉，这依赖定义范围与创建 WBS 两个过程。

定义范围是制定项目和产品详细描述的过程。我组织了两轮引导式研讨会，运用多准则决策分析，按 " 法定必办、影响验收指标、业务频次、实现成本 " 四个准则对需求加权排序，形成项目范围说明书。说明书明确了产品范围描述，即六个业务模块与《业务事项清单》所列的 39 类可线上办理事项；明确了可交付成果、验收标准（含线上办理率不低于 90%、收费与出证台账自动勾稽、页面响应不超过 2 秒、国产化环境下全功能可用）；并列明除外责任，包括涉外认证转递、实体保管柜改造、第三方数据源自身的改造与硬件采购。八类使用频次低于全年 200 件的事项被明确移入二期，这一决定因有加权排序作依据而顺利通过评审。

创建 WBS 是把可交付成果与项目工作分解为较小、更易管理的组件的过程。分解时我着重把握两点：一是遵循 100% 原则，把项目管理、系统研制、国产化适配、数据迁移、部署实施、验收交付六项作为第二层平级分解，而不是把项目管理挂在系统之下，避免出现管理工作无处归属的结构缺陷；二是全程使用统一的自上而下层级编码，各层编码严格继承上一层前缀。最终 WBS 共五层、含工作包 183 个，并编制了 WBS 词典。需要说明的是，WBS 本身是分级的可交付成果层级结构，下文以表格呈现只是展示载体，并非 WBS 的结构类型。

WBS 完成后，我用散点图对分解质量做了一次校验：以每个工作包的估算工时为横轴、以首月实际发生工时为纵轴作图，绝大多数点位落在四十五度参考线附近，但国产化适配类的 11 个工作包明显整体偏离在参考线上方，实际工时普遍为估算值的 1.6 至 2.1 倍。这一发现促使我提前介入难点三，而不是等到偏差累积到不可挽回时才处理。

四、难点三：国产化适配的隐性范围如何显性化

散点图暴露的偏离并未随时间自行收敛。我随即召集架构师、数据库工程师、中间件工程师与建设单位信息科开展根本原因分析：先确认问题现象为 " 适配类工作包工时普遍超支且反复返工 "，再沿因果链逐层追问。第一层原因是适配工作量被低估；继续追问，是因为估算时只考虑了数据库语法替换，未考虑存储过程重写、分页语法差异与国产浏览器内核下的前端兼容；再追问为何未考虑，根因指向两点：一是招标阶段的国产化要求仅表述为 " 适配国产数据库与中间件 "，未细化到具体版本与组件清单，范围描述本身含糊；二是团队缺少同类适配的基线数据，估算依据不足。

根因清楚后，处置就有了方向。在控制范围这一监督项目和产品范围状态、管理范围基准变更的过程中，我采取了三项动作：其一，会同建设单位把 " 适配 " 逐条拆解为数据库对象适配、存储过程重写、中间件参数调优、浏览器内核兼容、操作系统与国密组件适配五个明细项，形成《国产化适配范围确认单》并双方会签，把隐性范围显性化；其二，就其中超出原范围描述的存储过程重写与浏览器兼容两项提出正式变更请求，经变更控制委员会审议，以 " 二期实现三类低频报表的适配、本期集中保障 39 类事项全功能可用 " 的方式收敛，同步更新范围基准、需求跟踪矩阵、WBS 与进度计划；其三，建立每周范围偏差通报，将新增变更请求数与已批准变更工作量占比两项指标纳入周报。全项目共受理变更请求 29 件，批准 14 件、拒绝 11 件、合并 4 件，获批变更累计工作量占原基准的 5.8%，控制在合同允许的范围内。

五、确认范围与项目成效

确认范围是正式验收已完成的项目可交付成果的过程。我按计划采取分批预验收：每个模块完成内部测试后，即组织公证员依据需求跟踪矩阵逐条核对，采用检查与投票决策确认。收费结算模块预验收时，公证员提出票据打印格式与财政票据规范不符，我对照矩阵判定其属于已确认需求 R-04 的实现偏差而非新增需求，纳入缺陷修复，两日内完成整改。六个模块全部通过后，2025 年 2 月组织整体终验，一次性通过。

系统上线后，线上办理率由 51% 提升至 93%；收费与出证台账实现自动勾稽，公证费结算差错连续 12 个月零发生；因材料预校验与数据源自动核验的引入，业务差错率由 2.7% 下降至 0.3%；卷宗调阅由平均 40 分钟缩短至即时检索。

六、心得体会

第一，范围边界越早逐项落定，后续的自由度越大。本项目在开工前用 9 天做完 47 类表单的逐项检查，看似慢，实则换来了建设期内现场施工与业务办理并行而无争议，这 9 天是最划算的投入。第二，范围压缩必须有可解释的准则。八类低频事项之所以能顺利移入二期，靠的不是项目经理的坚持，而是 " 法定必办、影响验收指标、业务频次、实现成本 " 四准则加权排序给出的可复核依据。第三，含糊的范围描述是最危险的隐性风险。招标文件中一句 " 适配国产数据库与中间件 "，在实施中裂变为五个明细项，若不通过根本原因分析把它显性化并走正式变更，工时黑洞会一直吞噬项目。第四，范围管理无法孤立开展：WBS 是进度与成本估算的共同输入，变更评估须联合进度管理研判关键路径、联合风险管理评估二次风险，公证员对新系统的接纳则依赖干系人管理提前介入。

不足之处在于，投标与估算阶段未针对国产化适配建立基线数据库，导致初始估算严重偏低。项目结束后我已牵头把本项目五个适配明细项的实际工时沉淀为公司的估算基线，供后续同类项目在定义范围阶段直接引用。

表 1 核心范围需求跟踪矩阵（摘录）

编号	需求描述	业务需求／目标	项目目标	WBS 可交付成果	产品设计	产品开发	测试用例	状态
R-01	在线申请与材料预校验	减少申请人到场次数	线上办理率≥90%	1.2.1 申请受理模块	表单向导、必备件校验规则	受理服务	缺件拦截、重复申请识别	通过
R-02	三类外部数据源自动核验	材料真实性由人工判读转为自动核验	业务差错率≤0.5%	1.2.2 数据核验模块	接口编排、核验留痕	核验服务与适配器	接口超时降级、留痕完整性	通过
R-03	承办出证与审批留痕	办证过程全程可溯	出证环节留痕率 100%	1.2.3 承办出证模块	审批链配置、电子签章	工作流引擎	越级审批拦截、签章有效性	通过
R-04	收费与出证台账自动勾稽	消除人工对账差错	结算差错零发生	1.2.4 收费结算模块	票据规范、勾稽规则	结算服务	票据格式、日结月结对账	通过
R-05	远程视频公证	特殊群体免于奔波	远程办件占比≥15%	1.2.5 远程视频模块	身份核验、音视频存证	视频服务	弱网重连、存证可回放	通过
R-06	电子档案与卷宗检索	调阅由 40 分钟降至即时	检索响应≤2 秒	1.2.6 电子档案模块	元数据模型、全文索引	档案服务	大卷宗检索、权限隔离	通过

表 2 WBS 分解（五层，摘录；表格仅为展示载体）

层级	编码	名称
第 1 层	1	粤北某区县级公证业务办理系统项目
第 2 层	1.1	项目管理
第 2 层	1.2	系统研制
第 3 层	1.2.1	申请受理模块
第 4 层	1.2.1.1	在线申请功能
第 5 层	1.2.1.1.1	申请表单向导设计与开发
第 5 层	1.2.1.1.2	必备件校验规则引擎开发
第 5 层	1.2.1.1.3	申请模块单元测试
第 4 层	1.2.1.2	窗口受理功能
第 5 层	1.2.1.2.1	叫号与预约对接开发
第 5 层	1.2.1.2.2	受理回执打印开发
第 2 层	1.3	国产化适配
第 3 层	1.3.2	数据库适配
第 4 层	1.3.2.1	存储过程重写
第 5 层	1.3.2.1.1	存量存储过程清点与分级
第 5 层	1.3.2.1.2	高频存储过程重写与回归
第 2 层	1.4	数据迁移与卷宗数字化
第 2 层	1.5	部署实施与培训
第 2 层	1.6	验收交付

表 3 范围变更处置统计

变更来源	提出	批准	拒绝	合并	主要处置依据
国产化适配明细	11	7	2	2	是否影响 39 类事项全功能可用
公证员使用侧	10	4	5	1	是否属基线内实现偏差
外部数据源方	5	3	1	1	是否属除外责任
我方内部优化	3	0	3	0	不影响验收标准者不予变更