当产品同时维护多个已交付版本时，判断维护成本是否可接受，核心是把并行维护的投入算清楚，再与这些版本带来的收入、合同承诺和客户留存价值对照。前提是先划定纳入核算的版本范围和时间窗口，统一人天、周期、币种与分摊口径，让总投入可以复算。单版本成本占比、版本间投入分布和关键敏感因素都落在预设阈值内，且没有隐藏的交付或合规风险时，成本可视为可接受。
要点总览（TL;DR）
- 判断多版本维护成本是否可接受，先划定纳入核算的已交付版本、支持级别与年度时间窗口，再统一人天单价、计费周期、币种与分摊口径，让总投入可以复算。
- 成本项按人力、测试、环境、发布与缺陷四类拆分，分别用人天、兼容性组合数、环境套数×月、补丁次数等可计量单位归集到具体版本。
- 可接受性看四个指标：单版本维护成本占版本收入或合同额的比例、版本间投入分布、新增版本的边际成本、维护总投入占研发总预算的比例，阈值按组织基线自行设定。
- 版本数量增加、客户集中于低合同额旧版本、缺陷密度与安全合规要求上升、关键人员流失、迁移延迟，都会把结论从可接受推向不可接受，需要按季度复核。
- 取数覆盖工时、缺陷、发布记录与支持工单，环境与许可费用按财务口径核对；数据缺口用相邻周期均值估算并标注，保证模型可审计。
维护范围与时间跨度怎么划定
成本核算的第一步是确定哪些版本进入账本。范围一旦漂移，后续所有比例和阈值都会失真。建议以“仍在向客户提供支持或补丁”为纳入标准，把已停止支持、仅保留归档的版本排除在外，避免把历史包袱算进当期投入。
纳入核算的版本清单需要同时满足三个条件：已经交付给客户、仍处于承诺的支持期内、本期仍可能产生补丁或支持动作。对于只做安全补丁、不再做功能修复的版本，可以单独标注支持级别，因为不同级别对应的人力与测试投入差别很大。
时间跨度建议以年度为核算周期，并标注每个版本的维护起止时间。维护期起点通常取首次交付或合同约定的支持起始日，终点取支持承诺到期日。跨年度的合同要拆到对应年度，避免把多年承诺一次性计入某一年。
范围表按版本、客户、合同三个维度分层统计，便于后续按版本汇总成本、按客户核对收入。下表是一个可填写的结构示例，具体行数按实际版本数量展开。
| 版本 | 交付时间 | 支持级别 | 承诺到期 | 关联客户数 | 关联合同额 | 本期是否产生投入 |
|---|---|---|---|---|---|---|
| V3.2 | 示例：2023年6月 | 完整支持 | 示例：2026年6月 | 待填 | 待填 | 是 |
| V3.0 | 示例：2022年3月 | 仅安全补丁 | 示例：2025年3月 | 待填 | 待填 | 是 |
| V2.8 | 示例：2021年1月 | 已停止支持 | 示例：2024年1月 | 待填 | 待填 | 否 |
完成这张表后，核算边界就固定下来：本期只对“是”的版本计算投入，收入侧只统计这些版本对应的合同与续约金额。后续章节的成本项、公式和阈值都基于这个范围展开。
多版本维护的成本和资源项有哪些
并行维护的投入分散在多个环节，单看开发工时容易低估。把投入拆成人力、测试、环境、发布与缺陷四类，每类给出计量单位，才能汇总成可比较的总量。
人力项
人力是占比最大的部分，按人天计量。开发侧包括针对旧版本的功能修复与代码合并；测试侧包括回归执行与缺陷复现；支持侧包括客户问题受理、远程排查与版本确认；发布侧包括补丁构建、发布值守与回滚预案。每个版本单独记录，公共投入另行标注。
测试项
测试投入取决于回归范围和兼容性矩阵。版本越多，需要验证的升级路径和依赖组合越多。计量单位可用“回归用例执行人天”和“兼容性组合数”。自动化脚本的维护也要计入，因为旧版本界面或接口变化会导致脚本失效，需要持续修补。
环境项
多版本并行意味着多套环境同时在线，包括测试环境、预发环境和客户问题复现环境。成本包括服务器或云资源占用、测试数据准备、许可证席位占用。计量单位可用“环境套数×月”和“许可席位数×月”，便于与财务口径对齐。
发布与缺陷项
补丁发布频次直接影响投入。高频热修会带来额外的构建、验证和客户通知工作。缺陷修复成本按“缺陷数×平均修复人天”估算，热修另加应急协调时间。安全补丁还需要额外的合规验证，应单独列项。
| 成本类别 | 具体项 | 计量单位 | 记录方式 |
|---|---|---|---|
| 人力 | 开发修复、测试执行、客户支持、发布值守 | 人天 | 按版本归集 |
| 测试 | 回归执行、兼容性验证、自动化维护 | 人天、组合数 | 按版本归集 |
| 环境 | 并行环境、测试数据、许可席位 | 套×月、席位×月 | 按财务账单归集 |
| 发布与缺陷 | 补丁发布、缺陷修复、热修、安全验证 | 次、人天 | 按版本与缺陷单归集 |
这张清单的作用是统一单位，让不同版本、不同季度的数据可以相加。清单本身不涉及单价和分摊，这些在下一节处理。
核算口径与假设怎么定
同一份工时数据，用不同单价和分摊规则会算出差别很大的结果。核算前需要把口径写成说明表，让任何人拿到原始数据都能复算出相同结论。
人天单价按组织内部成本口径设定，可以是全成本口径（含薪酬、社保、管理分摊），也可以是直接人力口径。两种口径不能混用。席位与许可按财务计费周期记录，月付和年付要折算到同一周期。币种统一为核算币种，涉及外币的按财务入账汇率折算，并注明汇率取值日期。
公共投入的分摊规则需要提前约定。例如跨版本共用的测试环境、公共组件维护、发布平台值守，可以按各版本工时占比分摊，也可以按版本数量平均分摊。规则一旦确定，本期核算内保持一致，便于跨期比较。
事实数据与示例假设要分开标注。工时、缺陷数、发布次数来自系统记录，属于事实数据；人天单价、汇率、分摊比例在缺乏正式口径时属于假设。示例演算中的金额只用于说明计算方法，不代表实际报价或预算。
| 口径项 | 取值方式 | 数据性质 | 备注 |
|---|---|---|---|
| 人天单价 | 组织内部成本口径 | 假设或财务核定 | 注明是否含管理分摊 |
| 计费周期 | 月或年，统一折算 | 事实 | 与财务账单一致 |
| 币种与汇率 | 核算币种，入账汇率 | 事实 | 注明汇率日期 |
| 公共投入分摊 | 按工时占比或版本均摊 | 假设 | 期内保持一致 |
可接受性怎么算：计算模型与预算框架
判断可接受性，需要把总投入折算到单版本，再与版本价值对照。单版本年度维护成本的基本公式是：该版本人力人天×人天单价，加上测试、环境、发布与缺陷的直接费用，再加上分摊的公共投入。把所有纳入范围的版本加总，得到年度维护总投入。
示例演算：某版本年度投入开发修复120人天、测试回归80人天、支持60人天、发布值守20人天，合计280人天；按示例单价每人天1000元计算，人力成本28万元；环境与许可分摊示例6万元；缺陷与热修示例4万元；该版本年度维护成本约38万元。此处的单价和金额均为示例假设，实际核算应替换为组织核定数据。
可接受性看三个比例。第一是单版本维护成本占该版本年度收入或合同额的比例，比例越低，维护的经济性越好。第二是版本间投入分布，如果少数旧版本消耗了大部分维护资源而收入贡献有限，说明资源错配。第三是边际成本，新增一个维护版本带来的增量投入是否低于它带来的增量收入或合同保障。
阈值需要组织自行设定，没有通用标准。设定方法可以是：先算出当前各版本的实际比例作为基线，再结合预算上限确定可接受区间；对战略客户或合同强制要求的版本，单独设定例外规则并注明理由。预算上限则按年度维护总投入占研发总预算的比例控制，超出时触发版本收敛讨论。
| 判断指标 | 计算方式 | 观察方向 | 阈值设定 |
|---|---|---|---|
| 单版本成本占比 | 版本维护成本÷版本收入或合同额 | 越低越经济 | 按基线设定 |
| 版本间投入分布 | 各版本成本占总维护成本比例 | 避免旧版本过度占用 | 按收入贡献对照 |
| 边际成本 | 新增版本增量投入÷增量收入 | 低于增量收益为宜 | 按合同承诺设定 |
| 总投入预算占比 | 维护总投入÷研发总预算 | 控制在预算上限内 | 按年度预算设定 |
哪些敏感因素会改变判断结论
核算结果建立在当期假设上，几个关键变量变化后，原本可接受的成本可能转为不可接受。识别这些变量，比追求一个精确数字更有决策价值。
版本数量增加是最直接的因素。每增加一个并行维护版本，测试组合、环境套数和发布协调都会上升，边际成本往往高于线性增长。客户集中度变化同样重要：如果少数客户集中在旧版本且合同额有限，维护投入的收入支撑会变弱。
缺陷密度和安全合规要求变化会推高测试与验证投入。安全补丁通常需要额外的合规检查和客户通知，周期比普通缺陷更长。关键人员流失会带来知识转移成本，熟悉旧版本的人员离开后，修复效率下降、回归范围可能扩大。测试环境扩容和许可到期续费也会改变环境项成本。
合同续约与升级迁移节奏决定维护期的实际长度。如果客户按计划迁移到新版本，旧版本维护投入会自然下降；如果迁移延迟，维护期延长，累计成本上升。建议把这些变量列入监控清单，按季度复核其对结论的影响方向。
| 敏感因素 | 变化方向 | 对成本的影响 | 对可接受性的影响 |
|---|---|---|---|
| 维护版本数量 | 增加 | 测试与环境投入上升 | 趋于不可接受 |
| 客户集中度 | 集中于低合同额旧版本 | 收入支撑减弱 | 趋于不可接受 |
| 缺陷密度与安全要求 | 上升 | 修复与验证人天增加 | 趋于不可接受 |
| 关键人员流失 | 发生 | 效率下降、知识转移成本 | 趋于不可接受 |
| 升级迁移节奏 | 加快 | 旧版本投入下降 | 趋于可接受 |
数据从哪里取、怎么核验
模型能否被信任，取决于取数是否可追溯。工时数据来自工作项与工时记录，缺陷数据来自缺陷单，发布记录来自发布或构建记录，支持投入来自工单系统。环境与许可费用以财务账单为准，与内部记录交叉核对。
取数清单应逐项写明来源系统、统计周期、责任人和核对方式。工时按版本归集时，注意区分直接投入和公共投入；缺陷按版本和严重级别统计，热修单独标记；发布记录按补丁次数统计，与客户通知记录对照。财务口径的环境费用要与资源台账匹配，避免重复计算或遗漏。
核验采用抽样加复盘的方式。每月抽取若干工作项和缺陷单，核对工时填报与实际处理是否一致；每季度做一次完整复盘，比较预算与实际投入的偏差，修正分摊比例和单价假设。数据缺口无法补齐时，用相邻周期的均值或同类版本的比例估算，并在说明表中标注为估算值，不与事实数据混列。
当工时、缺陷和发布记录分散在多个工具中时，统计口径容易不一致。ONES 可以把需求、任务、缺陷和工时记录放在同一工作项体系中，按版本字段归集投入，让维护成本的取数有统一来源；版本范围、支持级别和承诺到期时间也可以作为工作项属性维护，便于按版本汇总和月度复盘。具体字段和报表配置以实际使用为准。
完成取数与核验后，把范围表、成本项清单、口径说明和计算结果放在同一份核算文档中。任何人依据这份文档和原始记录，都能复算出相同的年度维护总投入和占比，成本是否可接受就有了可讨论、可审计的依据。
常见问题
维护期还没结束但客户已经迁移到新版本，这个版本还要计入核算范围吗？
建议按“本期是否仍可能产生补丁或支持动作”判断，而不是只看合同到期日。客户已全部迁移、本期没有支持请求和补丁计划的版本，可以从当期成本核算中移出，但在范围表里保留记录并标注迁移完成时间，便于跨期比较时解释投入下降的原因。如果合同仍约定支持义务，即使实际请求很少，也应保留在范围内，按最低支持投入估算，避免遗漏承诺风险。
组织没有正式的人天单价和分摊规则，第一版核算怎么起步？
可以先用财务已核定的直接人力口径作为起点，公共投入暂按各版本工时占比分摊，并在口径说明表中标注为假设。第一版核算的目标是建立可复算的结构，而不是追求精确金额。运行一个季度后，用实际工时分布和预算偏差修正单价与分摊比例，再逐步替换假设值。关键是同一期内口径保持一致，跨期比较时注明口径变化。
单版本成本占比算出来偏高，是否就意味着应该停止维护这个版本？
占比偏高是触发讨论的信号，不能直接作为停止维护的依据。需要同时看这个版本对应的合同承诺、客户留存价值和迁移可行性。如果合同强制要求支持，或客户迁移成本很高，占比偏高可能仍属可接受，此时应设定例外规则并注明理由。如果版本收入贡献有限、客户已有迁移路径，可以制定收敛计划，把维护投入逐步转移到新版本。
多个版本的工时和缺陷记录分散在不同工具里，统计口径怎么统一？
先确定以哪套记录作为工时和缺陷的权威来源，其他工具的记录只做交叉核对。按版本建立统一字段，把开发修复、测试执行、支持受理和发布值守都归集到同一版本标识下，公共投入单独标记。每月抽样核对若干工作项和缺陷单，确认填报与实际处理一致。当需求、任务、缺陷和工时记录在同一工作项体系中维护时，按版本字段汇总会更容易保持口径一致，ONES 支持在工作项中记录工时并按版本属性归集，具体字段配置以实际使用为准。
阈值应该多久调整一次，调整时依据什么？
建议每年结合预算编制调整一次，季度复盘时只观察是否越界，不频繁改动阈值。调整依据包括：上一年度各版本实际成本占比的基线、研发总预算的变化、合同承诺的版本支持要求、客户迁移计划的推进情况。阈值调整要在口径说明表中留痕，记录调整前后的数值和原因，避免不同季度数据因阈值变动而无法比较。
