知识需求调研要交付的是一份能直接指导建设的结论：谁在什么业务场景下需要什么知识、目前从哪里获取、卡在哪里、先做哪些。调研范围先圈定业务线、角色与知识类型，再通过材料预审、访谈和现场观察收集线索，整理成“场景—知识—来源—缺口”的结构化清单，经评审排出优先级，最终形成调研报告和首批建设建议，作为知识库内容规划与组织机制设计的输入。
要点总览（TL;DR）
- 调研前先写范围说明：覆盖哪些业务线、角色、知识类型和时间窗，再按一线执行、业务骨干、管理者、知识维护四类角色准备问题清单。
- 收集分四步：材料预审找线索、访谈与现场观察收集场景、整理成场景—知识—来源—缺口条目、合并去重并标注频次与影响。
- 调研负责人、业务访谈人、知识维护角色和评审角色各有交付物与交接节点，分工在启动时定清可避免重复访谈和口径不一。
- 调研报告应给出优先场景、缺口清单、来源责任和首批建设建议，需求条目按状态流转并保留评审记录以便追溯。
- 收尾时用覆盖度、可追溯、可执行、有优先级、有确认五条标准逐项核对，未满足项明确补做动作。
调研前先定清楚：范围、对象与问题清单
调研铺得过宽是常见问题：访谈了十几个部门，记录了几十页，最后无法收敛成建设建议。启动前用一份范围说明把边界写下来，后续所有收集动作都围绕它展开。
范围说明至少包含四项内容：本次覆盖的业务线与部门、涉及的知识类型（如产品需求、技术文档、项目规范、操作说明、复盘记录）、调研时间窗，以及明确本次不覆盖的范围。时间窗建议与一个完整的业务周期对齐，例如覆盖一次版本发布或一个项目从立项到交付的全过程，这样访谈中提到的场景才有具体事件可依托。
调研对象按角色分层选取，每层关注的问题不同：
- 一线执行角色：日常在哪些环节需要查资料、查不到时怎么办、最近一次因信息缺失导致返工的情形。
- 业务骨干：关键流程中的判断依据、隐性经验目前以什么形式存在、哪些知识只有少数人掌握。
- 管理者：团队协作中的信息断点、新人上手周期、跨部门交接时的知识传递问题。
- 知识维护角色：现有文档由谁维护、更新频率、哪些内容已经过期但仍在被引用。
把调研意图转成问题清单时，按现状、痛点、期望三类分开写。现状类问题问“现在怎么做”，例如“新成员了解接口规范时，通常先看哪里”；痛点类问题问“哪里卡住”，例如“最近一次因为找不到某份文档而延误是什么情况”；期望类问题问“希望怎样”，例如“如果有一份随时可查的清单，你希望它包含哪些字段”。三类问题分开，访谈记录整理时更容易归类，也能避免把个人期望直接当成建设需求。
启动前还要收集已有材料：现有文档目录或页面结构、搜索关键词记录、工单与问题记录、培训材料与新人手册。这些材料在下一步预审中用于交叉验证访谈内容，也能提前暴露明显的知识空白。
本节产出两份文件：调研范围说明（含对象名单与时间安排）和访谈问题清单（按角色标注适用问题）。完成标志是范围说明经过调研负责人确认，问题清单在至少一次内部试问后修订定稿。
核心操作步骤：从收集到形成需求清单
从零散信息到可用清单，按四步推进。每步都有明确的输入、动作、输出和完成标志，避免调研停留在“聊过了、记下了”的状态。
第一步：材料预审，从已有文档与检索记录中找线索
输入是启动前收集的文档目录、搜索记录、工单和培训材料。动作是逐项浏览并标注三类线索：高频被访问或搜索的内容、长期未更新但仍被引用的内容、反复出现在工单或提问中的问题。输出是一份预审线索表，每条线索注明来源位置和初步判断。完成标志是线索表覆盖全部已收集材料，且每条线索都能指向具体文件或记录。
第二步：访谈与现场观察，按问题清单收集场景化需求
输入是问题清单和访谈对象名单。访谈时围绕具体事件追问，请对方描述最近一次真实经历：当时在做什么任务、需要什么信息、从哪里找、找到没有、最后怎么解决。现场观察补充访谈中说不清的部分，例如实际工作中打开哪些系统、在哪个环节停下来询问同事。输出是访谈记录和观察笔记，记录中保留原话和具体场景，不做即时归纳。完成标志是目标角色每类至少完成约定数量的访谈，且每条记录标注了受访角色、时间和对应业务场景。
第三步：把原始记录整理成结构化条目
输入是访谈记录、观察笔记和预审线索表。动作是把每条需求拆成四个要素：场景（什么业务情境下发生）、知识对象（需要的是什么内容，如接口规范、验收标准、操作步骤）、现有来源（目前从哪里获取，或标注“无”）、缺口（现有来源哪里不够用，如缺失、过期、分散、口径不一）。输出是结构化条目表。完成标志是每条条目都能追溯到具体的访谈记录或预审线索，四个要素填写完整，缺口描述具体到可判断的程度。
第四步：合并去重、标注频次与影响，形成需求清单初稿
输入是结构化条目表。动作包括：合并描述同一知识对象的重复条目；统计每个条目被多少受访角色提及（频次）；标注影响范围，例如影响单个岗位、一个团队还是跨部门交接；对每条给出建议优先级及理由。输出是需求清单初稿。完成标志是清单中不存在重复条目，每条都有频次和影响标注，优先级排序有可复核的依据而非平均罗列。
角色分工与各环节交付物
调研涉及多个角色，分工不清会导致访谈重复、结论口径不一。下表按环节列出责任角色、交付物和交接节点，可直接作为调研启动时的分工依据。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 调研负责人 | 统筹范围、进度与结论口径，主持评审 | 调研范围说明、调研报告 | 启动时确认范围；评审后定稿报告 |
| 业务访谈人 | 按角色分工执行访谈与现场观察并记录 | 访谈记录、观察笔记 | 访谈完成后移交整理人 |
| 知识维护角色 | 确认现有知识来源、更新责任与内容状态 | 来源确认意见（哪些有效、哪些过期、谁负责更新） | 结构化整理阶段提供来源核实 |
| 评审角色 | 对需求清单的优先级与可行性给出意见 | 评审意见与优先级确认 | 清单初稿完成后参加评审会 |
访谈人按业务线或角色分组，同一受访对象只安排一次访谈，避免重复打扰。知识维护角色的介入时机在结构化整理阶段，由其对每条条目的“现有来源”做核实，确认来源是否仍然有效、更新责任人是谁。评审角色通常由业务负责人和知识库建设负责人共同担任，评审会上逐条确认优先级，对争议条目记录理由。调研负责人对最终结论口径负责，报告定稿前确保各角色对关键结论无异议。
示例：一条知识需求如何从访谈记录变成建设条目
以下为演示情景，用于说明转换过程，非真实客户案例。
原始访谈记录大致如下：“测试同事提到，新版本上线前要确认接口变更影响范围，现在靠问开发或者翻聊天记录，上次就因为漏了一个下游系统，回归测试范围没覆盖到，上线后才发现。希望能有一份接口变更影响清单，每次变更时更新。”
转换为四要素条目：
- 场景：版本上线前的回归测试范围确认。
- 知识对象：接口变更影响清单，包含变更接口、受影响的下游系统与模块、需回归的测试范围。
- 现有来源：开发人员口头告知、历史聊天记录，无固定文档。
- 缺口：信息分散在个人和聊天工具中，无统一清单，变更时无人负责更新，导致遗漏下游系统。
补充频次与影响：该问题在测试角色访谈中被多次提及，影响范围为测试团队与相关下游系统的联调环节，遗漏会直接导致上线后缺陷。建议优先级为高，理由是影响交付质量且现有来源不可靠。
该条目进入内容规划时，对应一项待建设知识：接口变更影响清单模板及更新机制，责任角色为接口负责人或版本发布协调人，更新触发点为每次接口变更评审。后续在内容规划中，它与“发布检查清单”“回归测试范围模板”等条目一起，构成版本发布场景的知识建设包。
调研结论如何衔接知识库建设与协作管理
调研报告是调研的最终交付物，应包含四类结论：优先建设的业务场景及其排序依据；按场景归类的知识缺口清单；每项缺口对应的来源责任角色；首批建设建议，包括先建哪些内容、由谁负责、大致节奏。报告不展开运营成效评估，那属于知识库上线后的独立工作；也不涉及工具选型对比，选型应在需求明确后单独进行。
需求条目在评审后进入建设过程，需要状态流转：待评审、已确认、建设中、已上线、暂缓。每个状态对应责任人和时间节点，评审记录保留在条目上，便于后续追溯为什么某项需求被排在高优先级或暂缓。条目在流转中可能被拆分或合并，版本记录帮助回溯调整过程。
当团队使用 ONES 承载这一过程时，调研结论中的需求条目可以作为工作项管理，责任人与评审意见随条目流转；对应的知识内容在 ONES Wiki 中按页面树组织，页面组可关联项目，使需求条目与文档互相对应。ONES Wiki 支持记录页面版本并随时查看与回滚，便于在建设过程中保留内容修订痕迹；文档与项目、任务场景结合使用，可以让需求条目、建设文档和评审记录保持关联。这样调研结论从一份报告变成可持续跟踪的建设清单，而不是归档后不再更新的文件。
完成检查：调研是否可交付
调研结束前逐项核对以下五条，全部满足即可进入建设阶段；有未满足项时，明确补做动作再收尾。
- 覆盖度：范围说明中列出的目标角色和业务场景是否都有访谈或观察样本，缺失的样本是否说明了原因。
- 可追溯：随机抽取需求清单中的条目，能否回到具体的访谈记录、观察笔记或预审线索。
- 可执行：每条条目是否写明了知识对象、现有来源和责任角色，缺口描述是否具体到可判断建设内容。
- 有优先级：排序是否附有频次、影响范围等依据，是否存在大量条目并列同一优先级而无区分理由。
- 有确认：调研负责人、业务负责人和知识维护角色是否对优先场景与首批建设建议达成一致，异议是否记录在案。
这份检查清单同时可作为调研报告的附录，让报告的使用者了解结论的覆盖范围与局限，也为后续建设阶段的验收提供参照。
常见问题
调研对象只覆盖一线执行角色，结论够用吗？
通常不够。一线执行角色能提供具体场景和卡点，但隐性经验、跨部门交接问题和现有文档的维护责任，往往要由业务骨干、管理者和知识维护角色补充。如果时间有限，可以优先保证一线与业务骨干的样本，管理者和知识维护角色至少各安排少量访谈，并在报告中说明样本覆盖的局限。
访谈记录很多，整理时先合并还是先拆条目？
建议先拆后合。先把每条原始记录拆成场景、知识对象、现有来源、缺口四个要素，拆的过程中会发现同一知识对象在不同访谈中被反复提到，这时再合并去重，并统计频次和影响范围。先合并容易把不同场景的需求混成一条，后续评审时难以判断优先级。
调研结论中的需求条目，后续怎么跟踪才不流于形式？
关键是让条目带上状态、责任人和评审记录。评审后条目进入待确认、建设中、已上线或暂缓等状态，每次状态变化对应责任人和时间节点。团队使用 ONES 时，可以把需求条目作为工作项管理，评审意见随条目流转，对应的知识内容在 ONES Wiki 中按页面树组织，页面组可关联项目，使条目与文档互相对应，页面版本记录也便于回溯内容修订过程。
调研做到什么程度可以停下来进入建设？
以能否支撑建设决策为准，而不是以访谈数量为准。目标角色和业务场景都有样本、每条需求能回到原始记录、条目写明了知识对象与来源责任、优先级有排序依据、关键角色对结论达成一致，这五条满足即可收尾。若某条不满足，明确补做动作和时间，不必无限延长调研周期。
调研结论和上线后的效果评估是什么关系？
调研结论回答“先建什么、由谁建”，效果评估回答“建了之后有没有被用起来、有没有解决问题”。两者使用不同的指标和时间点：调研阶段记录缺口与优先级依据，上线后另行设定使用情况与业务影响的观察口径。把评估指标提前写进调研报告作为参照可以，但调研本身不承担运营评估的结论。
