建立需求、测试、缺陷、知识四域能力清单，关键是把“现状”和“目标”放在同一套能力项与判定标准下对照，而不是各写一份互不对应的材料。做法是先拆能力项并统一字段，再用配置、导出数据、抽样和访谈取证现状，从具体业务场景反推目标等级，逐项比对后把差距转成替换、优化或培训配置动作。清单经各域负责人和决策角色确认后，才能作为工具替换评估的输入。
要点总览（TL;DR）
- 把需求、测试、缺陷、知识四个域拆成可观察的能力项，每个能力项配一条可复核的判定标准，现状列与目标列共用同一套字段和三档等级。
- 现状等级靠证据判定：配置截图、字段与工作流导出、历史数据抽样、访谈记录四类证据配合使用，并区分能力缺失与使用不到位。
- 目标等级从具体业务场景和角色任务反推，写明触发条件、验收方式和优先级，把必须达成项收敛到支撑核心场景的最小集合。
- 逐项比对后把差距分为能力缺失、能力不足、使用不到位三类，分别对应替换、优化、培训与配置调整，每条差距记录证据编号、影响范围和责任角色。
- 清单交付前逐项核对证据与等级无空项，经四域负责人和决策角色确认后，才能作为替换评估的输入。
先定评估口径：四域能力项怎么拆
能力清单能否用于替换评估，取决于现状列和目标列是否可比。可比的前提是同一能力项只出现一次、判定标准只有一套、字段顺序固定。拆解时按需求、测试、缺陷、知识四个域分别展开，每个域都覆盖记录、流转、追溯、查询与权限五类动作，避免只列功能名称而漏掉协作环节。
以需求域为例，记录类能力项可写为“需求条目可结构化录入并区分类型与优先级”，流转类写为“需求状态变更可按既定流程执行并留下操作记录”，追溯类写为“需求可关联下游任务、用例与缺陷”，查询类写为“可按负责人、状态、版本组合筛选需求”，权限类写为“不同角色对需求的查看与编辑范围可配置”。测试、缺陷、知识三个域按同样方式展开，形成一张横向覆盖四域、纵向覆盖五类动作的拆解表。
每个能力项必须配一条判定标准，标准要能被第三方复核。把“缺陷管理好用”改成“缺陷从提交到关闭的每个状态变更都有操作人、时间和备注记录”，把“知识库强大”改成“知识文档可按空间或目录设置查看与编辑权限”。判定标准写不清的能力项，说明拆得还不够细，应继续下切到可观察的系统行为。
统一字段建议固定为八列，所有域共用同一张表结构：
| 字段 | 填写要求 |
|---|---|
| 能力项 | 一个能力项只描述一个可观察动作，不合并多个诉求 |
| 所属域 | 需求、测试、缺陷、知识四选一 |
| 判定标准 | 可复核的系统行为或数据结果，不用形容词 |
| 现状等级 | 已具备、部分具备、不具备三档之一 |
| 证据 | 证据编号，对应截图、导出文件、抽样记录或访谈纪要 |
| 目标等级 | 与现状同一套三档口径 |
| 差距类型 | 能力缺失、能力不足、使用不到位 |
| 动作 | 替换、优化、培训或配置调整，写明责任角色 |
字段定好后先冻结，后续取证和比对都在这张表上填写。中途新增字段会导致已填内容返工，因此建议先用两三个能力项试填，确认字段够用再全面铺开。
建立现状清单：证据从哪里取、等级怎么定
现状清单的价值在于可复核，因此每条等级结论都要挂证据编号。证据来源主要有四类：系统配置截图，用于证明字段、状态、权限的实际设置；字段与工作流导出，用于证明流转路径和必填项；历史数据抽样，用于证明追溯关系和记录完整性；访谈记录，用于补充系统里看不到的操作习惯和变通做法。四类证据配合使用，单靠访谈容易把个人印象当成系统能力。
现状等级按三档判定，每档都要写明判定依据。已具备指判定标准描述的行为在系统中完整存在且被实际使用；部分具备指行为存在但覆盖范围有限，例如追溯关系只能单向建立，或权限只能按项目设置而不能按目录设置；不具备指系统中找不到对应配置，也没有替代操作方式。判定时以证据为准，不以使用者的满意度为准。
取证过程中最容易出现的偏差，是把使用不到位误判为能力缺失。系统支持状态流转但团队长期跳过评审节点，属于使用不到位；系统根本没有评审节点配置，才属于能力缺失。区分方法是先查配置是否存在，再抽样历史数据看实际执行比例。配置存在而执行率低，证据应记录为“配置具备、抽样执行率偏低”，等级定为部分具备，动作指向培训或流程约束，而不是替换工具。
建议为每个域建立一份证据清单，按证据编号登记来源、采集人、采集时间和对应能力项。抽样数据要写明样本范围和抽样方法，例如“近三个月缺陷单随机抽取五十条，检查关联需求字段填写率”。证据清单与能力清单用同一编号体系，后续比对时可以直接引用。
建立目标清单：从业务需求反推目标等级
目标清单常见的失败是变成愿望清单：每项都写“需要具备”，结果无法据此判断替换范围。可行的做法是从具体业务场景和角色任务反推。先列出未来一到两年内必须支撑的场景，例如版本发布前需要按需求维度统计测试覆盖和缺陷分布，再拆出该场景涉及的角色任务，最后落到能力项和目标等级。场景没有涉及的域，目标等级可以不提升。
每个目标项要写清三件事：触发条件、验收方式、优先级。触发条件说明什么情况下这项能力必须到位，例如“当同一需求跨两个以上团队交付时，需要双向追溯”；验收方式说明如何确认目标达成，例如“抽取一个跨团队需求，能在系统中从需求查到全部关联用例和缺陷”；优先级用于控制替换范围，分为必须达成和可延后两档。
必须达成项建议控制在能够支撑核心场景的最小集合，其余列入可延后。可延后项在替换评估中作为观察项记录，不进入本期动作。这样做的目的是让清单能指导决策，而不是把所有理想能力都压进一次替换。目标等级同样使用已具备、部分具备、不具备三档，与现状列保持同一口径，否则比对时无法计算差距。
逐项比对：差距分类与记录方式
比对按能力项逐行进行，同一行左边是现状等级，右边是目标等级。目标高于现状即为差距项，目标等于或低于现状则记录为无差距，并在备注中说明维持现状即可。差距项不直接写“需要新工具”，而是先分类，再定动作。
| 差距类型 | 判断依据 | 对应动作 |
|---|---|---|
| 能力缺失 | 系统中无对应配置，也无替代操作方式 | 评估替换或在目标工具中确认该能力 |
| 能力不足 | 配置存在但覆盖范围或深度达不到目标 | 优化配置、补充流程或评估扩展能力 |
| 使用不到位 | 配置具备，历史数据或访谈显示执行率低 | 培训、流程约束与执行检查 |
每条差距记录要包含证据编号、影响范围和责任角色。影响范围写清受影响的场景和团队，例如“影响跨团队版本发布时的覆盖统计”；责任角色写清由谁推进动作。差距分类的意义在于把替换需求收敛到真正缺失的能力上，避免因为执行问题启动不必要的工具更换。
在需求、测试、缺陷、知识四域的记录与追溯环节，清单本身也需要一个承载位置。ONES 的工作项与文档管理方式可以作为落地载体：测试用例可与需求、任务关联，测试计划与迭代关联；未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试报告可自动生成，并提供项目缺陷分布统计；用例库和测试计划可单独配置权限。这些能力对应清单中的追溯、流转和权限类能力项，便于在评估时用实际配置核对现状等级。知识域若涉及从 Confluence 迁移，ONES 可将空间、页面、附件和权限结构迁移到 ONES Wiki，保留原有知识组织方式，迁移前仍需逐项确认定制场景的对应关系。
角色分工与交付物：谁填、谁审、谁拍板
清单涉及四个业务域和一套工具配置，需要明确填写、审核和决策三类角色，否则容易出现各域口径不一致、证据缺失或结论无人确认的情况。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求域业务负责人 | 填写需求域能力项、现状等级与目标等级 | 需求域能力清单与证据编号 |
| 测试域业务负责人 | 填写测试域能力项，提供用例与计划关联的抽样证据 | 测试域能力清单与抽样记录 |
| 缺陷域业务负责人 | 填写缺陷域能力项，核对缺陷流转与统计口径 | 缺陷域能力清单与流转记录 |
| 知识域业务负责人 | 填写知识域能力项，核对文档权限与检索使用情况 | 知识域能力清单与访谈纪要 |
| 工具管理员 | 提供系统配置截图、字段与工作流导出、历史数据抽样 | 证据清单与配置说明 |
| 架构或平台负责人 | 审核四域判定标准与字段口径的一致性 | 口径审核意见 |
| 决策角色 | 确认必须达成项、可延后项与替换范围 | 确认后的目标清单与替换范围说明 |
各阶段交付物按顺序衔接：四域能力项拆解表完成后进入取证，证据清单齐备后填写现状等级，目标清单经决策角色确认后开始比对，差距比对表完成后进入完成检查。每个阶段的输出都是下一阶段的输入，缺少任一交付物都会导致后续结论无法复核。
示例：一条缺陷域能力项的完整比对记录
以下为演示情景，用于说明填写方式，不代表任何实际评估结论。
| 字段 | 填写内容 |
|---|---|
| 能力项 | 缺陷与需求可双向追溯，从缺陷可定位关联需求，从需求可查看关联缺陷 |
| 所属域 | 缺陷 |
| 判定标准 | 缺陷单存在关联需求字段且可跳转；需求详情页可列出关联缺陷清单；抽样缺陷单中关联字段填写率可统计 |
| 现状等级 | 部分具备 |
| 证据 | E-07 缺陷字段配置截图；E-08 近三个月缺陷单抽样五十条，关联需求字段填写率约六成；E-09 需求详情页无关联缺陷列表 |
| 目标等级 | 已具备 |
| 差距类型 | 能力不足与使用不到位并存 |
| 动作 | 由工具管理员确认需求侧关联缺陷的展示配置；由缺陷域负责人推动关联字段必填与提交检查；两项完成后重新抽样验证填写率 |
这条记录进入决策的方式是：先看差距类型中是否包含能力缺失，本例中配置层面存在关联字段，主要问题在展示与执行，因此动作指向配置优化和流程约束，替换需求优先级较低。若抽样显示系统完全没有关联字段且无法配置，则差距类型改为能力缺失，动作转为在目标工具评估中确认该能力，并纳入替换范围讨论。
完成检查：清单可用性的核对项
清单交付前逐项核对，通过标准是清单能直接作为替换评估的输入，而不是需要再补一轮材料。
- 每个能力项都有判定标准、证据编号和现状等级，无空项；判定标准中不出现“好用”“强大”等无法复核的描述。
- 现状等级与目标等级使用同一套三档口径，同一能力项在两列中的含义一致。
- 每条差距项都有差距类型和建议动作，动作写明责任角色；能力缺失项已单独汇总，作为替换范围讨论的依据。
- 必须达成项已由决策角色确认，可延后项已标注，替换范围有明确边界。
- 证据清单与能力清单编号对应，抽样记录写明样本范围和方法，访谈纪要注明时间和对象。
- 四域负责人已确认本域内容，架构或平台负责人已出具口径审核意见。
核对完成后，清单与差距比对表一并归档，作为后续工具替换评估、配置优化和培训安排的共同依据。若核对中发现某域证据不足，应回到取证阶段补充，而不是在比对阶段用推测填补等级。
常见问题
四个域的能力项数量应该控制在多少，拆得太细会不会反而难比对？
能力项数量没有统一标准，判断依据是清单能否支撑比对和决策。一个实用的控制方法是：每个域先覆盖记录、流转、追溯、查询与权限五类动作，每类动作保留一到三个与核心场景直接相关的能力项，其余作为候选记录在附表中。
拆得过细的典型表现是同一系统行为被拆成多条，比对时重复计算差距；拆得过粗则一条能力项里混着多个诉求，等级无法判定。建议先用两三个能力项试填，确认判定标准能被第三方复核，再按同一粒度铺开其余能力项。
现状取证时，业务负责人和工具管理员的判断不一致怎么办？
以证据为准，不以职位或印象为准。出现分歧时，先回到判定标准，确认双方讨论的是同一个系统行为；再核对证据，配置截图和导出数据能证明系统是否具备该行为，抽样数据能证明实际执行比例。
如果配置存在而执行率低，等级定为部分具备，差距类型记为使用不到位，动作指向培训或流程约束；如果配置不存在且无替代操作方式，才记为能力缺失。分歧记录连同双方证据一并保留，由架构或平台负责人按统一口径裁定，避免同类问题在不同域反复出现。
目标清单里必须达成项太多，替换范围收不住，怎么取舍？
先检查每个必须达成项是否挂在一个明确的业务场景上。找不到对应场景的目标项，通常应降为可延后或直接删除。剩下的必须达成项再按触发条件排序：在近期版本发布、跨团队交付等场景中已经产生实际阻塞的排在前面，尚未发生但可预见的排在后面。
取舍的结果要写进清单，注明哪些项本期不进入动作、作为观察项记录。这样替换范围有明确边界，后续评估也不会因为目标清单反复扩张而返工。
差距比对完成后，怎么判断应该替换工具还是先做优化？
看差距类型中能力缺失项的比重和分布。如果能力缺失集中在少数能力项，且这些能力项不影响核心场景，优先做配置优化、流程约束和培训；如果能力缺失覆盖多个域的关键追溯或流转环节，且现有系统没有替代操作方式，才把替换纳入讨论。
能力不足和使用不到位两类差距一般不构成替换理由，分别对应配置优化和执行改进。比对表里把能力缺失项单独汇总，作为替换范围讨论的依据，可以让决策集中在真正缺失的能力上。
清单里的证据需要保留到什么程度，评估结束后还要维护吗？
证据清单与能力清单用同一编号体系登记，至少保留到替换决策完成并归档。抽样记录要写明样本范围、抽样方法和采集时间，访谈纪要注明对象和时间，配置截图注明采集时的系统状态，便于后续复核时判断结论是否仍然成立。
如果评估周期较长，建议在比对前对关键能力项的证据做一次时效检查，配置发生变更的能力项重新取证。清单归档后可作为下一轮评估的基线，但等级结论需要按当时的证据重新确认。
