研发效能诊断访谈提纲模板由三张可复制表组成：访谈提纲表按角色组织问题清单，诊断问题清单表把访谈记录归并为可排序的问题，诊断报告表把结论、根因和改进项落到责任人与验证口径。三张表按“访谈—归并—报告”的顺序使用，适合单团队诊断或跨团队多轮诊断。下文给出空白表、字段填写口径、必填与选填对照、一份完整示例，以及按团队规模和诊断轮次调整模板的方法。
要点总览（TL;DR）
- 模板由三张表组成：访谈提纲表按角色记录问题与证据，诊断问题清单表归并现象并排优先级，诊断报告表落到根因、改进项、责任人和验证时点。
- 访谈提纲表按研发负责人、项目经理、开发、测试、运维/发布分组，每个角色保留3–6个核心问题，问题编号采用“角色序号-问题序号”便于回溯。
- 必填字段决定记录能否进入下一环节：访谈记录至少要有受访角色、问题编号、回答摘要；问题清单至少要有问题描述、证据来源、影响；诊断报告至少要有结论、改进项、责任人。
- 填写顺序是访谈现场记录、访谈后归并问题、最后汇总报告；目标指标与效能度量挂钩，写明当前值、目标值和验证时点，下一轮诊断回填结果。
- 模板按团队规模和诊断轮次裁剪，字段增删时同步更新空白表、字段说明和示例，历史版本只读保存以便跨轮次对比。
可复制空白模板：访谈提纲表
访谈提纲表用于访谈现场记录，一行对应一个问题。表头固定，问题行按角色分组，受访者回答与证据在同一行记录，访谈结束后可直接按编号回溯。建议每个角色保留3–6个核心问题，留出追问时间。
| 受访角色 | 问题编号 | 访谈问题 | 回答摘要 | 证据 | 待确认项 |
|---|---|---|---|---|---|
| 研发负责人 | R1-01 | 当前研发流程中，哪个环节的等待时间最长？ | |||
| 研发负责人 | R1-02 | 近一个季度交付延期主要集中在哪些类型的需求上？ | |||
| 研发负责人 | R1-03 | 团队目前用哪些指标判断交付质量？数据从哪里来？ | |||
| 项目经理 | R2-01 | 需求从提出到进入开发，平均需要经过哪些确认环节？ | |||
| 项目经理 | R2-02 | 排期变更时，信息通过什么方式同步给开发和测试？ | |||
| 项目经理 | R2-03 | 跨团队依赖的协调目前靠什么机制推进？ | |||
| 开发 | R3-01 | 开发过程中，哪些事项最常打断当前任务？ | |||
| 开发 | R3-02 | 代码评审从提交到完成通常需要多久？瓶颈在哪里？ | |||
| 开发 | R3-03 | 需求描述不清时，通常如何澄清，耗时多少？ | |||
| 测试 | R4-01 | 提测版本的返工比例大致如何？返工主要来自哪类问题？ | |||
| 测试 | R4-02 | 测试环境准备通常需要多长时间？是否经常等待？ | |||
| 测试 | R4-03 | 缺陷从发现到修复关闭，平均经历哪些状态？ | |||
| 运维/发布 | R5-01 | 一次常规发布需要哪些人参与，耗时多久？ | |||
| 运维/发布 | R5-02 | 发布失败或回滚的频率如何？主要原因是什么？ | |||
| 运维/发布 | R5-03 | 线上问题的发现和定位主要依赖哪些手段？ | |||
表格末尾保留空行，用于补充角色或临时追问。问题编号建议采用“角色序号-问题序号”的格式，便于在问题清单中引用访谈记录。
可复制空白模板：诊断问题清单与诊断报告表
访谈结束后，把同一现象在不同角色中的描述归并成一条问题，填入诊断问题清单表。问题清单回答“发现了什么、证据在哪、影响多大、先处理哪个”；诊断报告表回答“结论是什么、根因在哪、谁来改、怎么验证”。两张表通过问题编号关联。
诊断问题清单表
| 问题编号 | 问题描述 | 所属环节 | 证据来源 | 影响 | 优先级 | 待验证假设 |
|---|---|---|---|---|---|---|
| P-01 | ||||||
| P-02 | ||||||
| P-03 | ||||||
诊断报告表
| 关联问题编号 | 诊断结论 | 根因判断 | 改进项 | 责任人 | 目标指标 | 验证时点 |
|---|---|---|---|---|---|---|
| P-01 | ||||||
| P-02 | ||||||
两张表都保留空行，便于后续轮次追加。问题清单中的“待验证假设”在诊断报告形成前用于记录尚未确认的推断，确认后转入根因判断或删除。
字段说明：每个字段填什么、怎么判断
三张表的字段口径需要统一，否则同一现象在访谈记录、问题清单和报告中会出现三种说法。下表逐字段说明含义与填写要求。
| 所属表 | 字段 | 含义 | 填写口径 |
|---|---|---|---|
| 访谈提纲表 | 受访角色 | 本次回答对应的岗位 | 填写实际受访岗位，同一角色多人受访时分别记录 |
| 访谈提纲表 | 问题编号 | 问题的唯一标识 | 按“角色序号-问题序号”编制，全表不重复 |
| 访谈提纲表 | 访谈问题 | 现场提出的问题 | 一次只问一个现象，避免复合问题 |
| 访谈提纲表 | 回答摘要 | 受访者回答的要点 | 记录事实与具体例子，保留受访者使用的数量和时间表述 |
| 访谈提纲表 | 证据 | 支撑回答的材料 | 指向具体报表、文档、工单编号或访谈记录编号 |
| 访谈提纲表 | 待确认项 | 访谈中未说清的内容 | 写明需要向谁、用什么材料确认 |
| 问题清单 | 问题描述 | 归并后的现象描述 | 写清发生环节、对象和表现，一条问题只描述一个现象 |
| 问题清单 | 所属环节 | 问题发生的流程阶段 | 从需求、开发、测试、发布、运维等环节中选择 |
| 问题清单 | 证据来源 | 支撑该问题的材料 | 列出访谈记录编号、数据报表或文档，至少一项可回溯 |
| 问题清单 | 影响 | 问题造成的后果 | 写交付延期、质量返工、协作阻塞等具体后果及范围 |
| 问题清单 | 优先级 | 处理顺序 | 按影响范围（单团队/跨团队）与影响程度两维打分，规则诊断前统一 |
| 问题清单 | 待验证假设 | 尚未确认的原因推断 | 写成可验证的判断，注明验证方式 |
| 诊断报告 | 诊断结论 | 对问题的定性判断 | 基于证据给出，区分已确认事实与推断 |
| 诊断报告 | 根因判断 | 问题的主要原因 | 写到可采取行动的程度，多个原因按主次排列 |
| 诊断报告 | 改进项 | 针对根因采取的动作 | 写清做什么、改哪个环节，避免只写“加强管理” |
| 诊断报告 | 责任人 | 推进改进项的人 | 填具体岗位或姓名，一项改进对应一个责任人 |
| 诊断报告 | 目标指标 | 改进的衡量标准 | 与效能指标挂钩，写明指标名称、当前值和目标值 |
| 诊断报告 | 验证时点 | 检查改进效果的时间 | 写明具体日期或下一轮诊断节点 |
优先级判断建议在诊断开始前统一规则，例如影响范围跨团队记2分、单团队记1分，影响程度为交付延期记2分、质量返工记2分、协作阻塞记1分，按总分排序。规则一旦确定，本轮诊断内保持一致，便于不同访谈人横向比较。
目标指标要与度量体系对应。若团队已在系统中沉淀需求流转、缺陷和发布数据，可优先选择能从系统直接取数的指标，减少手工统计。ONES Performance 提供交付效率、交付质量、资源效率、完成情况四个维度的度量实践体系，并自动收录系统内日常流转的研发数据形成分析指标，可作为目标指标取数的参照；具体指标项以团队实际配置为准。
必填与选填：哪些字段不能空
必填字段决定一条记录能否被后续环节使用，选填字段用于补充信息。缺失时按下表处理，避免用模糊描述填空。
| 所属表 | 必填字段 | 选填字段 | 选填留空时的处理 |
|---|---|---|---|
| 访谈提纲表 | 受访角色、问题编号、回答摘要 | 证据、待确认项 | 证据暂缺时在待确认项写明补证方式；待确认项为空表示该问题已闭环 |
| 问题清单 | 问题描述、证据来源、影响 | 所属环节、优先级、待验证假设 | 所属环节不明时归入“待分类”；优先级未评时默认排在已评分问题之后 |
| 诊断报告 | 诊断结论、改进项、责任人 | 根因判断、目标指标、验证时点 | 根因未确认时写“待验证”并关联假设；目标指标暂缺时在下一轮诊断前补齐 |
必填字段缺失时，该条记录不进入下一环节。例如访谈记录缺少回答摘要，无法归并为问题；问题清单缺少证据来源，无法在报告中支撑结论。选填字段留空需要在表内注明原因，而不是直接跳过，这样下一轮诊断时能看出哪些信息是当时未采集、哪些是确认后无需填写。
填写示例：一次完整访谈到诊断报告
以下示例为演示情景，团队规模、数据和结论均为示意值，用于说明三张表的串联方式，不代表真实企业情况。
示例背景
某研发团队约20人，包含1名研发负责人、2名项目经理、10名开发、5名测试和2名运维。本轮诊断聚焦交付周期，访谈了5个角色各1人。
访谈提纲表填写示例
| 受访角色 | 问题编号 | 访谈问题 | 回答摘要 | 证据 | 待确认项 |
|---|---|---|---|---|---|
| 测试 | R4-01 | 提测版本的返工比例大致如何？返工主要来自哪类问题？ | 近两个月约三成提测版本需要二次提测，主要是接口字段与需求描述不一致 | 访谈记录F-03；测试平台提测记录 | 向项目经理确认需求评审是否覆盖接口字段 |
| 开发 | R3-03 | 需求描述不清时，通常如何澄清，耗时多少？ | 平均每次澄清约半天，主要靠即时消息找项目经理确认 | 访谈记录F-05 | 统计近一个月澄清次数 |
| 项目经理 | R2-01 | 需求从提出到进入开发，平均需要经过哪些确认环节？ | 需求评审后仍有字段细节在开发阶段补充 | 访谈记录F-02；需求文档 | 核对评审检查项是否包含字段定义 |
问题清单归并示例
| 问题编号 | 问题描述 | 所属环节 | 证据来源 | 影响 | 优先级 | 待验证假设 |
|---|---|---|---|---|---|---|
| P-01 | 需求评审未覆盖接口字段定义，开发阶段反复澄清 | 需求 | F-02、F-03、F-05；需求文档 | 提测返工约三成，单次澄清约半天，跨团队协作阻塞 | 高（跨团队，质量返工） | 补充评审检查项后返工比例下降 |
| P-02 | 提测版本二次提测比例偏高 | 测试 | 测试平台提测记录 | 测试周期延长，发布节奏受影响 | 高（单团队，交付延期） | P-01 改善后二次提测比例同步下降 |
诊断报告示例
| 关联问题编号 | 诊断结论 | 根因判断 | 改进项 | 责任人 | 目标指标 | 验证时点 |
|---|---|---|---|---|---|---|
| P-01 | 需求信息在评审阶段不完整，导致下游返工 | 需求评审检查项缺少接口字段定义 | 在需求评审模板中增加字段定义检查项，评审通过后方可进入开发 | 项目经理A | 二次提测比例由约30%降至20%以下 | 下一轮诊断（约8周后） |
| P-02 | 二次提测与需求澄清高度相关 | 同P-01，需求阶段信息缺失向下游传导 | 与P-01合并推进，测试在评审阶段提前介入字段核对 | 测试负责人B | 提测一次通过率提升 | 下一轮诊断 |
示例中P-02的根因指向P-01，因此改进项合并推进，避免同一原因产生两条独立任务。目标指标采用示意值，实际填写时应使用团队系统中可取的当前值。
调整与维护方法：按团队规模与诊断轮次改模板
模板需要随团队变化调整，但字段口径要保持稳定，否则多轮诊断之间无法对比。以下操作清单可用于裁剪和版本维护。
- 按团队规模增减问题行：小团队可合并开发与测试角色的问题，保留每角色3个核心问题；跨团队协作多的组织增加依赖协调和发布协同类问题。
- 按诊断轮次保留版本：每轮诊断开始前复制一份模板，文件名标注轮次和日期，历史版本只读保存，便于对比同一问题的变化。
- 字段增删同步三处：新增或删除字段时，同时更新空白表、字段说明表和填写示例，三处口径一致后才投入使用。
- 访谈资料归档：访谈记录、问题清单和诊断报告按轮次存入统一位置，问题编号跨轮次保持稳定，已关闭问题标注关闭轮次。
- 改进项跟踪衔接：诊断报告中的改进项转入日常任务跟踪，验证时点到期后回填结果，作为下一轮诊断的输入。
访谈记录、问题清单和改进项如果分散在个人文档中，跨轮次对比会变得困难。可将访谈记录作为文档归档，问题清单和改进项作为工作项管理，在系统中关联需求、缺陷和发布数据，使目标指标的取数与改进跟踪在同一处完成。ONES 支持将研发过程中的数据沉淀为工作项与文档，ONES Performance 可对系统内产生的数据进行多维度分析，并按交付效率、交付质量、资源效率、完成情况四个维度形成度量视图，适合把诊断报告中的目标指标与后续验证衔接起来；访谈提纲和诊断报告本身仍需团队按上述模板自行维护。
模板调整后，建议先用一轮小范围访谈试填，确认字段能覆盖实际回答再全面使用。诊断轮次之间保持问题编号和指标口径不变，改进效果才有可比性。
常见问题
访谈时受访者只能给出模糊描述，证据字段怎么填？
证据字段允许先留空，但要在“待确认项”写明补证方式，例如需要调取哪份报表、向谁核对、预计什么时候补齐。访谈结束后由访谈人按待确认项逐条补证，补齐后再把该条记录归并进问题清单。缺少证据来源的问题不进入诊断报告，避免结论只靠印象支撑。
一个问题同时涉及需求和测试两个环节，归并时放在哪里？
按问题的主要发生环节归类，把另一环节写进问题描述或影响字段。例如需求评审缺少字段定义导致提测返工，问题主体归入需求环节，影响中写明提测返工比例。若两个环节各自存在独立原因，拆成两条问题分别编号，在诊断报告中说明两条改进项的关联，避免同一原因被重复立项。
小团队人少，是否可以把五个角色的问题合并？
可以。小团队可把开发与测试的问题合并为一组，运维/发布问题并入研发负责人组，保留每个角色3个核心问题。合并后仍要保留受访角色字段，记录实际回答人，问题编号规则不变。跨团队协作多的组织反而应增加依赖协调、发布协同类问题，问题行数按实际协作复杂度调整。
诊断报告里的目标指标怎么和系统数据对应？
优先选择团队系统中已有流转数据的指标，例如需求流转时长、缺陷修复时长、发布频率，写明指标名称、当前值和目标值。ONES Performance 自动收录系统内日常流转的研发数据形成分析指标，并按交付效率、交付质量、资源效率、完成情况四个维度组织度量视图，可作为目标指标取数的参照；具体指标项以团队实际配置为准。系统外的数据需注明采集方式，避免下一轮验证时口径不一致。
多轮诊断之间，模板和历史记录怎么管理？
每轮诊断开始前复制一份模板，文件名标注轮次和日期，历史版本只读保存。问题编号跨轮次保持稳定，已关闭问题标注关闭轮次，新问题续编编号。访谈记录、问题清单和诊断报告按轮次归档到统一位置，改进项转入日常任务跟踪，验证时点到期后回填结果，作为下一轮诊断的输入。
