go/no-go 决策：如何准备，由谁决定

go/no-go 决定的是什么

go/no-go 是业务方表态的时刻：这个版本的 CRM 可以在这一天进入生产环境。或者说：还不行。它不是测试结束时的走过场，而是开展测试的原因。

一个好的 go/no-go 包含三部分：

• 事实。测试了什么、通过了什么、还有什么未解决。依据测试结果，而不是凭记忆。
• 判断。流程负责人说明他们能否用这个版本开展工作，以及需要什么条件。
• 决定。指导委员会结合上线日期权衡事实和判断，然后做出决定。

大多数出问题的 go/no-go 会议都缺少第一部分。大家争论某个问题有多严重，或者某个流程到底有没有测过，因为没有人掌握数据。本指南的其余部分讲的就是如何确保会议开始前事实已经到位。

退出标准：在第一个测试日之前商定

退出标准说明测试达到什么程度就足以上线。在第一个测试日之前与指导委员会商定。到了最后，情绪高涨，日期临近，那时再决定什么算数就太晚了。

适用于大多数 CRM 上线的标准：

• 没有未解决的 Critical 问题。
• 每个 Must 测试用例都已通过。
• 每个未解决的 High 问题都有业务部门接受的变通方案或修复日期。
• 范围内的每个测试用例都有结果。
• 每个流程的负责人都已签核。

商定用词的含义

只有当所有人使用同一套尺度时，标准才有效。写下每个严重程度的含义，并同时分享给测试人员和指导委员会：

优先级也照此处理。标记为 Must 的测试用例涵盖上线第一天就必须正常工作的内容，例如创建报价或路由个案。如果某个 Must 测试用例失败，上线就有风险。如何设定优先级，请参阅编写业务测试人员看得懂的测试用例。

写下哪些没有测试

每次 UAT 都会漏掉一些内容：稍后才上线的国家、尚未就绪的报表、只在系统测试中测过的集成。在测试之前就把它写下来。这样在 go/no-go 时就没有人能说他们以为已经覆盖了。

由谁决定

参与的有两类人，角色各不相同。

流程负责人签核

对于测试中的每个流程或分组，由业务部门的一个人签核：销售总监负责从潜在客户到回款，客户服务主管负责个案管理，财务负责人负责开票。他们了解自己的团队需要什么，也将承担结果。他们的签核意味着：我的团队可以用这个版本开展工作。

在项目开始时就指定他们，而不是在最后一周。一位在 go/no-go 会议上才第一次看到测试的流程负责人，要么不看就签字，要么要求再给一周。

指导委员会做决定

指导委员会为整个上线做决定。成员通常包括业务方的发起人、项目经理、IT 负责人，如果有实施合作伙伴，还包括合作伙伴的一名代表。它会权衡单个流程负责人看不到的因素：与旧 CRM 即将到期的合同、培训计划、迁移周末、同一日期的其他项目。

测试负责人负责准备，但不做决定

测试负责人提供事实和建议。测试负责人不代表业务方签核，也不做决定。正是把这些角色分开，才能让决定在上线后出现问题时站得住脚。

报告：包含哪些内容

go/no-go 报告是写给没有参与测试的人看的。保持简短：一页纸，背后附上细节，供需要的人查阅。

• 建议。go、有条件的 go 或 no-go，用一两行说明理由。
• 范围。测试涵盖了哪些流程和用户故事，以及哪些没有测试。
• 测试对象。环境、版本和构建。一个结果只属于系统的一个版本。
• 数据。已通过、失败、受阻和未完成的测试用例。
• 按分组或流程。同样的数据，附上每个分组的签核。
• 按优先级。多少个 Must、Should 和 Could 测试用例已通过，以及哪些 Must 测试用例尚未通过。
• 按严重程度列出问题。多少个未解决、待复测和已关闭，并逐一列出未解决的 Critical 和 High 问题。
• 签核。谁签的、何时签的、做了什么决定以及附加了哪些条件。
• 已知风险。业务方在最初几周将使用的变通方案，以及由谁提供支持。

在会议前一天发送报告。在家读过报告的人会提出更好的问题。

在 UAT Studio 中仪表板上的 Go/no-go report 包含结论提示（GO、GO with conditions 或 NO-GO，附理由）、各项数据、每日进度、按分组、按史诗和按优先级的结果、按严重程度的问题、逐一列出的未解决 Critical 和 High 问题，以及本轮的每次签核。结论提示遵循固定规则，仅为建议：由指导委员会做决定。可以 PDF 形式分享，也可下载为幻灯片放入指导委员会的演示文稿。

如何处理未解决问题

UAT 结束时总会有未解决的问题。关键不在于有没有，而在于每个问题是否都有决定。在会议之前，与业务方和开发团队一起过一遍，就像每日分诊一样。

谨慎重新分级

在最后几天，会有压力要求把 Critical 问题降为 High。有时这是对的：出现了变通方案，或者该流程其实很少用到。要公开地做，在分诊中与流程负责人一起做，并写下原因。绝不要为了让数据好看而悄悄这样做。上线就是这样在第一周失败的。

愿望不是缺陷

测试人员会发现一些他们希望有所不同的地方。如果系统按设计工作，那就是变更请求：它进入待办列表，而不是本次发布，也不计入影响上线的问题。

在 UAT Studio 中分诊为每个问题设定严重程度、优先级、负责人和决定：Fix、Reject 或 Change request。使用 AI test design 模块时，Issues 选项卡上的 Summarize with AI 会为 go/no-go 会议撰写未解决问题的简短概览：按主题归类，并指出哪些阻碍上线。没有该模块时，Summarize with your own AI 会提供一段提示词，供您粘贴到贵公司的 AI 中。

有条件的 go

许多 CRM 上线得到的是有条件的 go。系统已经足够好，前提是在上线前或上线后立即完成某些事项。只要条件是实实在在的，这就是一个合理的决定。

一个好的条件应当：

• 具体。金额超过 50,000 的订单折扣审批已修复并复测，而不是审批能用。
• 有人负责。由一个具名的人对它负责。
• 有日期。在上线前，或上线后最初几周内的某个日期。
• 有核查。有人确认已经完成，并告知指导委员会。

注意条件的数量。两三个是正常的。十五个说明测试还没完成。有条件的 go 不是回避 no-go 的手段。

分阶段上线

有时一个流程还没准备好，其余的都已就绪。这时可以在不含该流程的情况下上线，或者让某个国家或团队稍后上线。要明确做出这一决定，写下等待部分的新日期，并为其规划单独的 UAT 轮次和签核。

按分组签核

按流程或分组请求签核，而不是用一个签名涵盖所有内容。销售总监无法评判个案管理，也不应该由他来评判。每位负责人从三个答案中选择一个：

• 接受：我的团队可以用这个版本开展工作。
• 有条件接受：前提是这些条件得到落实。逐条写下每项条件，以及由谁在何时之前完成。
• 拒绝：还不足以上线。问一问怎样才能改变这个答案。

在会议之前收集好签核，让指导委员会基于完整的全貌做决定。签核只属于一个版本：如果之后有新的构建或新一轮测试，就要重新签核。

在 UAT Studio 中仪表板上的 Sign-off 卡片为整个项目和每个分组各设一行，可选 Accepted、Accepted with conditions 或 Rejected。系统会记录日期、时间以及未解决的 Critical 问题数量。默认情况下，只要还有未解决的 Critical 问题，就没有人能接受；如果勾选了 No sign-off while Must test cases have not passed，接受还要等到每个 Must 测试用例都已通过。拒绝始终可以进行。签核属于当前轮次。

主持 go/no-go 会议

在规划测试日时就规划这次会议，并把日期放进指导委员会的日历。预留一小时。典型的议程：

1. 测试负责人展示报告：范围、数据、未解决问题、签核。十分钟，数据显示在屏幕上。
2. 每位流程负责人用一两句话说明为什么这样签核，以及有哪些条件。
3. 针对未解决的 Critical 和 High 问题提问：有没有修复方案、变通方案、日期？
4. 测试之外的问题：培训、数据迁移、最初几周的支持、回滚计划。
5. 决定：go、有条件的 go 或 no-go。大声宣读，连同条件、负责人和日期。

如果决定是 no-go，请以一个计划结束会议：需要改变什么、新的测试轮次，以及下一次 go/no-go 的日期。有计划的 no-go 是正常的项目决定。没有计划的 no-go 会让人觉得是失败。

决策日志

当天就把决定写下来。几个月后，在发生事故或审计时，会有人问是谁决定带着那个未解决问题上线的。找到答案应该只需一分钟。

每次 go/no-go 的决策日志都包含：

• 日期，以及参会人员。
• 决定：go、有条件的 go 或 no-go。
• 每项条件，及其负责人、日期，以及之后完成的时间。
• 业务方接受的未解决问题，以及原因。
• 作为决定依据的报告，保持当时的状态。

将它与项目文档放在一起，并在上线后的最初几周跟进各项条件，直到每一项都完成。

在 UAT Studio 中go/no-go 报告上的 Save snapshot 会保存做出决定时的报告；它不会再变化，之后可以用 Show 再次打开。每次签核都保留在历史记录中，包括被替换或撤回的签核。为审计人员准备时，管理员可以下载 Evidence pack：报告、测试用例、结果和问题、每个问题的历史记录、每次签核和审计日志，每个文件都附有校验值。

免费使用

退出标准、签核和报告也包含在 CRM 上线 UAT 检查清单中，可作为免费 Excel 文件获取。关于整个测试，请参阅 Salesforce UAT 和 Dynamics 365 UAT 指南。