研发剩余投入，指从当前时点到目标交付节点，仍需投入的人力工时及其折算成本。它回答的是“还要投多少”，与“已经花了多少”分开核算。本文按范围界定、成本项、口径假设、计算模型、敏感因素、取数方法六步，给出一套可复算的估算框架，示例金额均为演算假设，不代表任何现价。
要点总览（TL;DR）
- 研发剩余投入指从当前时点到目标交付节点仍需投入的人力工时及其折算成本，与已发生投入分开核算。
- 核心公式：剩余投入 = Σ（剩余工作量 × 单位工时 × 人力单价）+ 非直接工时成本，非直接工时含评审、协调、等待与返工缓冲。
- 估算前先锁定核算对象（项目、版本或需求集合）和具体截止日期，同一份估算只对应一个对象，跨里程碑分段估算再汇总。
- 用乐观、基准、保守三档给出区间，三档共用同一套范围和口径，只调整返工比例与人员可用率等参数。
- 偏差主要来自需求变更、人员可用率、外部依赖等待和返工比例，建议各设监控项与触发调整规则，并保留版本记录。
剩余投入算到哪一步：范围与时间跨度
剩余投入的核算起点是当前时点，终点是目标交付节点或里程碑。核算前先把对象锁定为项目、版本或需求集合中的一种，同一份估算只对应一个对象，避免项目、版本、需求三层混算。已发生的工时和成本单列在“已投入”栏，不进入剩余投入；资金偏差、预算审批流程、交付达成率与可预测性指标属于其他分析口径，本文不展开。
范围界定建议落成一张表，由项目经理填写、技术负责人确认，作为后续所有取数和计算的基准。
| 界定项 | 填写内容 | 包含 | 排除 |
|---|---|---|---|
| 核算对象 | 如“版本 V3.2”或“需求集合：结算模块改造” | 该对象下的全部待办工作项 | 其他版本、已关闭需求 |
| 截止节点 | 如“目标交付日”或“提测里程碑” | 节点前需完成的开发、测试、评审 | 节点后的运维与迭代 |
| 时间起点 | 估算当日 | 起点之后尚需投入的工时 | 起点之前已登记工时 |
| 投入类型 | 人力工时及折算成本 | 直接工时、非直接工时、外部资源占用 | 资金偏差、达成率指标 |
截止节点要写具体日期，不写“上线前”这类相对表述，否则不同人取数时终点不一致，结果无法复算。若对象跨越多个里程碑，按里程碑分段估算再汇总，每段单独标注起止时间。
剩余投入包含哪些成本和资源项
剩余投入由三类条目构成：直接人力工时、非直接工时、外部资源占用。逐项列出并标注单位与责任角色，估算时才能逐条核对，避免遗漏或重复。
| 成本项 | 内容说明 | 常用单位 | 责任角色 |
|---|---|---|---|
| 开发工时 | 剩余待开发、联调、自测所需工时 | 人时 / 人天 | 开发负责人 |
| 测试工时 | 用例编写、执行、缺陷验证所需工时 | 人时 / 人天 | 测试负责人 |
| 设计与产品工时 | 交互、视觉、需求澄清与验收支持 | 人时 / 人天 | 产品/设计负责人 |
| 评审与协调工时 | 方案评审、跨团队对齐、例会 | 人时 | 项目经理 |
| 等待与依赖时间 | 外部接口、第三方交付、环境审批造成的阻塞 | 人天（按占用人力折算） | 项目经理 |
| 返工缓冲 | 按质量波动预留的返工工时 | 人时（按比例计提） | 技术负责人 |
| 外部资源 | 外包人力、临时支持、环境与工具占用 | 人天 / 按合同计费单位 | 采购或项目经理 |
单位统一是复算的前提。人时、人天、人月之间需要写明折算规则，例如“1 人天 = 8 人时”“1 人月 = 21 人天”，同一份估算内只使用一套规则。等待时间按被阻塞人力的占用折算，不按日历天直接计入，否则会把非人力时间算成成本。外部资源若按合同计价，保留合同单位并单独列示，不与内部人天混加。
口径与假设怎么写才可复算
口径决定同一份数据换个人算是否得到同样结果。工时口径要写明标准工时、加班折算方式和跨时区协作的处理：标准工时按每人每天多少小时计；加班按 1:1 还是系数折算；跨时区协作的会议与等待按哪一方工时计入。人力单价要注明来源，是内部成本分摊单价还是外部报价，分摊单价需说明包含哪些费用项。
| 口径项 | 写法示例 | 说明 |
|---|---|---|
| 标准工时 | 1 人天 = 8 人时 | 全文统一，不中途更换 |
| 加班折算 | 加班工时按 1:1 计入，或按公司制度系数 | 写明采用哪种 |
| 人力单价 | 内部成本分摊单价，元/人天 | 注明是否含社保、管理分摊 |
| 币种 | 人民币（CNY） | 涉及外币时注明汇率取值日 |
| 税费 | 含税 / 不含税 | 外部报价需明确 |
| 计费周期 | 按人天结算，按月汇总 | 与合同或内部核算周期一致 |
示例金额必须标注为假设。例如“假设开发单价 1200 元/人天、测试单价 900 元/人天”，这类数字仅用于演示计算过程，不能当作现价或对外报价依据。实际单价以财务或采购提供的口径为准，并在估算表附注中写明取数日期。
计算模型：从剩余工作量到预算区间
核心公式为：剩余投入 = Σ（剩余工作量 × 单位工时 × 人力单价）+ 非直接工时成本。先按角色或模块分层算出直接工时，再叠加评审、协调、等待、返工缓冲等非直接工时成本，最后汇总为总额。
三档估算通过调整关键参数得到：乐观档取较低的返工比例和较高的可用率，基准档取历史平均水平，保守档提高返工缓冲并下调人员可用率。三档共用同一套范围和口径，只改参数取值，结果才可比较。
示例演算（金额与参数均为假设）：某版本剩余开发 60 人天、测试 30 人天；开发单价 1200 元/人天，测试单价 900 元/人天；非直接工时按直接工时的 15% 计提。
| 档位 | 返工缓冲比例 | 直接工时成本（元） | 非直接工时成本（元） | 合计（元） |
|---|---|---|---|---|
| 乐观 | 5% | 60×1200 + 30×900 = 99,000 | 99,000×15% ≈ 14,850 | 约 113,850 |
| 基准 | 10% | 99,000 | 约 14,850 | 约 113,850（缓冲另计） |
| 保守 | 20% | 99,000 | 约 14,850 | 约 113,850 + 缓冲增量 |
实际填表时，把返工缓冲作为独立行计入非直接工时，三档分别给出缓冲金额，合计栏再相加，避免把缓冲混进直接工时导致无法追溯。按角色分层汇总后，还应按模块交叉核对一次，确认没有工作项被两个模块重复计入。
哪些因素会让剩余投入估算偏差最大
偏差通常不来自公式，而来自输入参数的变化。以下四类因素影响最大，建议在估算表中各设一个监控项和调整规则。
| 敏感因素 | 影响方式 | 监控方式 | 调整规则 |
|---|---|---|---|
| 需求变更与范围蔓延 | 剩余工作量增加，原估算失效 | 每周比对需求基线 | 新增需求单独估算并追加预算 |
| 人员可用率与并行任务 | 实际可投入工时低于名义工时 | 按周统计可用率 | 可用率低于假设值时上调人天 |
| 外部依赖与等待 | 阻塞拉长周期，占用人力 | 登记依赖项与阻塞时长 | 等待超过阈值时计入缓冲 |
| 返工比例与质量波动 | 缺陷密度上升推高测试与修复工时 | 跟踪缺陷趋势 | 返工比例超基准时切换保守档 |
调整规则要写清触发条件和动作，例如“当周可用率低于 80% 时，剩余人天按 1.2 倍系数重算”。规则一旦触发就留痕，便于事后解释预算变化的原因。
取数方法与数据来源
剩余投入的三个输入——剩余工作量、实际工时、人力单价——来源不同，需要分别规定取数位置、频率和复核人。
| 指标 | 来源 | 取数频率 | 复核责任人 |
|---|---|---|---|
| 剩余工作量 | 待办工作项、估算点数、历史完成速率 | 每周 | 项目经理 |
| 实际工时与剩余工时 | 工时登记记录、工作项剩余字段 | 每周或每日 | 团队负责人 |
| 人力单价与分摊比例 | 财务成本分摊表或外部合同 | 每季度或合同变更时 | 财务/采购 |
| 可用率与并行任务 | 资源规划与成员负荷数据 | 每周 | 项目经理 |
剩余工作量优先从待办工作项直接取，缺少逐项估算时，用“历史完成速率 × 剩余周期”推算，并注明推算方法。工时字段要求成员按工作项登记，剩余工时随进展更新，否则速率推算会失真。取数后由复核人抽查若干工作项，核对登记工时与工作项状态是否一致。
当团队在系统中持续维护工作项、工时登记和资源规划数据时，剩余工作量和可用率可以直接从这些记录中汇总。ONES 支持多维度统计项目和成员的资源投入情况，并可查询和导出工时登记日志明细，便于项目经理按周取数核对；资源规划视图和成员工作量、可用性、饱和情况的查看，也能为可用率参数提供依据。具体功能范围以实际购买方案为准。
把范围表、成本项清单、口径假设、计算表、敏感因素监控和取数对照表放在同一份文档中，每次更新只改参数并保留版本记录，剩余投入就能被复算、被解释，也能在预算申请和资源协调时作为可追溯的依据。
常见问题
剩余投入和已投入成本应该放在一张表里核算吗？
建议分开列示。剩余投入的起点是估算当日，只统计起点之后尚需投入的工时；已发生工时和成本单列在“已投入”栏，两者相加才能得到项目总投入。混在一起会导致两个问题：一是重复计算，已登记工时又被算进剩余工作量；二是无法判断预算变化来自历史消耗还是未来需求。实际操作中可以在同一份文档里设两个区块，共用范围界定表和口径假设，但分别汇总。
团队没有逐项估算工作量的习惯，剩余工作量怎么取数？
可以先用推算方式过渡：取历史完成速率（如近几个迭代平均每周期完成的工作项数或故事点），乘以剩余周期数，得到剩余工作量的近似值，并在估算表中注明这是推算而非逐项估算。同时逐步推动待办工作项补充估算，优先覆盖剩余周期内要交付的条目。推算结果建议按周与实际进展比对，偏差持续扩大时改为逐项估算。无论用哪种方式，都要写清取数日期和推算方法，保证换人也能复算。
三档估算的区间拉多大比较合适？
区间宽度取决于不确定性来源，没有统一比例。可参考的做法是：乐观档假设需求基本稳定、人员可用率接近名义值、返工比例处于历史低位；基准档取历史平均水平；保守档考虑范围可能扩大、关键人员被并行任务占用、外部依赖延迟。如果当前处于需求频繁变更或外部依赖较多的阶段，保守档与乐观档的差距应明显拉开，并在估算表附注中写明拉开的原因。区间给出后，预算申请可按基准档报批，同时说明触发保守档的条件。
估算做完后，多久更新一次比较合理？
常规节奏是按周更新剩余工作量和人员可用率，按季度或合同变更时更新人力单价与分摊比例。出现以下情况时应立即重算：需求基线发生变更、关键人员进出项目、外部依赖出现阻塞、缺陷趋势明显上升。每次更新只改参数并保留版本记录，不覆盖旧版本，这样预算变化的原因可以追溯。更新后由项目经理复核取数，财务或采购复核单价口径，两边确认后再对外使用。
等待外部依赖的时间要不要计入剩余投入？
要计入，但按被阻塞人力的占用折算，不按日历天直接计入。例如某接口等待两周，若期间有两名开发无法推进相关工作，就按这两人两周的可用工时折算，而不是把十四天日历时间全部算成成本。等待时间建议单独列一行，与直接工时分开，便于识别哪些成本来自依赖而非实际开发。同时登记依赖项和阻塞时长，等待超过设定阈值时在保守档中追加缓冲。
