AI PM Buddy从学习到交付
♢新
正在读取本机记录…
拓展项目实战◷ 55 分钟

可访问性、移动适配、评审与需求变更

用评审和版本记录保持方案一致、可访问、可追踪。

学完你能做到
  • 用自己的话解释“可访问性、移动适配、评审与需求变更”及其核心术语。
  • 在真实 AI 产品场景中识别何时应该使用本课方法。
  • 完成一份可沉淀进“功能流程图、交互原型与可验收 PRD”阶段任务的实践产出。
前置与关联课程

完成阶段 1 的能力检查，或先预览相关基础课

前置 · AI 生成、停止、重试、编辑与反馈体验关联 · 用户旅程、任务流程与服务蓝图
01

REAL SCENE

先从一个真实场景开始

!

需求评审通过后，业务临时加入“自动发布”，设计又调整流程，算法发现质量门槛达不到。变更通过群聊零散传递，PRD、原型、接口和测试各自停在不同版本。最后没人说得清当前范围和决定理由。评审与变更管理的目标是保持共同基线可追踪。

02

PLAIN EXPLANATION

说人话：它到底是什么？

需求评审确认价值、范围与规则，设计评审确认流程、状态和可用性，技术评审确认可行性、架构、依赖与风险，测试评审确认验收、数据和环境。评审不是轮流汇报，而是围绕待决策项获得结论。变更需要记录提出者、原因、影响、选择、决策人和生效版本，并同步更新所有关联产物。需求语言要删除“快速、智能、友好、适当”等不可测试形容词。

01

为不同评审定义入口条件

需求未说明目标和非目标，不应进入技术估时；流程未覆盖失败，不应进入完整视觉；验收不明确，不应承诺上线。入口条件让评审聚焦有效问题，而不是现场补作业。

  • 提前发材料和待决策清单
  • 参与者按决策权邀请
  • 未准备项明确退回与补充责任
02

会议输出是决定日志

每个议题记录结论、证据、反对意见、负责人和日期。未决项必须有下一步与截止时间；“大家都没意见”不是批准。重要决定链接到 PRD、原型、接口和测试版本。

  • 批准、修改后批准、退回三种状态
  • 决定与行动项分开记录
  • 风险接受必须有授权人
03

控制变更与可测试语言

任何变更先做用户价值、范围、设计、技术、数据、测试、成本、进度和风险影响分析，再由有权限的人决定进入当前、下个版本或拒绝。模糊词改成指标、条件和样例。

  • 建立需求—设计—接口—测试追踪
  • 变更后更新版本与通知范围
  • 保留被替代规则和迁移说明
01

每类评审有入口条件、待决策项和明确决策人。

02

评审结果写成可追溯决定、未决项和行动，不以沉默当批准。

03

变更先评估全链路影响，模糊语言改成条件、数值和样例。

#可访问性#需求评审#变更记录
03

KEY POINT

这节课最重要的结论

核心重点
需求变更不可怕，不记录影响范围和决策理由才可怕。
为什么重要
这决定了把需求转化为团队能开发、能测试、能验收的完整方案时，团队是否拥有一致、可验证的判断标准。
适用边界
当问题目标、数据来源或失败成本发生变化时，不要机械套用；先重新确认假设和风险等级。
04

EXAMPLES

正确案例与常见反例

✓ 正确做法

自动发布变更先分析：用户价值高但风险不可逆，需要新增权限、预览、审计、撤销和红队测试，排期增加两周。产品负责人决定当前版本仍人工确认，下版本在低风险内容灰度。决定同步更新 PRD 非目标、原型、接口状态和测试用例。

× 常见误区

业务在群里说“顺便自动发布”，开发回复“可以”。PRD 没更新，设计稿仍有确认页，测试按旧流程验收。上线前业务认为已经自动化，产品认为只是建议，团队被迫临时改动并跳过安全测试。

和工程师这样沟通

“这是范围变更，不在群里直接确认。影响包括工具权限、不可逆副作用、审计、撤销和两周测试。请各角色在变更单补影响；当前版本维持人工确认，正式决策链接会同步到 PRD、接口和测试基线。”

05

HANDS-ON

必做实操任务

本节产出：“功能流程图、交互原型与可验收 PRD”阶段任务中的《可访问性、移动适配、评审与需求变更》一页实践卡

  1. 步骤 1为需求、设计、技术和测试评审分别定义入口材料、参与角色和必须决定的事项。

  2. 步骤 2模拟一次评审，记录三个决定、两个未决项、负责人和截止时间。

  3. 步骤 3选择一个中途变更，完成价值、范围、技术、数据、测试、成本和风险影响分析。

  4. 步骤 4从现有文档找出十个模糊词，逐个改成条件、数值、状态或样例。

○
实践完成度 0/4

实践结果会自动保存在本机，并进入项目工坊的任务来源。

评审决定与变更影响单评审类型：需求 / 设计 / 技术 / 测试 入口材料与版本：____ 待决策项：____ 参与者与角色：____ 结论：批准 / 修改后批准 / 退回 证据：____　反对意见：____　风险接受人：____ 未决项｜负责人｜截止时间：____ 变更内容与原因：____ 用户价值影响：____ 范围/设计：____ 技术/依赖：____ 数据/迁移：____ 测试/验收：____ 成本/排期：____ 安全/合规：____ 决定：当前 / 下版本 / 拒绝｜决策人____ 需同步产物：PRD____ 原型____ API____ 测试____ 发布____
06

CHECKLIST

产品经理工作检查表

07

MASTERY QUIZ

掌握测验

达到 60% 即可完成本课。

1评审前设置入口条件的主要作用是？
2“大家没有意见”是否等于需求批准？
3如何把“结果要快速返回”改成可测试要求？
08

INTERVIEW

常见面试题

开发中途出现重要需求变更，你会怎么处理？
展开参考回答

先确认变更背后的问题和紧迫性，再分析用户价值、范围、体验、技术依赖、数据迁移、测试、成本排期与风险；给出当前版本、下版本或拒绝的选项和证据，由明确决策人决定；随后更新 PRD、原型、接口、测试与发布基线并通知受影响角色，保留决定日志。

09

RECAP & FURTHER READING

重点回顾、延伸阅读与下一步

一句话回顾需求变更不可怕，不记录影响范围和决策理由才可怕。
  1. 1

    围绕“可访问性、移动适配、评审与需求变更”继续阅读：阅读一份完整项目复盘，沿着目标、证据、方案、交付、结果和反思还原决策链。

  2. 2

    用“可访问性、需求评审、变更记录”作为检索词，分别写下一条定义、一条适用边界和一个反例。

  3. 3

    对照本课正确案例与反例，寻找一个公开案例并记录其中可复用的判断与不能照搬的条件。