需求还是bug？

文章主旨：

区分“需求”与“Bug”的核心依据是是否有明确的约定（文档/合同）或合理预期，违反约定或导致功能受损为Bug，提出新期望或改变为需求。

关键要点：

• Bug = 产品做了不该做的事/没做该做的事（违背已有约定或合理预期）；需求 = 产品想做新的事/改变现有约定。
• 判断基准：对照已有文档（PRD、原型图、设计稿），有但未实现 → Bug；没写或写的是另一回事 → 需求。
• 场景测试三问：1）写进合同/文档了吗？2）产品经理是否自己也认为该有？3）用户觉得“坏了”还是“想要更多”？
• 模糊地带（性能、体验、边缘情况、回归缺陷）需结合基本质量预期和实际影响综合判定。
• 建立三方快速裁决机制（产品最终拍板），需求走变更流程，Bug进缺陷跟踪。

内容结构：

1. 引言：提出“需求 vs Bug”的常见争议场景，即开发与产品立场不同。
2. 核心判断法则：定义Bug与需求，强调“白纸黑字”的约定是首要依据，并用三个表格对比依据、示例。
3. 场景测试法：提出三个问题（文档、产品经理记忆、用户视角）辅助判断。
4. 常见模糊地带与处理建议：分别讨论性能问题、体验不友好、未提及的边缘情况、修复Bug引发的副作用，并给出具体建议。
5. 常见场景辨析：通过6个具体场景（如点击崩溃、导出格式、按钮颜色、兼容性、流程繁琐等）明确分类理由。
6. 一句话实操建议：面向开发/测试/产品三方的具体行动准则，强调文档缺失时如何区分常识性Bug与需求。
7. 总结：重申Bug与需求的定义，并指出比区分更重要的流程机制（三方裁决、需求变更流程、缺陷跟踪）。

文章总结：

本文以清晰的定义和可操作的问题列表帮助团队科学区分需求与Bug，最终落脚于建立流程机制以减少争议、提升协作效率。

花几百万买个BI系统，打水漂了……

了解更多

麦哲思科技任甲林

查看原文：需求还是bug？

文章来源：

麦哲思科技任甲林

扫码关注公众号