需求还是bug？

在为客户提供咨询服务时，我经常被问到如何区分“需求”和“Bug”。争议的核心往往出现在开发人员与产品人员（或客户）之间：开发人员认为这是“需求变更”，而产品或客户则认为这是一个“Bug”——既然是Bug，就应该无偿修复。双方立场不同，分歧由此产生。

那么，究竟应该如何科学、清晰地判断呢？

一个简单的判断法则

• Bug：产品做了它不该做的事，或没做它本该做的事，即违反了已有约定或规范。
• 需求：产品想做某件新的事，或想改变现有的约定，即提出了新的或变更后的期望。

换句话说：

• 需求，描述的是产品尚未实现或需要变更的能力或行为，是关于“产品应该做什么”的期望。
• Bug，描述的是产品已经实现的功能中，存在与设计不符、运行异常或导致错误的问题，是关于“产品做了什么但没做好”的问题。

1. 核心判断：有没有“白纸黑字”的约定？

2. 场景测试法：问三个问题

当遇到边界模糊的情况时，可以问自己和团队以下三个问题：

1）“写进合同/文档了吗？”（或：原型图、PRD上有没有明确写？）
有，但没实现 → Bug
没有，或写的是另一回事 → 需求（或需求变更）
2）“是不是产品经理自己也认为该有这个功能？”（有时文档会遗漏）
产品经理回想后说：“对，这个确实该有，当时漏写了。” → Bug（本质上是文档缺失导致的缺陷）
产品经理说：“这个想法不错，但之前没考虑过。” → 需求
3）“换个角度看，用户会觉得这是‘坏了’，还是‘想要更多’？”
用户抱怨：“这功能怎么不工作？” → Bug
用户建议：“要是还能……就更好了。” → 需求

3. 常见的模糊地带与处理建议

实际工作中，总有一些边界模糊、容易引发争议的情况，需要特别处理：

• 性能问题：页面加载需要5秒，但PRD中没有明确要求。
  1. 建议：如果慢到明显无法接受（例如10秒），可视为Bug（质量缺陷）。如果只是从“1秒优化到0.5秒”，则通常属于性能优化需求。
• 体验不友好：流程虽然能走通，但步骤繁琐、容易误操作。

建议：如果没有交互规范约定，一般算作优化需求。但如果已导致用户频繁出错，则可视为Bug。

• 未提及的边缘情况：输入特殊字符导致系统崩溃。

建议：即使PRD没有写明，也通常算作Bug——因为“不崩溃”是软件应有的基本质量预期。

• 修复Bug引发的副作用：修好A问题后，原本正常的B功能出问题了。

建议：B功能损坏属于Bug（回归缺陷），无论B是否在文档中有明确说明。

4. 常见场景辨析

5. 一句话实操建议（面向开发与测试）

• 开发说“需求没写” → 先判断是否为常识性、显而易见的功能（如“点击保存应存储数据”）。如果是常识 → Bug；否则 → 需求澄清。
• 测试报“功能不符合直觉” → 先查阅文档。若文档未定义 → 提需求建议，而非Bug。
• 产品说“我原来就是这么想的，只是没写下来” → 按Bug处理（同时允许产品补充文档）。这有助于倒逼文档完善。

总结

Bug = 违背了已有的、明确的或合理预期的行为。

需求 = 提出了一个尚未被约定的新行为或改变。

最关键的判断依据，是对照基准（设计/文档）和影响性质（破坏现有功能 vs. 提出新期望）。在实际工作中，清晰记录产品设计、积极与提出方沟通确认，是减少分歧的有效方式。

但比“如何区分”更重要的，其实是流程机制：

• 建立一个三方（产品、开发、测试）快速裁决机制：遇争议时，由产品经理最终拍板是“Bug”还是“需求”。
• 如果是需求，走需求变更流程（评估工作量、排期）。
• 如果是Bug，进缺陷跟踪系统（优先修复）。

这样既能避免无谓争论，也能保护团队不把“需求变更”当作“免费Bug”来修。