收到“找不到资料”的反馈后，怎样写出一页改进方案？

同事说“资料太多，根本找不到”，你可能立刻想到增加搜索、做分类，或者接入智能推荐。但同一句抱怨，背后可能是名称难懂、入口隐蔽、权限不足，也可能是资料根本不存在。方案做得很快，却没有解决真正的问题，往往就从这里开始。

需求分析可以先交付一个小成果：一页能够回查证据、比较办法、约定检查方式的改进方案。它的作用是帮助团队决定下一步，而不是把猜测写得像结论。

先把抱怨还原为一次具体任务

下面是一个虚构示例：新客服在回复咨询前寻找一份双语资料，按课程名称搜索没有找到，最后向同事求助。这比“大家都觉得不好用”更适合分析，因为角色、任务和障碍已经可以观察。

接下来要补问：当时输入了什么词？用户在哪个入口操作？相关资料是否存在？换一个账号或设备能否找到？先记录原话、发生时间与观察来源，再写解释。

“课程名称和工作用词不一致”只是一个假设。如果资料不存在，增加别名不能解决问题；如果是权限异常，重新设计分类也可能无效。保留这些反例，是为了允许后来的证据改变判断。

假设目标是让新客服在咨询前找到相关资料，可以比较增加常用别名、提供岗位路线、展示搜索提示等办法。比较时不要只写优点，还要写每种办法依赖什么。

例如，岗位路线依赖有人维护课程与岗位的对应关系。搜索提示依赖可靠的提示词和结果。别名维护通常可以从少量常用词开始，但同一个词可能对应多份资料，需要检查歧义。这些都是待验证的工作条件，不是已证明的成本或收益。

如果暂时不知道哪种好，可以先做一个不改正式系统的小样。目标不是一次选出永远正确的答案，而是用较小投入排除一个重要的不确定性。