088_闽南某省会城市银行网点智能排队系统信息系统项目综合管理

ONEPSOFT | 软考学习知识库

---

闽南地区某省会城市的银行网点数量多、客流量大，高峰时段客户排队时间长，老年客户操作自助设备困难，网点客流与柜面资源调配靠人工经验，涉密与敏感数据又多，系统建设要求高。为提升客户体验与网点运营效率，该金融机构科技部于 2022 年 1 月发起了银行网点智能排队系统信息系统项目，经公开招标由我司承建，合同额 480.16 万元，建设周期 6 个月，我担任项目经理，负责项目全过程管理。6 个月的建设周期对银行系统而言相当紧张，既要保证涉密数据安全，又不能影响网点正常营业，范围划得越清楚，执行起来越从容。

项目建设目标是整合网点客流与排队数据，实现智能取号、动态分流与客流预测。建设内容包括号票与排队叫号、客流预测与分流、预约管理、终端展示与广告、统计分析与报表五个模块，并与网点核心业务系统、叫号终端及门禁设备对接。技术方案采用服务网格 Istio 统一治理微服务调用与灰度发布，整体部署为同城双中心多活容灾架构，数据库选用 GaussDB，热点数据由分布式缓存承载；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件采用东方通 TongWeb，系统运行在银行私有云信创环境，按等级保护三级完成安全建设。项目团队共 15 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 7 人、测试工程师 2 人、实施工程师 1 人、质量保证 1 人。项目于 2022 年 7 月通过终验，上线后识别准确率达到 94.6%、误报率控制在 3% 以内，用户满意度测评由 78 分提升至 94 分，月度报表出具时间由 5 天缩短至 4 小时。

范围管理决定项目做且只做哪些工作。这个项目周期短、网点多、老系统接口情况复杂，范围划得清不清，直接决定后面六个月的节奏，范围管理在这里不是纸面功夫，而是每天都要对照的标尺。下面我按规划范围管理、收集需求、定义范围、创建 WBS、确认范围、控制范围六个过程，结合项目实践说明范围管理是如何开展的。

一、规划范围管理

规划范围管理要回答范围工作按什么规矩运转的问题，产出范围管理计划与需求管理计划，为后续五个过程提供指南。我依据项目章程与合同，组织需求分析师与骨干开发共同编制了这两份计划，明确了范围说明书的编制要求、WBS 的分解层级、确认范围的验收组织方式与控制范围的变更流程，以及需求收集渠道、优先级评定方法与追溯矩阵的维护要求。考虑到 6 个月工期紧张，计划中明确了一条原则：涉密数据的处理范围以既有合规要求为准，不做扩展性设计。两份计划经科技部与我司分管领导确认后执行。

二、收集需求

收集需求要把干系人的期望变成可记录、可追溯的需求条目，产出需求文件与需求跟踪矩阵，为定义范围打基础。我们先后访谈了网点运营部、柜面主管、大堂经理、老年客户代表与信息科技部，共整理出原始需求 167 条。访谈之外，我们还到两个代表性网点现场蹲点观察了高峰时段的排队情况，把观察到的痛点转化为需求条目。为避免遗漏，我用检查表按六个维度逐项排查：业务运营、客户体验、合规安全、终端配套、数据接口、运维支持，每个维度下细分到具体岗位，逐格打钩确认，不能确定的标注待核并限期落实。检查表把想到谁算谁变成了照单排查，第一轮就发现两类容易忽略的需求：一是残障人士的无障碍取号，二是网点断网时号的本地缓存。经确认的需求文件与需求跟踪矩阵随后作为定义范围的输入。

三、定义范围

定义范围要把项目边界与验收标准写成文件，产出项目范围说明书，让边界可核对。我牵头编制《项目范围说明书》，对边界逐一写明：项目范围即建设号票排队、客流预测、预约管理、终端展示、统计分析五个模块，完成与网点核心业务系统及叫号终端的对接；交付成果包括各子系统、接口联调报告、性能测试报告与运维手册；验收标准写明识别准确率不低于 94%、取号响应时间不超过 1 秒、报表 4 小时内自动生成等；除外事项列明不包含网点装修改造、叫号硬件的重新采购与历史客流数据的清洗。说明书还写明了假设条件，例如各网点叫号终端型号以现状为准，不做统一更换，这一假设避免了设备改造被悄悄塞进范围。说明书经科技部逐条确认后发布，成为范围工作的基准。

四、创建 WBS

创建 WBS 要把可交付成果逐层分解到工作包，让范围可执行、可考核。结构上，第一层是五个模块，加上项目管理与集成测试两类支撑工作；第二层按功能拆分，第三层细化到可考核的工作包，遵守 100% 规则，并让单包工期落在 8 到 80 小时区间。例如客流预测与分流模块向下分解为数据采集、预测模型、分流策略、告警联动四个工作包，其中预测模型又按算法调参与离线训练细分。WBS 词典对每个工作包补充了负责人、验收标准与依赖关系，成为排程、估算与考核的统一参照。分解过程中我们邀请网点业务人员参与评审，确保工作包与业务场景一一对应。

五、确认范围

确认范围要请干系人正式验收可交付成果，把验收从口头认可变成书面记录，提高最终验收通过的把握。我们采取分阶段确认的方式，每完成一个模块就组织一次阶段验收。以客流预测模块为例，验收时邀请网点运营部、大堂经理与信息科技部到场，按检查单逐项核对预测准确率、分流建议的可用性与告警联动效果，并随机抽取三个高峰时段的历史数据做回放验证。对发现的预测偏差偏大的问题，我们当天登记、限期整改，一周后复核通过。阶段验收发现的共性问题，我们还汇总成问题清单，在下一模块验收前逐一销项，避免同类问题反复出现。全部模块确认完成后，各方签署了阶段验收报告。为控制验收成本，我们对分支网点的终端验收采用了分层抽样，按网点类型与终端型号分层抽取样本现场核对，用有限的精力覆盖了关键风险面。

六、控制范围

控制范围要盯住范围基准与实际工作的偏差，防止范围悄悄蔓延。项目执行中，网点运营部提出把广告投放管理也并入本期建设，在范围说明书中本就不在本次范围之内。我组织团队评估后向变更控制委员会提交了变更申请，说明该功能涉及广告素材审核与投放效果统计，工期与成本均不可控，建议列入二期。委员会采纳建议后，本期范围得以保持。为防范围悄悄扩张，配置管理员每周核对 WBS 与实际工作的对应，发现计划外工作立即登记追源。对项目中段出现的一批界面调整诉求，我用因果图围绕 " 变更请求增多 " 这一结果，从人员、流程、需求、环境四方面分析根因，发现多数诉求源于需求收集阶段对大堂经理操作习惯的了解不够，据此把界面易用性评审前置到需求阶段，后续变更数量明显回落。

七、结语

项目最终按期通过终验，识别准确率提升至 94.6%，满意度由 78 分提升到 94 分，月度报表由 5 天压缩到 4 小时。回顾整个过程，范围管理就是要把边界划清楚、把承诺写下来、把变更管起来：检查表让需求排查不漏项，范围说明书把边界写到可核对的粒度，WBS 让做且只做有了落点，分层抽样让确认范围兼顾了效率与严谨，因果图则让变更潮的根因浮出水面。六个过程环环相扣，缺了哪一环，验收时都会加倍偿还。项目交付后，这套范围管理的做法被沉淀为银行的合作模板，写进了后续同类项目的范围条款，也算是项目带给组织的额外价值。