203_江苏某地市级非遗数字档案系统信息系统项目开发方法与生命周期绩效域

ONEPSOFT | 软考学习知识库

---

江苏地区某地市级的非遗档案管理长期依赖手工整理与纸质归档，非遗项目登记、传承人档案、影像资料、申报材料等环节分散在各区县文化部门与市文旅局手中，国产化替代要求数据库与中间件须整体适配，算法识别在复杂光照与天气条件下准确率不稳定，网络专线覆盖不全、偏远节点通信稳定性不足，非遗档案分散、数字化程度低。为把非遗档案业务数字化，该市文旅局于 2023 年 11 月发起了非遗数字档案系统信息系统项目，经公开招标由我司承建，合同额 1050.16 万元，建设周期 10 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合非遗档案全流程数据，实现项目登记在线化、影像资料数字化、申报材料规范化。建设内容包括项目登记、传承人档案、影像资料、申报管理、统计分析与报表五个模块，并与各区县文化部门及市文旅局对接。技术方案上，业务表单与流程依托低代码平台快速配置，微服务网关统一管理接口，业务数据存放于 OceanBase 数据库，消息通过 RocketMQ 异步推送，前端基于 Vue3 组件体系实现，后端以 Java 17 与 Spring Boot 编写，数据库与中间件按国产化要求整体适配，应用部署在市政务云信创环境，安全建设按等保三级实施。项目团队按矩阵型组织搭建，全队 20 人，其中需求分析 3 人、研发 9 人、测试 3 人、实施运维 4 人、数据治理 1 人，编制随模块规模动态调整，联调高峰期另调集厂商力量集中攻坚。项目于 2024 年 9 月通过终验，上线后跨部门数据共享接口调用量月均突破 120 万次，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日。

开发方法与生命周期绩效域解决的是项目用什么方法开发、按什么节奏交付的问题。这个项目适配重、识别不稳、网络不均，开发方法与节奏稍有失当，适配拖期、识别返工、节点掉线，项目必然受挫。10 个月的实践让我体会到，开发方法与生命周期管理本质上是一连串的权衡：方法选型要权衡、节奏排定要权衡、协同方式也要权衡。下面围绕三次关键权衡，结合项目实践说明开发方法与生命周期绩效域的落地过程。

一、权衡一：方法选型，在 " 一次成型 " 与 " 增量迭代 " 之间取舍

方法选型的权衡回答 " 用什么方法开发 "。非遗档案系统模块多、影像资料数字化工作量巨大，若用一次成型式开发，所有模块同时开工，联调风险集中、返工代价巨大；若用增量迭代，可以分批交付、分批验证，但需要更严格的需求管理。我们权衡后选择了增量迭代：把项目拆成四个迭代，每个迭代交付一组完整可用的功能。针对国产化适配任务重的问题，我们在第一个迭代就并行开展数据库与中间件适配，用因果图围绕 " 适配进度慢 " 从接口、环境、版本、人员四方面分析根因，定位到部分厂商的中间件版本与测试环境不一致，据此统一了适配测试环境，建立版本基线，整体适配一次通过。针对影像资料数字化工作量大的特点，我们把数字化任务拆进四个迭代分批完成，每批数字化完成并验证后再进入下一批，工作量被摊薄到整个周期，而不是集中在收尾突击。以影像资料为例，全市非遗影像资料超过两万条，我们按区县分批数字化，每批完成即抽验、抽验通过再进下一批，全程没有出现 " 年底突击、质量失控 " 的情况。方法选型的权衡，本质是用迭代的灵活性换取风险的分散，这个取舍在项目启动时做对了，后面就顺畅了。

二、权衡二：节奏排定，在 " 前紧后稳 " 与 " 均衡推进 " 之间取舍

节奏排定的权衡回答 " 按什么节奏交付 "。10 个月的建设周期，若全面铺开均衡推进，核心模块与边缘模块同节奏，容易 " 该快的没快起来、该稳的没稳下来 "；若前紧后稳，把核心模块前置，可以尽早验证核心价值。我们权衡后选择了前紧后稳：前六个月集中开发项目登记、传承人档案两大核心模块，尽早交付并验证；中间三个月做影像数字化与集成联调；最后一个月做性能优化与整体验收。针对算法识别在复杂光照与天气条件下准确率不稳定的问题，我们用控制图对每周的识别准确率持续监控：以连续数周数据建立基线，画出均值线与上下控制限，每周把实际准确率标注到图上，准确率连续低于控制限的周次，提前介入排查，发现是阴天场景的样本不足，据此补充了样本并调整了模型阈值，识别准确率由 86% 稳定到 94.6%。节奏的排定还要考虑外部因素：偏远节点的网络条件差，我们把涉及偏远节点数据同步的功能排在网络优化完成之后，避免功能做好了却用不上的尴尬。以某偏远区县为例，其专线带宽长期不足，我们先把网络优化与离线补传方案落地，再上线数据同步功能，上线后该区县的档案数据完整率始终保持在 99% 以上。前紧后稳的节奏让核心价值最先被验证，风险最早被暴露，这是 10 个月里最值得的一笔账。

三、权衡三：协同方式，在 " 严格把控 " 与 " 灵活响应 " 之间取舍

协同方式的权衡回答 " 方法与节奏怎么跟五大过程组及其他绩效域配合 "。开发方法与生命周期不是孤立的，它与五大过程组的协同体现在：启动过程组明确范围，规划过程组确定方法与排期，执行过程组按迭代推进，监控过程组用测量指标校准节奏，收尾过程组核验交付成果。协同方式的权衡在于 " 度 "：对厂商交付严格把控，对需求变化灵活响应。针对厂商交付质量参差的问题，我们把厂商交付物与验收标准在规划阶段写进协议，明确不合格不接收，这是 " 严 " 的一面；针对政策与需求变化，我们保留了需求缓冲期，新需求按优先级评估后进入后续迭代，这是 " 活 " 的一面。我们用标杆对照把本项目的交付质量与行业标杆做了对标：参考同类档案系统的数据准确率与交付及时率数据，把行业先进水平作为参照，据此确定测量指标的目标值——迭代速率、缺陷逃逸率、交付及时率每周统计、每月复盘，指标异常的迭代当场分析原因、调整安排。严与活的平衡让方法既能守住底线，又能适应变化，协同因此不是口号，而是每天都在运转的机制。以传承人档案模块为例，其申报要求中途调整过一次，因有缓冲期和优先级评估机制，该变更在当周评估、下一迭代落地，当前迭代照常收尾，严与活的配合经受住了实战检验。

项目最终按期通过终验，跨部门数据共享接口调用量月均突破 120 万次，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，用户满意度测评由 78 分提升至 94 分，各区县文化部门与市文旅局对系统的认可度明显提升。复盘整个项目，我的体会是：开发方法与生命周期管理的三次权衡，每一次都关乎项目的成败——方法选型权衡出灵活性，节奏排定权衡出重点，协同方式权衡出平衡，三次权衡做对了，开发管理就立住了，这正是本项目留给我最深的启示。因果图让适配根因有了答案，控制图让识别异常提前显形，标杆对照让测量指标有了参照。10 个月里印象最深的是迭代缓冲期：一次申报材料格式的政策调整，在缓冲期内两天消化，没有影响任何迭代，权衡时留出的余地，在关键时刻显现出了价值，也让团队对 " 权衡留余地 " 这个原则深信不疑。这套围绕三次权衡展开的开发方法与生命周期管理做法，后来被整理成公司在文化档案类项目的开发方法参考，供后续同类项目复用，也让后来的非遗类项目少走了不少弯路，开发方法与生命周期管理的价值由此得以延续。