047_滇西某地市级普惠信贷风控平台信息系统项目开发方法与生命周期绩效域

ONEPSOFT | 软考学习知识库

---

摘要

本文以滇西某地市级普惠信贷风控平台信息系统项目为例，沿项目前期、中期、后期的时间线论述开发方法与生命周期绩效域。该项目由该金融机构科技部发起，合同额 480.72 万元，2022 年 4 月启动，建设周期 16 个月，团队 14 人，采用低代码平台、微服务网关、OceanBase 与 RocketMQ 构建，前端 Vue3 与 TypeScript、后端 Java 17 与 Spring Boot 开发，我担任项目经理。针对业务连续性要求高、并发峰值性能压力大、法定验收时点刚性三个难点，我以标杆对照、因果图与控制图为支撑，确定了主平台多次交付、风控规则包持续交付的双轨节奏。项目于 2023 年 8 月按期通过终验，预警事件平均处置时长缩短 55%，资金结算差错连续 12 个月零发生，人工重复录入工作量下降 68%。

一、项目概况与我承担的工作

该金融机构面向本地涉农小微主体开展普惠信贷，客户笔均金额小、笔数多，风控长期依赖人工阅卷，一笔贷款要在信贷员、风控岗、审批岗之间流转数日，不同人的尺度还不一致，既拖慢放款又推高了逾期。为把风控从人工经验转向规则与模型驱动，该金融机构科技部作为建设单位发起本项目，我方中标承建，我被任命为项目经理。

系统建设内容包括客户准入、数据接入与加工、规则引擎、模型评分与贷后预警五个模块。技术实现上，采用低代码平台承载规则与审批流的可视化配置；后端服务经微服务网关统一鉴权与限流；客户与授信数据持久化于 OceanBase 分布式数据库；贷后预警与批量任务由 RocketMQ 异步驱动；前端采用 Vue3 与 TypeScript 开发，后端基于 Java 17 与 Spring Boot 框架。系统部署于该机构同城双活的信创环境，服务器与操作系统均为国产化产品，应用中间件采用东方通 TongWeb。

交付成果包括系统源代码与部署包；需求规格、概要与详细设计、数据库与接口规范等文档；规则与模型说明书；测试方案与测试报告；存量授信数据迁移与比对记录；割接与回退预案；面向信贷员、风控岗、审批岗三类角色共 7 场培训；以及 12 个月免费运维支持。

项目团队 14 人按矩阵型组织，下设需求组、开发组、集成实施组与测试组，另配专职配置管理员 1 名负责配置项标识与版本基线，质量保证人员 1 名。我作为项目经理，负责开发方法的选择、生命周期的划分与交付节奏的把控。

二、项目前期：确定生命周期与交付节奏

在项目前期阶段，需要根据产品特征与组织约束选择开发方法、划分生命周期并确定交付频率，这一工作被称为规划开发方法与生命周期。

本项目面临三重约束：业务连续性要求高，核心系统只能占用每月末的两个夜间窗口割接；办理高峰时段并发压力大；法定验收时点刚性，进度压缩明显。为避免闭门决策，我采用标杆对照，选取省内两家已上线同类风控平台的机构作为对标对象，逐项比较其生命周期划分、交付频率与割接安排，梳理出 17 项差异，其中 " 规则包与主版本分离发布 "" 割接前必须完成一次全链路演练 " 两项被直接吸收进本项目方案。

据此我确定了双轨的交付节奏：主平台采用多次交付，按客户准入、规则引擎与模型评分、贷后预警划分三个批次，分别在第 6、第 11、第 15 个月末交付；风控规则包因政策与风险形势变化频繁，采用持续交付，通过配置化发布，日常无须停机、不占用割接窗口。需要说明的是，交付节奏描述的是交付频率，包括单次交付、多次交付、周期交付与持续交付；而预测型、适应型与混合型描述的是开发方法，其中迭代与增量属于适应型的具体形态，两者不是同一维度的概念。本项目主平台以预测型推进，规则引擎部分采用适应型迭代，整体属于混合型，阶段与批次安排详见表 1。

三、项目中期：交付节奏的执行与偏差纠正

在项目中期阶段，需要按既定节拍产出可交付成果，并及时识别执行偏差、加以纠正，这一工作被称为开发方法与生命周期绩效域的执行与监控。

第二批次开发过程中，性能问题成为主要威胁。压测显示在办理高峰模拟场景下，规则引擎的平均响应时间波动剧烈，最差时超过 6 秒。我组织绘制因果图，从人、机、料、法、环五个方面排查：人——规则配置人员习惯写多层嵌套条件；机——缓存未按客户维度预热；料——外部征信数据接口响应不稳；法——规则执行未做短路优化；环——业务高峰集中在每日上午 9 至 11 点。根因判定为 " 法 " 与 " 机 "，即规则未做短路、缓存未做预热。

对策落地后，我用控制图对 " 规则引擎平均响应时间 " 持续监控，设定上控制限为 1.5 秒，每日取样一次。整改后前两周仍有 3 个点越限，追查为外部征信接口抖动所致，随即增加本地兜底缓存与降级策略；此后连续 10 周全部样本点落在控制限内且无连续同侧趋势，过程判定为受控，关键链路响应最终稳定在 1.1 秒以内。

割接方面，我把标杆对照吸收的 " 割接前全链路演练 " 固化为强制门槛：每个批次割接前必须完成一次带真实数据量的演练，演练不通过不得占用正式窗口。三个批次共演练 5 次，其中 1 次未通过并推迟到下月窗口执行，避免了一次可能的生产事故。

四、项目后期：验收准备与节奏移交

在项目后期阶段，需要确认交付成果满足验收条件，并把持续交付机制平稳移交给运营方，这一工作被称为收尾阶段的交付确认与移交。

第三批次交付后，我按合同约定组织了为期两个月的试运行。为守住法定验收时点，我把验收所需的安全测评、内部审计与档案归档三类材料的准备提前到第 14 个月并行开展，而不是等系统全部完成后再启动，仅此一项就为验收节省了约 3 周。与此同时，我把规则包的持续发布权限分阶段移交给建设单位的风控团队，并配套建立 " 发布前双人复核、发布后 24 小时观察 " 的制度，确保项目结束后规则仍能安全地持续更新，不因交付结束而失控。

五、项目经理需要重点关注的内容

结合本项目实践，我认为项目经理应重点关注五个方面，详见表 2。其一，关注不同交付物的变化频率差异，把高频变化的部分单独拆出来做持续交付，避免它被主版本的节奏拖累，也避免它反过来冲击主版本的稳定。其二，关注节奏与组织刚性窗口的对齐，本项目每月仅两个夜间割接窗口，批次时点必须提前半年就锁定。其三，关注方法选择的依据要可追溯，标杆对照的 17 项差异记录成为我方案答辩时最有力的支撑。其四，关注过程是否处于统计受控状态，控制图上的点分布比一句 " 性能达标 " 更能说明问题。其五，关注收尾期的能力移交，持续交付机制如果没有配套制度和人员承接，项目一结束就会退化。

六、结项成效与心得体会

本项目 2022 年 4 月启动，第一批次于同年 9 月末交付，第二批次于 2023 年 2 月末交付，第三批次于 2023 年 6 月末交付，随后进入两个月试运行，2023 年 8 月按期通过终验，全程 16 个月，与合同工期一致。核心成效为：预警事件平均处置时长缩短 55%；资金结算差错连续 12 个月零发生；人工重复录入工作量下降 68%。

回顾这段经历，我有三点体会。第一，交付节奏不必全项目一刀切，把变化频繁的规则包拆出来做持续交付，主平台按批次稳步推进，两条轨道各得其所，这一思路后来被建设单位推广到其他系统。第二，性能问题往往不是单点故障而是机制缺失，因果图把根因指向规则短路与缓存预热，控制图再证明整改后过程受控，技术团队与业务团队因此不再互相猜疑。第三，验收准备必须与开发并行而不是串行，把测评、审计、归档提前到第 14 个月，是本项目能在刚性时点前完成验收的关键；这种 " 关键路径外的准备工作尽早并行 " 的思路，同样适用于进度管理中的赶工决策与采购管理中的长周期物资安排。只有把开发方法、生命周期与交付节奏协调好，普惠信贷的风控能力才能既建得起来，又能长期跟得上变化。

表 1 生命周期阶段与双轨交付安排

轨道	交付批次/频率	时点	交付内容	开发方法
主平台	第一批次	第 6 个月末	客户准入、数据接入与加工	预测型
主平台	第二批次	第 11 个月末	规则引擎、模型评分	适应型（迭代）
主平台	第三批次	第 15 个月末	贷后预警、报表与移交	预测型
规则包	持续交付	按需随时	风控规则、阈值与名单策略	适应型

表 2 项目经理在本绩效域的关注要点

关注方面	本项目具体做法
变化频率差异	高频变化的规则包拆分为持续交付，与主版本解耦
刚性窗口对齐	三个批次时点提前半年锁定，对齐每月两个夜间割接窗口
方法选择可追溯	标杆对照两家同类机构，记录 17 项差异作为决策依据
过程统计受控	控制图监控响应时间，上控制限 1.5 秒，连续 10 周受控
收尾能力移交	规则发布权限分阶段移交，配套双人复核与 24 小时观察制度