当科技部门"人少、外包多、系统多、无源码"：一种"资产驱动型"IT 研发管理平台该怎么设计
市面上大多数研发产品默认客户是IT部门研发全流程管控。但现实中，大量泛金融科技公司、券商数科、保险 IT 部门的形态完全不同------自研团队小、外包体量大、存量系统多、大部分无源码、监管比银行轻。这篇文章基于这样一个典型场景，聊聊"这类客户"的研发管理平台到底该怎么设计。
一、先看客户画像，而不是先讲产品
在动手设计任何功能之前，我们先把客户"拆开看"：
| 维度 | 现状 |
|---|---|
| 科技团队 | 规模有限，以几十人计 |
| 外包团队 | 远超自研人数，是科技条线管理半径的主体 |
| 项目规模 | 每年项目数量多，并行度高 |
| 存量系统 | 系统数量庞大，且大部分无源码，由供应商（恒生电子等）开发、测试、发布制品 |
| 监管强度 | 明显轻于银行，评审、质量、研发过程、测试过程等重流程关注度低 |
一句话总结：这不是一个"研发过程管理"问题，而是一个"资产 + 外包 + 商务"的治理问题。
如果照搬银行自研型的 ALM（把需求、设计、代码、测试、投产、质量全部搬到平台上，要求每个节点留痕评审），这套东西对这类客户来说就是过度设计------用不上、学不动、也不想学。
二、核心洞察：三条主线取代"研发过程"
对这类客户，真正值得管死的只有三条主线：
1. 需求与立项主线（Why）：为什么做、值不值得做
业务提需求 → 项目经理写立项 → 供应商实施，这条链在轻监管环境下反而最重要，因为：
- 评审环节弱了，"立项文件"就成了唯一的决策留痕；
- 每年项目数量多，如果没有统一的需求池和立项流程，就是"谁嗓门大谁立项"；
- 预算与立项必须绑定，否则科技费用"花出去不知道花在哪"。
设计含义 ：需求管理保留，但不做过程级 （不追踪开发中每个 task），只做到"需求 → 立项 → 预算 → 供应商 → 项目 → 交付 → 验收"的决策级。
2. 资产主线（What）：我到底有哪些系统？
存量系统数量庞大，大部分无源码，全靠供应商维护。客户最需要的是：
- 每个系统的全生命周期档案：建设时间、承建商、合同金额、SLA 承诺、变更历史、投产记录、风险敞口；
- 系统与需求、项目、预算、合同、供应商之间的统一关联 （这正是"数字产品主干"的思想------不是代码主干，是资产主干）；
- 一句话能查到："这个系统是谁建的、花过多少钱、现在谁在维护、下次续约什么时候。"
设计含义 ：把"应用系统管理"升级为核心模块，作为所有其他模块的主数据，而不是一个附属台账。
3. 外包主线（Who）：这些人是谁、在干什么、值不值？
外包人员规模远超自研团队，管理半径远大于科技条线本身。这类客户真正头疼的从来不是"代码怎么写"，而是：
- 外包入场/离场、考勤、工时、结算；
- 供应商尽调、准入、考核、黑名单；
- 外包与系统、项目、合同、付款的四方一致性（谁建的、给多少、结算多少、干得怎么样）；
- 关键系统的单点依赖风险（某供应商垄断大量系统，一旦出问题怎么办）。
设计含义 ：把"外包管理 + 供应商管理 + 商务合同 + 预算"整合成一条外包治理主线，这是差异化价值所在，也是大多数通用 ALM 没有的模块。
三、明确"不做什么"：轻监管下的取舍
产品设计最难的不是加功能，而是砍功能。对这类客户，我们建议：
| 通用 ALM 常见模块 | 是否纳入 | 理由 |
|---|---|---|
| 代码管理 / CI/CD 流水线 | ❌ 不纳入 | 无源码，供应商交付制品 |
| 开发过程看板（燃尽图、故事点） | ❌ 不纳入 | 自研人少且不承担主体交付 |
| 单元测试 / 代码覆盖率 | ❌ 不纳入 | 供应商黑盒交付，无源码可测 |
| 迭代评审 / 每日站会 / Scrum 全套 | ❌ 不纳入 | 客户不关心研发过程 |
| 需求-设计-开发-测试的细粒度追溯 | ⚠️ 简化为"需求→项目→投产" | 保留可审计粒度即可 |
| 测试用例库 / 测试计划管理 | ✅ 保留测试报告模块 | 只要"结果报告"，不要"过程管理" |
| 质量审计 / 不符合项 | ⚠️ 保留极简版 | 满足基本合规，不追求 CMMI 级 |
| 预算 / 合同 / 供应商 / 外包 | ✅ 重点加强 | 这类客户的真正痛点 |
| 应用系统档案 / 资产主干 | ✅ 重点加强 | 无源码资产的唯一"数字身份证" |
| 投产管理 | ✅ 重点保留 | 无源码环境下，投产即"验收"，必须留痕 |
一句话：把"研发过程管理"砍掉 60%，把"资产 + 外包 + 商务"加满 100%。
四、产品设计：三条主线重新组织
我们建议按"需求立项-资产-商务"三条主线重新组织研发管理平台：
主线 1：需求与立项管理（Requirement & Initiation）
- 需求池管理：业务需求统一受理、登记、分类，形成待决需求池；
- 立项管理：标准化立项文件，强制字段化目标、范围、投入、预期效益、风险；
- 预算-立项绑定：没有预算的项目无法立项，没有合同的需求无法排期；
- 项目里程碑管理：里程碑、进度、风险、周报，不做 task 级；
- 投产管理（强保留）：投产窗口、报备、审批、结果记录------无源码环境下这是唯一的"质量闸口"。
主线 2：应用系统资产（Application Asset）
- 系统档案：一个系统一张"数字身份证"，涵盖建设时间、承建商、合同、SLA、投产记录、变更历史、风险敞口；
- 系统与合同绑定：每个系统必须关联到至少一份合同，避免"孤儿系统"；
- 系统生命周期看板：建设期 / 运行期 / 维护期 / 退役期四态清晰，供应商交接一目了然；
- 风险敞口视图：按供应商集中度、系统依赖度、无源码比例三维评估，识别"高危资产"。
主线 3：外包与商务闭环（Outsourcing & Commercial Loop）
- 供应商全生命周期：尽调 → 准入 → 合同 → 履约 → 考核 → 续约/退出；
- 外包人员档案：入离场、考勤、工时、技能等级、所属项目；
- 四方一致性校验：合同金额 vs 实际结算 vs 工时 vs 供应商考核结果，异常自动预警；
- 付款计划与节点：合同付款节点与项目里程碑挂钩，超期未付自动提醒；
- 科技费用多维分析：按系统 / 供应商 / 条线 / 年份切片，支撑经营决策；
- 续约预警：合同到期前 90/60/30 天三级提醒，避免"系统停摆"。
简化保留的模块
- 测试报告（结果级）：只收供应商交付的测试报告，不做用例库管理；
- 极简质量模块：不符合项登记 + 整改跟踪，满足基本合规即可。
说明：需求、立项、项目、投产已在主线 1 中按"决策级/里程碑级"组织，此处不再重复，强调"不做 task 级过程追踪"的原则。
一体化数据视图
- CIO 一屏：科技费用总量 / 供应商集中度 / 高危资产 Top / 未付合同 / 即将到期系统；
- 系统全生命周期追踪：任一系统点开即见"需求-立项-合同-预算-供应商-外包-投产-验收"完整链条；
- 审计追溯：所有决策节点留痕，满足轻监管下的最低审计要求。
五、为什么这套设计更适合这类客户
- 匹配管理半径：外包远超自研，管人的成本远大于管代码，把管理重心放在"人/商/钱/资产"上是理性的；
- 匹配监管强度：不做过程级追溯，避免为"没人看的评审"增加操作负担；
- 匹配技术形态：无源码 = 不需要 CI/CD、不需要代码管理，需要的是"资产档案 + 投产闸口"；
- 实施成本低 ：这类客户通常已有需求、项目、预算、应用系统等零散能力，这套设计是重排组合而非推倒重来，可平滑演进；
- 差异化：市面上绝大多数 ALM 都默认"银行自研 + 强监管"，这套"轻监管 + 重外包 + 资产驱动"的定位是明显的市场空档。
六、小结
研发管理平台不是越大越好，而是要"配得上客户"。
银行自研客户要的是"过程管控 + 质量审计"；
外包驱动 + 轻监管 + 无源码客户要的是"资产清晰 + 外包可控 + 商务闭环"。
沿着第二条路走------把"管系统、管人、管钱"做到极致，把"管代码、管过程"该放的放。
最好的开始时间是十年前，其次是现在。
北京维普时代软件