研发效能诊断问题清单与诊断报告模板

研发效能诊断要落到可执行，需要三份材料配合使用：问题清单负责逐项打分并记录证据，访谈提纲负责补齐数据背后的原因，诊断报告负责汇总结论、改进项和责任人。本文给出可直接复制到表格工具或文档中的空白模板，并说明字段口径、必填项和一份完整填写示例。模板适用于以度量证据为基础的团队级诊断，不涉及成熟度模型建设或技术债专项治理。

要点总览（TL;DR）

• 诊断材料分三份：问题清单逐项打分并记录证据，访谈提纲补齐数据背后的原因，诊断报告汇总结论、改进项与责任人。
• 问题清单按交付效率、交付质量、需求与规划、协作与评审、工程实践与自动化、度量与反馈六个诊断域组织，评分口径全文统一。
• 报告模板固定八个章节，分域发现表与改进项表是核心；结论页只写有证据支撑的判断，改进项必须具体到人和日期。
• 填写顺序建议先取数、再访谈、后成文：数据类问题提前取数，访谈记录指向问题编号，报告中的每条发现对应清单编号。
• 模板调整保留编号稳定、评分口径留版本、材料归档齐全，多轮诊断才能对比趋势。

可复制的研发效能诊断问题清单（空白表）

问题清单是诊断的主表，按诊断域组织，每个问题一行，填写时先记录观察方式和证据，再给评分。评分口径全文统一，建议采用1–5分制：1分表示基本缺失，3分表示部分落地但依赖个人，5分表示稳定执行并有数据佐证。若团队更习惯定性判断，可改用“符合/部分符合/不符合”三档，但同一轮诊断中只使用一种口径。

编号	诊断域	问题	观察方式	证据来源	评分	备注
D1-01	交付效率	需求从进入开发到上线的平均周期是否可统计？	数据	需求流转记录、发布记录
D1-02	交付效率	迭代内是否存在明显的排队等待环节？	访谈	开发、测试访谈记录
D1-03	交付效率	需求拆分粒度是否支持单周内完成交付？	文档	需求列表、迭代计划
D2-01	交付质量	线上缺陷是否有分级记录并回溯到需求或代码变更？	数据	缺陷记录、发布记录
D2-02	交付质量	测试阶段发现的缺陷中，返工占比是否可统计？	数据	缺陷状态流转记录
D2-03	交付质量	发布后是否执行回滚预案或灰度验证？	访谈	运维访谈、发布流程文档
D3-01	需求与规划	需求进入开发前是否完成优先级评审与验收标准确认？	文档	需求文档、评审记录
D3-02	需求与规划	迭代计划变更频率是否被记录和分析？	数据	迭代计划变更记录
D3-03	需求与规划	业务方与研发对需求范围的认知是否一致？	访谈	项目经理、业务方访谈
D4-01	协作与评审	代码评审是否有明确的检查项和响应时限？	文档	评审规范、评审记录
D4-02	协作与评审	跨角色信息获取是否需要多次询问才能完成？	访谈	开发、测试访谈记录
D4-03	协作与评审	阻塞问题是否有统一的记录和升级路径？	数据	阻塞事项记录、站会纪要
D5-01	工程实践与自动化	构建与部署是否由流水线自动完成？	数据	流水线执行记录
D5-02	工程实践与自动化	自动化测试覆盖了哪些关键路径，是否随需求更新？	文档	测试用例库、覆盖率报告
D5-03	工程实践与自动化	环境配置与依赖管理是否有统一规范？	访谈	运维、开发访谈记录
D6-01	度量与反馈	团队是否定期查看交付周期、缺陷率等指标？	访谈	团队例会记录
D6-02	度量与反馈	指标异常时是否有对应的分析和改进动作？	文档	复盘记录、改进跟踪表
D6-03	度量与反馈	度量口径是否在团队内公开且保持稳定？	数据	指标定义文档

“观察方式”一列标注该问题主要通过访谈、数据还是文档判断，便于安排诊断日程：数据类问题提前取数，访谈类问题排入访谈提纲，文档类问题提前收集材料。备注列记录证据位置或异常说明，不写主观评价。

访谈提纲：按角色准备的提问清单

访谈的作用是解释数据背后的原因，例如交付周期长是需求拆分问题还是评审等待问题。提纲按角色分组，每个角色3–6个问题，回答摘要需指向问题清单编号，保证定性判断可追溯。单次访谈建议控制在30–45分钟，由一人主问、一人记录，记录以摘要为主，关键原话可摘录。

受访角色	核心问题	回答摘要	指向问题编号
研发负责人	当前交付节奏的主要瓶颈在哪里？
研发负责人	哪些指标是团队真正在看的，哪些只是上报？
研发负责人	改进动作由谁推动，如何验证效果？
项目经理/交付负责人	需求进入开发前通常完成哪些确认？
项目经理/交付负责人	迭代中计划变更的主要原因是什么？
项目经理/交付负责人	跨团队依赖的等待时间通常出现在哪个环节？
开发工程师	拿到需求后，需要额外询问多少次才能开始开发？
开发工程师	代码评审平均等待多久，评审意见集中在哪些方面？
开发工程师	构建失败或环境问题每周大约占用多少时间？
测试工程师	测试介入时需求与验收标准是否清晰？
测试工程师	返工主要来自需求变更还是缺陷修复？
测试工程师	测试环境是否稳定，等待环境的时间如何？
运维/发布负责人	发布流程中哪些步骤仍需人工操作？
运维/发布负责人	线上问题回溯时能否快速定位到变更？
运维/发布负责人	发布频率与回滚次数是否有记录？

记录字段中，“回答摘要”写事实和具体例子，例如“评审平均等待一天以上，集中在周五”，避免只写“评审较慢”。“指向问题编号”填写对应的问题清单编号，一个问题可对应多条访谈记录，便于后续交叉验证。

诊断报告模板（空白文档结构）

诊断报告是输出文档，把问题清单的评分和访谈记录汇成结论、根因和改进项。报告结构固定为八个部分：诊断范围与时间、方法与数据来源、总体结论、分域发现、根因分析、改进建议与优先级、责任人与时间点、附录证据。结论页只写有证据支撑的判断，证据不足的内容放入附录待补充事项。

分域发现表按诊断域逐条填写，每条发现对应问题清单中的编号：

诊断域	现状描述	证据	影响	评分

改进项表把发现转化为可跟踪的动作，每条改进项必须对应至少一条发现：

改进项	对应发现	预期结果	负责人	目标时间	验证方式

改进项进入跟踪后，可以在ONES的工作项中建立对应条目，把负责人、目标时间和验证方式作为字段维护，报告文档与工作项互相引用，下一轮诊断时直接查看完成情况。这样诊断结论与执行记录保持在同一处，减少报告归档后无人跟进的情况。

字段说明与必填/选填划分

三份模板的字段口径需要一致，否则问题清单的评分无法在报告中解释。下表说明主要字段的含义与填写要求。

所属模板	字段	含义与填写口径	必填/选填
问题清单	编号	诊断域首字母加序号，如D1-01，全轮次保持稳定	必填
问题清单	问题	描述可观察的现象，避免“是否高效”这类无法判断的表述	必填
问题清单	观察方式	访谈、数据、文档三选一，决定证据收集途径	必填
问题清单	证据来源	具体记录名称或材料位置，如“近三个月缺陷记录”	必填
问题清单	评分	按统一口径打分，无证据时留空并说明原因	必填
问题清单	备注	异常说明、待补充证据	选填
访谈记录	受访角色	与提纲角色分组一致	必填
访谈记录	回答摘要	写事实、频次和具体例子，不写评价性结论	必填
访谈记录	指向问题编号	关联问题清单编号，可多选	必填
报告	现状描述	与证据一一对应，不加入未验证的推断	必填
报告	影响	尽量量化，如“评审等待平均增加一天”	必填
报告	改进项负责人与目标时间	具体到人、具体到日期	必填
报告	附录补充材料	原始数据、访谈全文、待补充证据	选填

必填项缺失会直接影响结论可信度：没有证据来源的评分不能进入报告，没有负责人和时间点的改进项无法跟踪。选填项用于补充上下文，不替代必填内容。

填写示例：从问题清单到诊断报告

以下示例为演示数据，用于说明三份模板如何串联，不代表任何真实团队的实测结果。示例背景：某研发团队在三个月窗口内开展诊断，范围覆盖两个交付小组，数据来源为需求流转记录、缺陷记录和六场角色访谈。

问题清单示例行：

编号	诊断域	问题	观察方式	证据来源	评分	备注
D1-02	交付效率	迭代内是否存在明显的排队等待环节？	访谈	开发、测试访谈记录	2	评审与测试环境等待被多次提及
D4-01	协作与评审	代码评审是否有明确的检查项和响应时限？	文档	评审规范、评审记录	2	有规范但未约定时限
D5-01	工程实践与自动化	构建与部署是否由流水线自动完成？	数据	流水线执行记录	4	构建自动，部署仍需人工确认

访谈记录示例：开发工程师回答“代码评审平均等待一天以上，集中在周五提交后”，回答摘要记为“评审等待约一天，周五提交的变更等待更久”，指向问题编号D4-01和D1-02。这条记录解释了D4-01评分偏低的原因，也支撑D1-02的排队判断。

报告片段示例：分域发现写“协作与评审：代码评审有规范但未约定响应时限，近三个月评审记录显示周五提交的变更平均等待超过一天，影响迭代末期交付节奏，评分2”。对应改进项写“为代码评审设定响应时限并在评审模板中增加检查项，预期将评审等待缩短到半天以内，负责人为研发负责人，目标时间为下一迭代开始前，验证方式为连续四周评审记录统计”。

模板的调整与维护方法

模板需要随团队情况调整，但调整要保留可比性。团队规模较小时可合并诊断域，例如将协作与评审并入交付效率，问题数量控制在15条左右；多团队诊断时可增加分域问题，但编号规则不变，新增问题使用新编号，不复用已删除编号。诊断轮次之间保持同一套编号，才能对比评分变化。

评分口径变更时记录版本，例如从1–5分制改为三档判断，需在报告首页注明版本号和变更原因，跨版本比较时只对比同一口径下的数据。诊断结束后归档四类材料：问题清单、访谈记录、诊断报告和改进项跟踪表，归档位置与命名规则固定，下一轮诊断直接复用上一轮清单，标注新增、删除和保留的问题，差异对比时先看保留问题的评分变化，再看新增问题的发现。

维护规则可归纳为：编号稳定、口径留版本、归档齐全、复用先对比。按这四条执行，多轮诊断的结果才能形成趋势，而不是每轮重新开始。

常见问题

问题清单里的评分没有足够证据，应该怎么处理？

评分列留空，并在备注中写明缺什么证据、计划从哪里补。没有证据来源的评分不进入诊断报告，可以放入附录的待补充事项。若诊断时间窗口内确实无法取数，改用访谈或文档判断，并在观察方式一列如实标注。

访谈记录和问题清单之间如何对应，才能避免重复劳动？

访谈提纲中的每个问题在记录时填写“指向问题编号”，关联到问题清单的对应行。一条访谈记录可以指向多个编号，一个问题也可以对应多条访谈记录。这样问题清单的定性评分有据可查，报告写分域发现时直接引用编号，不必重新翻访谈全文。

团队规模较小，诊断域和问题数量需要精简吗？

可以合并诊断域，例如把协作与评审并入交付效率，问题总数控制在15条左右。合并时保留原编号规则，被合并的问题沿用原编号，便于后续轮次对比。精简的是覆盖面，评分口径和证据要求不变。

多轮诊断之间评分口径变了，还能比较结果吗？

可以比较，但要在报告首页注明版本号和变更原因，跨版本只对比同一口径下的数据。更稳妥的做法是保留旧口径的历史数据，新口径从下一轮起单独记录，差异对比时先看保留问题的评分变化，再看新增问题的发现。

诊断报告写完以后，改进项怎么跟踪才不流于形式？

把每条改进项建成可跟踪的条目，负责人、目标时间、验证方式作为字段维护，报告文档与条目互相引用。下一轮诊断时先查看上一轮改进项的完成情况和验证结果，再开始新的评分。ONES 的工作项与文档可以承载这类跟踪记录，具体用法按团队现有流程安排。