如何做需求文档分析

之前组内的小伙伴在研究如何利用AI进行需求文档分析（大致的技术方案是多角色、多agent、多轮交叉审核），自然而然，我们想到可以将QA已有的经验作为输入的上下文之一，帮助产出更高质量的结果。之前没有系统性的回顾过这块的想法，借这个机会，我也重新梳理了自己对需求文档分析的理解。

不得不说，传统的需求分析正在“瓦解”，至少在我目前所在的项目。有时候甚至出现策划发了需求文档后，立马进行需求评审的情况，其他职能走进会议室的时候，还不知道这个需求是什么，需求评审会议更多的是由策划进行讲解，其他职能现场进行吸收和提问。理论上的需求评审，一般是程序，美术，QA接到需求文档后，在1天的左右时间内各自进行阅读，提问，将一些简单疑问在会议前进行确认好，在会议上，只对复杂的、有矛盾的内容进行探讨。想要做好需求分析是难度很大的事情，需要丰富的测试经验和游戏体验，大部分QA在需求评审会上几乎不会发言，只是被动的接受输入，一方面可能是性格，但更多的是能力导向，而这块的能力建设，需要长期的培养和自我驱动，难度不小。有时候需求评审会议会将QA遗忘，这里固然是上游存在问题，但其实也有一部分原因是QA长期无法在需求评审会上发表建议，存在感低，久而久之导致无人关注到QA是否参加。

需求评审的重要性不言而喻，通过评审发现需求的缺陷，从而大大降低后续的研发风险和制作成本，像互联网行业，还有专门的技术评审等好几轮需求评审。敏捷的本质是缩短反馈周期、快速验证和持续迭代，而不是让模糊需求直接进入开发，需求分析时间被压缩是现实，QA更需要建立一套高效、结构化的分析方法：即使只拿到半小时，也能迅速抓住最核心的风险点，在评审会上提出有价值的问题。将固有的经验，转换成Spec，利用AI进行需求分档分析，提升分析质量和速度，是一个非常不错的方向（这里有一个前提，本文不做讨论：就是如何将传统的需求文档，转化成更容易被AI读懂的文档形式）。下面我将个人对需求分析理解的一些checklist点进行简单的阐述。

第一是要明确和理解设计意图。不少需求文档里没有写这个需求的设计目的是什么，该功能要解决什么玩家问题。如果目标不明确，后续规则很容易变成为了实现而实现。但在实际工作中，我们常常忘记这个。当文档没有写明目标时，QA 可以提出这个非常有价值的问题：“这个功能最希望改善什么指标或解决什么问题？”这个问题看似不直接属于测试，但能够帮助团队判断许多规则是否合理。假设我们要做一个活动：

如果目标是促进日活，那么任务门槛应当让目标玩家群体有机会完成；是否容易理解、容易完成、愿意重复使用；
如果目标是引导新玩法，那么任务描述、跳转入口和奖励设计应当降低尝试成本；
如果目标是回流玩家，那么任务的奖励是否有足够吸引力；对于玩家追赶进度是否有大幅帮助；

第二是需求合理性：主要包括设计的合理性（是否是玩家真实需求，是否符合游戏背景，是否符合现实世界）和数值合理性。

在理解和对齐了设计意图后，合理性自然而言就会浮现出来（前提是QA对游戏有比较深入的外网体验），包括UI布局、操作、文案、剧情的合理性，还有一类是和游戏内的其他系统的冲突性，因为策划也是分职能的，很可能设计出来的需求和之前的某个需求是冲突的，这也是我们在做需求评审的时候，希望所有的QA都参与进来的原因。比如对于新手流程的优化需求，可能应该和活动开启等级的限制冲突；对于充值入口的调整，可能和渠道审核的要求冲突等。在用户体验层面，比如操作交互是否违反了一致性等交互理论，或者和市面上热门游戏操作相反的情况。

我们常常会说，QA做久了就容易忘记了玩家这个最原始的身份标签。我们可以尝试把自己带入到三个角色的情景之中：新玩家、老玩家、极端玩家。对于新玩家要注意的合理性，比如：功能解锁条件是否清楚；引导是否打断正常游戏节奏；文案是否使用过多内部术语；首次体验是否能快速获得正反馈；当玩家暂时无法参与时，是否说明原因和达成路径；是否有足够的引导帮助玩家进入和理解新的系统。对于老玩家要注意的合理性，比如：历史道具是否仍可使用；已完成的任务、已购买的商品、已培养的角色如何兼容；原操作是否突然变化导致认知成本上升。对于极端玩家，这里可以理解为工作室账号，很多游戏和工作室是深度绑定的，是游戏生态的重要一环，可以注意的合理性，比如：是否可以通过重复进出、取消确认、切换账号等方式规避限制；是否可以利用小号、组队关系、交易关系获取异常收益；这不是假设玩家“恶意”，而是承认玩家会按照系统允许的方式追求最优收益。

QA应具备基础的数值风险意识。这里的重点并不是判断“100元宝还是120元宝更合理”，而是识别明显失衡的规则。比如投入与产出是否匹配；免费玩家、轻度付费玩家和高付费玩家的体验差异是否过大；是否会破坏已有经济系统；是否允许小号；产出是否可交易；是否远高于或者远低于其他同类型的玩法\活动的价值产出。

第三是需求完整性：当某个需求不完整时，对于技术人员来说工作量是减少了，但是后期产品测试或者上线可能会带来更多的麻烦。因此在需求评审时，我们要关注需求是否是完整的。例如需求中写“活动期间完成任务可领取奖励”，至少还应明确：

活动结束后未领奖的奖励是否补发；
任务在结束前完成、结束后领取是否允许；
红点的规则是怎么样的

这些问题并不“吹毛求疵”。线上玩家不会因为文档没写就不触发边界场景。项目中很多需求会写“复用XX活动框架”，“沿用XX礼包逻辑”，“参考XX玩法”。这类描述能节省篇幅，但也容易让团队对“复用范围”产生不同理解。例如复用一个旧活动框架时，旧框架可能默认“奖励只能领取一次”，“不支持跨服”。如果新需求隐含了多轮领取、跨服需求，开发后期才发现框架不支持，就很容易产生返工。我们应主动确认：

复用的是界面、配置、服务端逻辑，还是完整流程？
原系统有哪些限制，新需求是否会突破这些限制？
原系统中已知的问题是否会被带入？
复用后哪些规则继承，哪些规则需要覆盖？

第四是异常项：异常处理是需求分析中最重要的部分。正常流程通常人人都会想，真正拉开分析质量差距的，是对异常、并发和极端场景的覆盖（也是QA参与需求分析的价值所在）。常见的一些异常清单比如：断线、重连、切后台、闪退；顶号、多端登录、重复点击、并发请求；跨天、跨周、活动开始和结束瞬间；队伍解散、队长转移、成员离队、匹配超时；背包满、道具过期、货币不足、奖励重复；第三方服务超时、不可用。以组队玩法为例，需求中如果只描述“队长开启副本，队员参与后获得奖励”，还需要补充：开启后队长掉线或转让队长怎么办；队员在战斗开始前、战斗中、结算前退出，奖励如何计算；队员网络异常但服务端已结算，重连后如何补发；队伍成员不满足进入条件时，是禁止组队、禁止进入，还是允许旁观；跨刷新点时副本次数、奖励次数和队伍状态如何处理。

在异常发生时，给玩家的信息提示在游戏中是十分重要，就好比家里灯突然灭掉了，你的第一反应是什么？当然是想知道是停电了？还是灯坏了？此时若有明确的信息告诉你原因，感受是不是有很大的不同？当你分析一份文档时，如果发现提示信息很少，往往意味着异常场景尚未被充分考虑，QA可以据此展开追问。QA不能只关注系统“有没有兜底”，还要关注玩家“知不知道发生了什么”。如果玩家点击领取奖励后没有任何反馈，他无法判断是背包满、资格不足、活动结束，还是系统出错。明确、可行动的信息提示能显著降低玩家困惑。好的异常提示通常应包含三部分：发生了什么；为什么发生；玩家接下来可以做什么。例如“领取失败”信息价值较低；“背包空间不足，请清理背包后重试”则明确给出了原因和行动路径。

第五是产品性能：QA不需要成为所有领域的专家，但应知道什么类型的需求可能带来性能风险。比如大量玩家同时参与的活动；全服排行榜；跨服匹配；世界事件；高频刷新或高频请求的界面；大量特效等。尽早同步负责性能（客户端性能/服务器性能）的同学，准备好相关的测试环境

第六是实现方案：这一块是QA做的比较少的。要勇敢和程序对接，请教相关实现的机制和方案，有的程序同学写代码喜欢另辟蹊径，写出各种复杂奇特的代码，导致QA同学后期测试苦不堪言，还容易出Bug。代码尽量是高可拓展得、可复用得。质量是被设计出来的，而不是测出来的。策划配置也需要注意，很多功能开发得时候，喜欢自己维护一个策划表，但有些数据其实是已经存在，要尽量公用，这样后续得可维护性也会高很多，避免以后出现这里改了，那里没改得情况。

第七是日志的健全性：线上很难避免不出现bug，或者玩家反馈，以及线上投放监控、玩法效果统计等。这个时候就需要完善得日志进行查询和监控。

需求文档分析是一项长期能力，不会因为参加几次评审就立刻提升。它依赖于测试经验、游戏体验、技术理解、业务认知，以及持续复盘的习惯。对QA来说，需求评审的目标不是证明自己能发现多少问题，而是尽可能在开发前让团队对“要做什么、怎么做、异常怎么办”达成一致。当QA能够从合理性、完整性、异常边界、用户体验、性能、实现成本、拓展性等多个维度提出具体问题时，需求评审中的角色就不再是被动接收者，而是必不可少的核心参与人员。