研发投入产出报告要回答的核心问题很直接：一个统计周期内投入了多少人力与成本，交付了多少可核验的成果，单位投入的效率发生了什么变化。本文给出一份按季度填写的完整示例，覆盖投入口径、产出指标、效率比值和结论动作四个部分，并逐项说明每个字段的取值来源。示例中的团队、数字和结论均为演示假设，用于说明填写方式，不代表任何真实团队水平或行业基准。
要点总览（TL;DR）
- 研发投入产出报告按“投入口径—产出指标—效率比值—结论动作”四段组织，先固定统计周期、团队范围和成本折算规则，再呈现结果。
- 示例以12人团队一个季度为演示情景：33人月与18万元外部成本合计100.5万元，交付46个需求、扣除5个返工后有效交付41个，人均产出约1.24个/人月。
- 产出指标优先选交付需求数、上线版本数、需求吞吐、缺陷与返工等可核验成果，效率比值的分子分母必须同周期、同团队范围。
- 换团队时结构不变、指标可替换：项目制团队看验收项目与里程碑，产品制团队看上线需求与版本节奏，跨期对比前先对齐口径。
- 示例数字均为演示假设，不构成行业基准，也不能直接用于个人考核；投入占比与产品用户价值评估属于另外两类分析。
示例目标：这份报告要回答什么
这份示例报告设定为某研发团队季度经营回顾的附件，读者包括研发负责人、对接的业务方和管理层。三类读者的关注点不同：研发负责人关心产能与交付节奏，业务方关心需求是否按承诺上线，管理层关心资源投入与产出的关系是否合理。报告需要让三类读者在同一份材料上对话，因此字段要少而稳定，口径要写明。
报告要回答三个问题：
- 投入多少：本周期投入的人月总量、外部成本，以及折算规则。
- 产出多少：交付并上线的需求数、版本数，以及缺陷与返工情况。
- 效率如何变化：人均产出、单位成本产出、返工占比与上一周期相比的变化，以及变化的原因判断。
需要提前说明的是，本文示例中的团队规模、需求数量、缺陷数和成本金额均为假设值，目的是让每个字段都有具体填法可对照。读者可以把示例当作填写模板，把数字替换为自己团队经确认的统计结果。示例中的效率变化结论也只针对这个假设情景，不能外推为行业经验。
完整示例：一个季度的研发投入产出报告
以下是一份填写完成的季度报告示例。假设对象为一个 12 人的产品研发团队，统计周期为某年第一季度（1 月 1 日至 3 月 31 日），统计范围为该团队直接参与的需求交付工作，不含长期技术预研和外部采购的纯运维支出。
第一部分：投入口径
| 字段 | 示例填写 | 说明 |
|---|---|---|
| 统计周期 | 第一季度，1 月 1 日—3 月 31 日 | 与财务季度对齐，便于成本口径衔接 |
| 团队范围 | 12 人，含前端、后端、测试、产品接口人 | 按直接参与交付的在岗人数计 |
| 人力投入 | 33 人月 | 12 人 × 3 个月，扣除入职未满月与长期缺勤后折算 |
| 外部成本 | 18 万元 | 云资源、第三方服务与外包测试费用合计 |
| 人力成本折算 | 按团队平均全成本 2.5 万元/人月计 | 口径在报告首页注明，跨期保持一致 |
| 投入合计 | 33 × 2.5 + 18 = 100.5 万元 | 人力成本与外部成本相加 |
第二部分：产出指标
| 字段 | 示例填写 | 说明 |
|---|---|---|
| 交付需求数 | 46 个 | 本周期内完成开发、测试并上线验收的需求 |
| 上线版本数 | 6 个 | 含 2 个计划外紧急版本 |
| 需求吞吐 | 期初在途 18 个，期内新增 52 个，期末在途 24 个 | 用于说明交付量与积压的关系 |
| 线上缺陷数 | 14 个，其中严重 2 个 | 按上线后 30 天内发现的缺陷计 |
| 返工需求数 | 5 个 | 上线后因质量问题需要重新开发的需求 |
| 有效交付需求 | 46 − 5 = 41 个 | 交付需求数扣除返工需求 |
第三部分：效率比值
| 指标 | 示例计算 | 结果 |
|---|---|---|
| 人均产出 | 41 个有效交付需求 ÷ 33 人月 | 约 1.24 个/人月 |
| 单位成本产出 | 41 个有效交付需求 ÷ 100.5 万元 | 约 0.41 个/万元 |
| 返工占比 | 5 ÷ 46 | 约 10.9% |
| 严重缺陷密度 | 2 个 ÷ 6 个版本 | 约 0.33 个/版本 |
| 与上季度对比 | 人均产出由 1.18 升至 1.24，返工占比由 13% 降至 10.9% | 效率小幅改善，质量指标同步好转 |
第四部分：结论与下季度动作
示例结论写为：本季度有效交付 41 个需求，人均产出较上季度提升约 5%，返工占比下降约 2 个百分点，主要原因是需求评审阶段增加了技术可行性确认，减少了上线后的返工。需要说明的是，这一归因是团队复盘时的判断，报告本身只呈现指标变化，归因需在复盘中交叉验证。
下季度动作示例：
- 把需求评审中的技术可行性确认固化为准入条件，目标将返工占比控制在 10% 以内。
- 对 2 个计划外紧急版本做专项复盘，评估其占用的产能是否影响计划内需求交付。
- 期末在途需求 24 个，下季度初先做一次在途清理，避免积压继续扩大。
逐项解释：每个字段为什么这样填
示例的价值在于字段背后的取值规则。下面按投入、产出、效率三类字段说明计算方式，并列出常见填错点。
| 字段 | 取值来源 | 计算方式 | 常见填错点 |
|---|---|---|---|
| 人力投入 | 在岗人数与考勤、排班记录 | 人月 = 人数 × 在岗月数，不足整月按比例折算 | 人月与人天混用；把外包人员重复计入内部人力 |
| 人力成本 | 财务提供的团队全成本口径 | 人月 × 平均全成本 | 不同季度更换成本口径，导致跨期不可比 |
| 交付需求数 | 需求管理系统中的上线状态记录 | 统计周期内状态变为“已上线并验收”的需求数 | 把开发完成但未上线的需求计入 |
| 返工需求数 | 缺陷与变更记录 | 上线后因质量问题重新开发的需求，按需求去重 | 同一需求多次返工被重复计数 |
| 人均产出 | 有效交付需求数与人月 | 有效交付需求 ÷ 人月 | 分子用交付数、分母用人数，周期不一致 |
| 单位成本产出 | 有效交付需求数与投入合计 | 有效交付需求 ÷ 投入金额 | 成本含了非本团队支出，分母被放大 |
人力投入用人月还是人天。季度和年度报告用人月更稳定，月度报告或人员流动频繁的团队可用人天，但同一份报告内只能选一种，并在首页注明折算规则。人月与人天混用会让效率比值失去可比性。
产出为什么选交付量而不是代码行数。代码行数受语言、框架、个人风格和重构影响，同一功能不同实现方式的行数差异很大，无法反映交付结果。交付需求数、上线版本数、需求吞吐这些指标对应业务方可感知的成果，也便于跨团队对照。对于基础设施类团队，可以用可核验的交付物替代，例如接口上线数、稳定性事件处理数，原则是产出必须能被外部确认。
效率比值的分子分母必须同周期同范围。示例中人均产出的分子是 41 个有效交付需求，分母是 33 人月，两者都限定在第一季度和这 12 人范围内。如果分子统计了全团队交付、分母只算了部分人力，比值会虚高。跨期对比前，先确认两期的团队范围和成本口径一致，否则比值变化无法区分是效率变化还是统计范围变化。
返工与缺陷如何计入产出扣减。示例采用“交付需求数扣除返工需求数”得到有效交付需求，扣减规则写在产出表下方。另一种做法是不扣减交付数，单独列示返工占比，两种做法都可以，关键是全篇统一并在报告中注明。缺陷按上线后 30 天内发现计，这个时间窗也要写清楚，避免同一缺陷在相邻两个周期重复计入。
示例数字的假设说明。12 人团队、33 人月、46 个交付需求、100.5 万元投入均为演示假设，用于展示字段之间的计算关系。读者替换数字时，应保持字段间的勾稽关系，例如投入合计等于人力成本加外部成本，有效交付需求等于交付数减返工数。
当报告需要按季度反复出具时，工作项状态、工时记录和缺陷数据如果分散在多个表格里，每次汇总都要人工核对口径。ONES 可以把需求、任务、缺陷和工时记录放在同一套工作项体系中，按项目和周期筛选后导出统计结果，让报告中的交付数、返工数和人月数据来自同一数据源，减少跨表对齐的工作量。具体字段配置需结合团队现有的工作项类型设计。
可迁移规律：换团队换周期怎么改
示例的结构可以复用，字段需要按团队实际调整。可迁移的规则有以下几条。
- 结构不变，指标可替换。投入口径、产出指标、效率比值、结论动作四段结构适用于大多数研发团队，替换的是具体指标。替换时保证每个产出指标都有明确的统计来源和确认方式。
- 项目制团队与产品制团队的产出差异。项目制团队以验收交付为导向，产出可用验收通过的项目数、里程碑达成数；产品制团队以持续迭代为导向，产出可用上线需求数、版本节奏和线上质量指标。两类团队都建议保留返工或缺陷类指标作为质量约束。
- 月度、季度、年度的口径衔接。月度报告适合跟踪节奏，季度报告适合看趋势，年度报告适合做资源决策。三个周期的团队范围和成本口径应保持一致，年度数据由季度数据汇总而来，避免年度报告重新定义口径。
- 跨期对比的可比性处理。团队扩编、业务线调整或成本口径变化时，在报告中单列说明，并对对比基期做同口径重算。无法重算的，注明对比仅供参考。
- 指标数量控制。产出指标建议控制在 5 个以内，效率比值 3 个左右。指标过多会增加统计成本，也会让读者抓不住重点。
适用边界：示例不能直接当结论用
这份示例是填写方法的演示，使用时需要清楚它的边界。
演示数字不构成行业基准。示例中的人均产出 1.24 个/人月、返工占比 10.9% 只在这个假设情景内自洽，不同业务复杂度、需求颗粒度和团队职能构成的团队之间没有直接可比性。把示例数字当作标杆去要求其他团队，会得出错误结论。
投入产出比不能单独用于个人考核。报告统计的是团队层面的投入与产出，需求交付往往由多人协作完成，把团队比值拆到个人会忽略协作分工和需求难度的差异。个人绩效评估需要结合职责、任务难度和行为表现另行设计。
投入占比与资源利用率属于另一类分析。如果关注的是人力在不同项目、不同职能间的分布，或者资源闲置与超载情况，那属于投入结构分析和资源利用率分析，指标和呈现方式与本文的投入产出报告不同，本文不展开。
产品用户价值评估属于另一类分析。交付了多少需求说明的是产出数量，需求上线后对用户和业务产生了什么价值，需要通过产品验证、用户行为数据和业务指标来评估，这部分不在投入产出报告的范围内。
数据来源与统计口径需在报告中注明。每个字段的数据来自哪个系统、由谁确认、统计起止时间如何界定，都应写在报告首页或附注中。口径缺失的报告，数字再完整也无法支撑决策，跨期对比时尤其容易产生争议。
常见问题
团队第一次做研发投入产出报告，字段可以从几个开始？
建议从最小可用集合起步：投入侧保留统计周期、团队范围、人力投入（人月）、外部成本和投入合计；产出侧保留交付需求数、返工需求数和有效交付需求；效率侧保留人均产出和返工占比。这组字段能支撑“投入多少、产出多少、效率是否变化”三个基本问题，统计成本也低。
运行一到两个周期后，再根据读者提问补充指标。例如管理层关心成本，可增加单位成本产出；业务方关心交付节奏，可增加需求吞吐和上线版本数。每次新增字段时同步写清取值来源和计算方式，避免口径在团队内出现多个版本。
月度报告和季度报告的口径怎么衔接，才不会出现两套数字？
关键是让月度数据成为季度数据的组成部分，而不是各自独立统计。团队范围、人力成本折算规则、返工扣减规则和缺陷统计时间窗应在年初确定一次，月度、季度、年度报告都沿用同一套定义。
季度报告由三个月的月度数据汇总，年度报告由四个季度汇总，汇总时只做加总，不重新定义字段。遇到团队扩编或成本口径调整，在当期报告中单列说明，并对对比基期做同口径重算；无法重算的部分注明对比仅供参考。
需求颗粒度差异很大，交付需求数还能横向比较吗？
直接比较不同团队的需求数意义有限，因为一个需求在不同团队的拆分粒度可能相差数倍。可行的做法是先在本团队内部统一需求拆分规则，例如按可独立验收的业务价值单元计数，并在报告中注明规则；跨团队比较时，改用同口径的交付周期、返工占比、缺陷密度等比率型指标，或结合需求规模分级后再比较。
如果确实需要跨团队对照，建议先做一次需求颗粒度的抽样校准，确认两边的计数规则接近，再解读数字差异。
报告里的效率变化原因，应该由谁来写？
指标变化由报告呈现，原因判断建议由团队复盘得出，再由研发负责人确认后写入报告。示例中“返工占比下降源于评审阶段增加技术可行性确认”这类归因，属于复盘判断，需要在复盘中用返工记录、评审记录等材料交叉验证，避免把相关性直接写成因果。
如果当期无法确认原因，报告可以只描述变化并列出待验证的假设，把归因留到下一次复盘补充，这比给出一个未经核实的结论更可靠。
报告数据分散在多个表格里，每次汇总都要人工核对，有什么改善思路？
先梳理字段与数据源的对应关系：交付需求数来自需求状态记录，返工数来自缺陷与变更记录，人月来自工时或在岗记录。把这三类数据放在同一套工作项体系中按项目和周期筛选，汇总时就不需要跨表对齐口径。
ONES 可以将需求、任务、缺陷和工时记录纳入统一的工作项管理，并按项目与统计周期导出结果，供报告直接引用；具体的工作项类型与字段配置需结合团队现有流程设计。无论使用哪种方式，报告首页仍应注明每个字段的数据来源与确认人。
