判断研发知识传承有没有真正发生，核心看接手人能否在缺少原负责人口头补充的情况下独立完成原本由对方承担的任务，并观察重复提问、返工与缺陷、问题闭环时间等信号是否同向变化。评估前先固定任务范围与时间窗，把知识形成（文档、案例、评审记录）和知识应用（独立完成、复用、纠错）分开看，用多个信号交叉验证。ONES Wiki 可承载文档、复盘记录与项目任务的关联信息，为取数提供部分证据来源，具体口径仍需团队自行定义。
要点总览（TL;DR）
- 判断传承是否真正发生，看接手人能否在缺少原负责人口头补充的情况下独立完成原本由对方承担的任务，而不是看文档写了多少。
- 用四类信号交叉验证：独立完成率、重复提问与求助频次、交接后缺陷率与返工率、问题闭环时间与升级求助比例，多数信号同向改善才可下较强结论。
- 每个信号先写清分子、分母、时间窗和缺失值规则，再与交接前等长基线对比；分母为零时标记为无样本，不写零分或满分。
- 信号冲突时回到原始记录排查任务难度、需求波动和人员变动，结论分已发生、部分发生、未发生三档，并写明支撑信号与待解释项。
- 不设通用达标线，阈值按模块风险设定；文档数量、培训场次属于知识形成层面的投入指标，不能作为传承发生的判断依据。
评估目标：传承要验证到什么程度
评估研发知识传承，先要明确判断对象。传承包含两个层面：知识形成，即原负责人把经验写成文档、案例、评审记录；知识应用，即接手人能在实际任务中调用这些知识解决问题。文档齐全只说明知识形成有产出，不能证明知识应用已经发生。评估要回答的问题是：接手人是否已经具备独立承担某项任务的能力。
评估对象应落到具体任务、角色或模块上。例如“订单结算模块的日常维护由A交接给B”“支付渠道接入的排障职责由张三交接给李四”。对象越具体，后续取数和结论越可靠；如果笼统评估“整个团队的知识传承”，信号会被大量无关任务稀释。
结论用途决定评估的严格程度。用于交接验收时，需要事先约定判断规则和观察窗；用于季度复盘时，可以放宽为趋势观察；用于改进交接方式时，重点看哪类知识在应用环节反复出问题。建议在评估开始前写一份目标说明，包含三项内容：评估对象（哪个模块、哪个角色、哪批交接）、判断问题（接手人能否独立完成哪些任务）、结论用途（验收、复盘还是改进）。这份说明同时是后续口径统一的依据。
指标与范围：选哪些信号、圈多大范围
传承是否发生，可以从四类可观察信号判断。它们分别对应独立承担、求助行为、交付质量和问题处理效率，单看任何一类都容易误判，组合使用才能形成较完整的证据链。
| 信号 | 观察内容 | 适用场景 | 主要局限 |
|---|---|---|---|
| 接手人独立完成任务的比例 | 交接后由接手人独立完成、无需原负责人介入的任务占比 | 职责明确的模块交接、岗位轮换 | 需要明确“介入”的判定标准 |
| 重复提问与重复求助频次 | 同一问题在沟通渠道被再次提出的次数变化 | 有固定答疑渠道或群组的团队 | 依赖提问记录的完整性 |
| 交接后缺陷率与返工率 | 交接后新增缺陷、返工任务相对变更量或任务量的比例 | 有缺陷跟踪和任务记录的研发团队 | 受任务难度和需求波动影响 |
| 问题闭环时间与升级求助比例 | 接手人处理问题的平均耗时、需要升级给原负责人的比例 | 运维、排障、线上问题处理类交接 | 样本量小时波动明显 |
统计范围要按模块、团队或交接批次圈定，避免把指标泛化到整个知识库运营。按模块圈定适合职责边界清晰的交接；按交接批次圈定适合一次集中交接多名成员的情况；按团队圈定适合评估整体传承氛围，但需要更大的样本量。范围一旦确定，交接前后的统计口径应保持一致，否则对比失去意义。
信号选择还应与任务风险匹配。核心模块的交接，独立完成率和缺陷率应作为主要信号；辅助性、低频维护的模块，可以更多依赖问题闭环时间和升级求助比例。低频任务在短观察窗内可能没有足够样本，此时应延长观察期或补充定性证据，而不是用零样本强行下结论。
数据口径与证据：每个信号怎么取数
每个信号在计算前都要写清分子、分母、时间窗、单位和缺失值规则。口径卡建议逐项填写，评估过程中不再临时调整。
| 信号 | 计算口径 | 时间窗 | 数据来源 | 缺失值处理 |
|---|---|---|---|---|
| 独立完成率 | 无原负责人介入完成的任务数 ÷ 交接后该范围全部任务数 | 交接完成后固定观察窗，如2个月 | 任务记录、协作沟通记录、评审记录 | 任务记录缺失时标注为不可判定，不计入分子分母 |
| 重复提问频次 | 同一问题在指定渠道被再次提出的次数 | 与观察窗一致，可按周统计 | 答疑群、工单、评论记录 | 渠道记录不完整时注明覆盖范围，不推算 |
| 交接后缺陷率 | 交接后新增缺陷数 ÷ 对应变更量或任务量 | 注明统计周期，与基线周期等长 | 缺陷跟踪记录、发布记录 | 分母为零时该指标不计算，单独说明 |
| 返工率 | 被退回或重新打开的任务数 ÷ 该范围完成任务数 | 与观察窗一致 | 任务状态流转记录 | 状态记录缺失的任务排除并注明数量 |
| 问题闭环时间 | 问题从提出到关闭的平均时长，单位小时或天 | 与观察窗一致 | 工单或问题记录 | 未关闭问题不计入均值，单独列出数量 |
| 升级求助比例 | 升级给原负责人处理的问题数 ÷ 该范围问题总数 | 与观察窗一致 | 问题记录、沟通记录 | 分母为零时不计算 |
“同一问题”的判定需要事先约定规则。可以按问题对象加现象描述判定，例如“结算金额四舍五入异常”重复出现计为同一问题；表述不同但指向同一根因的，由评估人合并计数并保留原始记录。规则写进口径卡，避免不同人统计出不同结果。
定性证据用于补充定量信号的不足。可采集三类材料：交接文档的实际使用痕迹，如接手人在文档上的评论、修订和引用；评审记录中接手人独立发表意见、被采纳的情况；接手人自己的复盘说明，描述哪些问题已能独立处理、哪些仍需求助。定性证据应注明采集时间和来源，与定量数据分开呈现，不混算成比例。
缺失值和分母为零要单独处理。分母为零表示观察窗内该范围没有相关任务，此时该指标标记为“无样本”，不写为零分或满分；缺失值超过一定比例时，应在结论中说明数据覆盖不足，结论强度相应降低。
计算与评估步骤：从取数到下结论
评估按固定步骤推进，保证结果可复算、可解释。
- 确定交接前基线与交接后观察窗。基线取交接前一段与观察窗等长的时间，例如交接前2个月对比交接后2个月；如果交接前数据不可得，改用同类模块或同团队其他成员作为参照，并在结论中注明。
- 按口径卡逐项取数，计算每个信号的基线值和观察值。计算过程保留原始数据，便于复核。
- 逐项对比变化方向。独立完成率上升、重复提问下降、缺陷率与返工率下降、闭环时间缩短、升级求助比例下降，都是正向信号；方向相反或基本持平的，标记为待解释项。
- 多信号交叉验证。多数信号同向改善，可以支持“传承已发生”的判断；信号互相冲突时，回到原始记录查找原因，例如任务难度是否变化、人员是否有调整、统计口径是否一致。
- 形成结论。结论分为“已发生”“部分发生”“未发生”三档，每档附上支撑信号和待解释项。部分发生要写明哪些任务已能独立承担、哪些仍需支持。
判断规则建议在评估前写入目标说明。例如：独立完成率达到约定阈值、重复提问较基线明显下降、缺陷率未上升，三项同时满足可判为已发生；仅独立完成率改善而质量信号恶化，判为部分发生并说明风险。阈值按任务风险设定，核心模块要求更严，辅助模块可以放宽。
取数环节如果任务、缺陷、文档和评审记录分散在不同工具中，关联成本会直接影响评估能否持续。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应，文档实时同步并记录页面版本；团队可以把交接文档、复盘记录与对应任务放在同一关联结构中，减少取数时的人工拼接。评估口径本身仍需团队按上述步骤自行定义。
例子：一次模块交接的评估演算
以下为演示情景，数据为假设值，用于说明计算与判断过程。
背景：某团队将“结算模块”的日常维护由A交接给B，观察窗为交接后两个月，基线取交接前两个月。交接前该模块月均完成任务40项，新增缺陷8个，变更量约60次；交接后两个月共完成任务70项，其中无A介入完成49项，新增缺陷21个，变更量约100次；答疑群中“结算对账差异”类问题交接前两个月出现12次，交接后两个月出现5次；升级给A处理的问题交接前占比30%，交接后占比18%。
| 信号 | 基线 | 交接后 | 变化 |
|---|---|---|---|
| 独立完成率 | 不适用（原负责人承担） | 49 ÷ 70 = 70% | 新增指标，需结合其他信号解读 |
| 重复提问频次 | 12次/2个月 | 5次/2个月 | 下降 |
| 缺陷率 | 8 ÷ 60 ≈ 13.3% | 21 ÷ 100 = 21% | 上升 |
| 升级求助比例 | 30% | 18% | 下降 |
信号出现冲突：独立完成率70%、重复提问和升级求助比例下降，说明B已能处理大部分任务；但缺陷率从约13.3%升至21%，质量信号恶化。此时不能直接判为已发生。补充取证发现，观察窗内该模块承接了一次紧急需求变更，变更集中在B尚未接触过的对账规则部分，缺陷也主要集中在该部分。据此可以判为“部分发生”：常规维护任务已实现独立承担，对账规则相关任务仍需支持，建议延长观察窗或安排针对性交接。
分母为零的处理：假设观察窗内该模块没有发生线上故障，则“故障平均闭环时间”无样本，应标记为“无样本”，不写成0小时，也不据此判断传承效果好。可以改用其他有样本的信号，并在结论中说明该维度未覆盖。
解读与限制：哪些结论不能下
指标变化可能来自任务难度、需求波动、人员变动等外部因素。交接后缺陷率上升，可能是接手人不熟练，也可能是同期需求复杂度提高；重复提问减少，可能是知识被掌握，也可能是提问渠道改变或团队沟通习惯变化。解读时应先排除这些替代解释，再归因于传承本身。
文档数量、培训场次、知识库条目数属于知识形成层面的投入指标，不能代表传承发生。文档写得再多，如果接手人仍无法独立处理任务，传承就没有在应用层面落地。这类数据可以作为过程参考，不进入传承是否发生的判断依据。
样本量小或观察窗过短时结论不稳定。低频模块在两个月内可能只有个位数任务，独立完成率的波动会被放大；此时应延长观察期、合并同类模块统计，或更多依赖定性证据，并在结论中注明置信程度有限。
不设通用达标线。不同模块的风险、任务频率和知识复杂度差异很大，统一阈值容易造成误判。阈值应按任务风险设定：核心链路、故障影响大的模块要求更高的独立完成率和更低的升级求助比例；辅助模块可以接受更长的学习期。阈值一旦确定，应在同一批评估中保持一致，便于横向比较。
常见误判还包括：把一次成功处理当作能力已形成，忽略其是否可重复；把接手人“没有提问”当作已掌握，忽略其可能因不敢问而延迟处理；把交接文档的完成度当作验收通过。评估时保留原始记录、注明数据覆盖范围，并在结论中写明支撑信号和待解释项，可以让判断经得起复盘检验。
常见问题
交接后缺陷率上升，是不是就说明传承没做好？
不能直接这样判断。缺陷率上升可能来自接手人不熟练，也可能来自同期需求复杂度提高、变更集中在陌生模块或发布节奏变化。建议先核对观察窗内的任务构成和变更分布，看缺陷是否集中在特定模块或特定类型；如果缺陷集中在接手人尚未接触的部分，更合理的结论是“部分发生”，并针对该部分补充交接，而不是整体否定传承效果。
观察窗内任务太少、分母为零，评估还能做吗？
可以做，但要调整方法。分母为零的指标标记为“无样本”，不写成零分或满分，也不据此判断传承好坏。低频模块可以延长观察期、合并同类模块统计，或更多依赖定性证据，例如交接文档的使用痕迹、评审记录中接手人独立发表意见的情况、接手人复盘说明。结论中应注明样本不足，判断强度相应降低。
团队没有交接前的基线数据，怎么对比？
可以改用参照对象：同类模块、同团队其他成员在相近时间段的同类指标，或交接后前一个月与后一个月的自身变化趋势。使用参照对象时要在结论中注明替代口径，并说明参照对象与评估对象在任务难度、频率上的差异。基线缺失时，独立完成率这类新增指标更适合结合重复提问、升级求助比例等有历史记录的信号一起解读。
文档写得很全、培训也做了，为什么还不能算传承发生？
文档和培训属于知识形成层面的投入，说明原负责人已经把经验外化，但知识应用是否发生要看接手人在真实任务中的表现。判断依据应放在接手人能否独立完成任务、求助是否减少、交付质量是否稳定上。文档和培训记录可以作为过程参考和定性证据，不进入传承是否发生的核心判断。
评估取数时任务、缺陷、文档记录分散在不同工具里，怎么办？
先按口径卡列出每个信号需要的数据来源，再确认哪些记录可以关联到同一任务或模块。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应，文档实时同步并记录页面版本，团队可以把交接文档、复盘记录与对应任务放在同一关联结构中，减少人工拼接。评估口径和判断规则仍需团队按自身任务风险自行定义。
