需求实现成本指一个需求从进入排期到上线稳定运行所消耗的全部投入，通常包含人力工时、外部采购与外包、软硬件与云资源、测试与质量保障、上线发布与培训、运维与缺陷修复，以及延期、返工和机会成本。核算前先确定范围与时间跨度，再按成本项列出单位、单价口径和数量，用“工时×人力单价+采购金额+资源摊销+风险准备金”形成可复算的模型。下文给出成本项清单、口径规则、计算公式、敏感因素和取数责任，示例金额均标注为假设，实际核算时替换为现价。
要点总览（TL;DR）
- 需求实现成本通常包含人力工时、外部采购与外包、软硬件与云资源、质量保障、上线与推广、稳定期运维，以及延期返工等风险成本。
- 核算前先定边界：以单个需求或需求批次为对象，起点为进入排期或立项，终点为上线后稳定期结束，一次性投入与周期性投入分开记录。
- 总成本=人力+采购+资源摊销+质量+上线+运维+风险准备金；人力成本按各角色工时×对应单价计算，风险准备金按需求不确定性设定比例。
- 估算偏差主要来自范围变更与返工、人员投入结构、采购与许可价格波动、上线后缺陷量以及工期压缩，评审时建议同时给出基准与保守两个情景。
- 成本数据用于需求排序时，量级分档比精确到元更实用，估算结果随需求记录留存，可与价值评分同表对照。
核算范围与时间跨度怎么定
成本核算的第一步是划定边界。同一个需求，按“开发完成”和按“上线后稳定运行三个月”两种口径算出来的总成本可能相差数成，差别主要来自测试回归、发布支持和早期缺陷修复。建议以单个需求或需求批次为核算对象，批次核算适用于共享同一套设计、同一批发布的需求集合。
起止节点的常见设定是：起点为需求进入排期或立项评审通过，终点为上线后稳定期结束。稳定期长度按业务影响设定，一般取上线后一个完整业务周期，例如一个月度结算周期或一个促销周期。稳定期内发生的缺陷修复、监控告警处理、用户支持计入本次核算；稳定期之后的常规运维转入周期性成本，单独归集。
一次性投入与周期性投入要分开记录。开发工时、采购许可的首次费用、上线培训属于一次性投入；云资源月费、按席位计费的软件订阅、持续支持人力属于周期性投入。分开记录的原因是可比较性：一次性投入影响当期预算，周期性投入影响后续每期的持有成本，两者混在一起会让不同需求之间的对比失真。
| 范围要素 | 建议设定 | 说明 |
|---|---|---|
| 核算对象 | 单个需求或需求批次 | 批次适用于共享设计或同批发布的需求 |
| 起点 | 进入排期或立项通过 | 此前的前期调研若已单独核算，不重复计入 |
| 终点 | 上线后稳定期结束 | 稳定期长度按业务周期设定并写明 |
| 计入清单 | 本需求直接消耗的人力、采购、资源、测试、上线、稳定期运维 | 按成本项逐条登记 |
| 不计入清单 | 团队固定办公成本、与需求无关的平台建设、稳定期后的常规运维 | 在核算说明中列明，避免口径争议 |
需求实现成本包含哪些项目
成本项按发生环节排列，每一项都应有明确的计量单位和取数来源，否则后续无法复算。下表给出常见成本项、计量单位、取数来源和投入性质，可作为核算清单的起点，按实际项目增删。
| 成本项 | 计量单位 | 常见取数来源 | 一次性/周期性 |
|---|---|---|---|
| 人力工时：产品、设计、开发、测试、项目管理 | 人时或人天 | 任务记录、工时填报、排期计划 | 一次性为主 |
| 外部采购：外包开发、第三方组件、设计素材 | 金额（按合同或报价） | 合同、发票、报价单 | 一次性，订阅类为周期性 |
| 软硬件与云资源：服务器、环境、许可、存储与带宽 | 金额（按月或按量） | 云账单、用量明细、许可合同 | 周期性为主，环境搭建为一次性 |
| 质量保障：测试环境、自动化脚本、验收与回归 | 人时加资源金额 | 测试任务记录、环境账单 | 一次性为主 |
| 上线与推广：发布操作、培训、文档、用户沟通 | 人时加物料金额 | 发布记录、培训签到、文档工时 | 一次性 |
| 运行与维护：缺陷修复、监控、支持响应 | 人时加工具订阅金额 | 支持工单、故障记录、监控账单 | 稳定期内计入，之后转周期性 |
| 风险成本：延期、返工、需求变更 | 金额（按比例或情景估算） | 历史返工率、变更记录 | 准备金形式 |
人力工时是多数需求中占比最大的部分，按角色分别记录比只记总工时更有用：评审时能看出投入结构是否合理，后续类似需求也能按角色比例快速估算。外部采购要区分买断与订阅，订阅类即使首期金额小，也要按使用周期折算进总成本。云资源中，开发测试环境常被忽略，实际上一套独立测试环境的月度费用在总成本中并非可略项。风险成本不进入逐项加总，而是以准备金形式在总成本之后追加，具体比例见计算模型一节。
口径与假设怎么统一
不同需求之间要能比较，前提是金额、工时、币种、税费和摊销规则一致。口径不统一时，两个需求的总成本数字放在一起没有意义。建议在核算模板中固定以下字段的取值规则，每次核算只填数值不改规则。
| 字段 | 取值规则 | 示例值（假设） | 是否需按现价替换 |
|---|---|---|---|
| 人力单价 | 内部按成本价（含薪酬、社保、管理分摊），外部按报价；注明是否含税 | 内部综合单价 800 元/人天 | 是 |
| 工时单位 | 统一用人时或人天，折算系数写明（如 1 人天=8 人时） | 1 人天=8 人时 | 否 |
| 币种与汇率 | 统一折算为一种币种，注明汇率取值日期 | 外币按核算日汇率折算 | 是 |
| 税费 | 明确单价含税或不含税，采购金额以发票金额为准 | 采购金额按含税发票金额 | 是 |
| 云资源摊销 | 按需求占用比例或实际用量分摊月度账单 | 独占环境全额计入，共享环境按用量比例 | 是 |
| 许可与席位 | 按席位计费的注明席位数与计费周期 | 按 10 席位、年付折算月成本 | 是 |
| 跨部门投入分摊 | 写明分摊依据（工时比例或约定比例） | 共享测试团队按工时比例分摊 | 否 |
示例值与现价必须分开标注。上表中的单价、汇率、席位数量都是假设，用于演示计算过程；正式预算评审时应替换为当期财务口径或供应商报价，并在核算表中保留替换记录，便于后续追溯。跨部门投入的分摊规则要在核算前与相关部门确认，事后调整容易引发争议。
可复算的成本计算模型
总成本按以下公式汇总，各分项先按一次性与周期性分别计算，再合并：
总成本 = 人力成本 + 采购金额 + 资源摊销 + 质量保障成本 + 上线与推广成本 + 稳定期运维成本 + 风险准备金
其中人力成本 = Σ（各角色工时 × 对应人力单价）；风险准备金 = （人力+采购+资源摊销+质量+上线+运维）× 准备金比例，比例按需求不确定性设定，需求范围清晰时取较低值，探索性强或依赖外部交付时取较高值。周期性成本另按“月成本 × 计入月数”折算，与一次性成本分列展示。
以下演算示例中的全部数字均为假设，仅用于演示计算步骤：
- 人力：产品 10 人天、设计 8 人天、开发 40 人天、测试 20 人天、项目管理 6 人天，合计 84 人天；按综合单价 800 元/人天，人力成本为 67,200 元。
- 采购：第三方组件一次性授权 5,000 元。
- 资源摊销：独占测试环境月费 1,200 元，占用 2 个月，计 2,400 元。
- 质量保障：自动化脚本编写 5 人天，计 4,000 元，已含在人力口径外的部分单列，避免重复计算。
- 上线与推广：培训与文档 3 人天，计 2,400 元。
- 稳定期运维：按上线后一个月计，支持 4 人天，计 3,200 元。
- 风险准备金：前六项合计 84,200 元，按 15% 计提 12,630 元。
- 总成本：84,200 + 12,630 = 96,830 元，其中一次性约 93,630 元，周期性（稳定期后延续部分）按月另行归集。
复算时只需替换工时、单价和采购金额，公式结构不变。建议把上述步骤做成表格模板，每行保留“数量、单位、单价、金额、口径备注”五列，评审时任何人可以逐行核对。
哪些因素会让成本估算偏差最大
估算偏差通常不来自单价的小幅波动，而来自范围和投入结构的变化。下表列出影响最大的几类因素及应对方式，影响幅度为经验区间，具体项目应结合历史数据校准。
| 敏感因素 | 影响方向 | 影响幅度区间（经验） | 应对方式 |
|---|---|---|---|
| 需求范围变更与返工 | 成本上升 | 返工可使人力成本增加 20%–50% | 设置变更评审节点，返工工时单独记录 |
| 人力单价与人员投入比例 | 成本上升或下降 | 高级人员比例提高可显著推高人力成本 | 按角色记录工时，评审时核对投入结构 |
| 外部采购与许可价格波动 | 成本上升 | 订阅涨价或汇率变动可带来 5%–15% 差异 | 合同锁定价格周期，汇率注明取值日期 |
| 上线后缺陷量与支持强度 | 成本上升 | 缺陷集中时稳定期运维可翻倍 | 稳定期长度与支持人力按历史缺陷率预估 |
| 工期压缩带来的加班或加人 | 成本上升 | 压缩工期常伴随效率下降，人力和协调成本增加 | 压缩工期时同步调整准备金比例 |
预算评审时，建议对上述因素做一次情景测算：基准情景按当前估算，保守情景对返工和稳定期运维上浮一定比例。两个数字同时呈现，比单一数字更能支撑决策，也便于事后对比实际发生额校准估算方法。
取数方法与数据来源
每类成本都要明确数据来源、责任人和更新频率，否则核算表会在评审前临时拼凑，数字可信度下降。下表给出常见分工，实际执行时按团队职责调整。
| 成本项 | 数据来源 | 责任人 | 更新频率 |
|---|---|---|---|
| 人力工时 | 任务记录、工时填报、排期计划 | 项目经理 | 每周 |
| 采购金额 | 合同、发票、报价单 | 采购或财务对接人 | 发生时更新 |
| 云资源 | 云账单与用量明细 | 运维或平台负责人 | 每月 |
| 质量保障投入 | 测试任务记录、环境账单 | 测试负责人 | 每周 |
| 运维成本 | 支持工单、故障记录 | 运维或支持负责人 | 每月 |
| 风险准备金 | 历史返工率、变更记录 | 项目经理与财务共同确认 | 每季度校准 |
数据缺失时的替代估算要标注方法和不确定性。例如没有工时填报时，可按任务数量乘以同类任务的历史平均工时估算，并在核算表中注明“估算值，待工时数据补齐后替换”。替代估算可以支撑排序决策，但不宜直接作为对外承诺的预算数字。
把成本口径接入需求排序
成本数据的用途是与价值并列，形成需求排序的输入。实践中有两点需要注意：一是成本量级分档比精确到元更适合排序场景，把成本分为小、中、大三档或按区间标注，可以减少估算精度不足带来的争议；二是成本估算结果要随需求记录保存，评审时与价值评分同表对照，后续复盘时能回看当时的估算依据。
在 ONES 中，可以在需求工作项上设置预估工时与成本档位字段，评审时将价值评分与成本档位放在同一视图中对照，排序结论和估算依据随需求记录留存，后续类似需求可直接参考历史档位。这样成本核算不止服务于一次预算，而是逐步积累成可复用的估算基线。成本档位与价值评分的组合规则由团队自行约定，例如高价值低成本优先、高价值高成本进入专项评审，规则本身应随业务阶段调整。
常见问题
需求上线后稳定期应该设多长，稳定期内的支出怎么归类？
稳定期长度按业务影响设定，常见做法是取上线后一个完整业务周期，例如一个月度结算周期或一个促销周期。稳定期内发生的缺陷修复、监控告警处理和用户支持计入本次需求核算；稳定期结束后的常规运维转入周期性成本单独归集，避免与当期一次性投入混在一起。稳定期长度要在核算表中写明，不同需求采用不同长度时，比较总成本前应先统一口径。
团队没有工时填报数据，还能做成本估算吗？
可以，但要把估算方法写清楚。常见替代方式是按任务数量乘以同类任务的历史平均工时，或按角色投入比例从排期计划反推。核算表中注明“估算值，待工时数据补齐后替换”，并保留替换记录。替代估算可以支撑需求排序和预算讨论，不宜直接作为对外承诺的预算数字。若后续建立工时填报，历史估算与实际工时的差异正好用于校准单价和工时系数。
风险准备金比例怎么定，定高了或定低了会有什么影响？
准备金比例按需求不确定性设定：需求范围清晰、依赖少时取较低值，探索性强或依赖外部交付时取较高值。比例定得过低，遇到返工或缺陷集中时预算容易被击穿；定得过高，会让低成本需求在排序中显得不划算，挤压本可优先推进的事项。可行做法是先用历史返工率和变更记录校准一个区间，再按需求类型分档取值，并每季度复核一次。
多个需求共享同一套设计或同批发布，成本怎么分摊？
共享投入按工时比例或事先约定的比例分摊，规则要在核算前与相关部门确认并写入口径说明。共享测试环境按实际用量比例分摊月度账单，独占环境全额计入对应需求。批次核算适用于共享设计或同批发布的需求集合，批次总成本确定后再按分摊规则落到单个需求。事后调整分摊规则容易引发争议，建议在批次立项时就固定下来。
成本档位分几档比较合适，和精确金额如何配合使用？
排序场景下三档（小、中、大）或按区间标注通常够用，档位边界由团队根据自身成本分布约定。精确金额用于预算审批和合同采购，档位用于需求排序和组合讨论，两者可以并存：核算表保留逐项金额，需求工作项上记录档位。这样既避免因估算精度不足在排序会上反复争论具体数字，又能在需要时回溯到明细。档位边界应随业务规模变化定期调整。
