Salesforce Certified Business Analyst

**写 User Story 时忽略 INVEST 原则** — INVEST = Independent（独立）/ Negotiable（可协商）/ Valuable（有价值）/ Estimable（可估算）/ Small（小）/ Testable（可测试）。考试里大量题目给你三四个 User Story 让你选"最好的那个"或"最差的那个"，判断标准就是 INVEST。最常见的错是 User Story 太大不能 Small（比如"用户可以管理所有客户"），或者没有 Acceptance Criteria 不能 Testable。标准格式永远是 `As a [role], I want [feature], so that [benefit]` + 明确的 Acceptance Criteria。

**搞不清 As-Is 流程图 vs To-Be 流程图的使用时机** — As-Is 画的是客户**当前**怎么做（包括所有痛点、手工步骤、Excel 文件传来传去），目的是让客户和项目团队对现状达成共识。To-Be 画的是上线 Salesforce **之后**流程长什么样。考试陷阱：很多人跳过 As-Is 直接画 To-Be，这是错的——没有 As-Is 基线客户根本不知道"改善了什么"，也无法度量项目 ROI。考题会问"项目 Kickoff 之后第一步应该做什么" → 答案永远是 As-Is 流程梳理，不是直接画 To-Be。

**把 Requirements（需求）和 Solution Design（设计方案）混为一谈** — BA 的核心纪律是：Requirements 只描述**业务问题和期望结果**，不能包含具体的技术实现方式。"销售经理每天上班要看到昨天所有超过 $50K 的订单" 是 Requirement；"在 Home Page 上用 Lightning Report Component 展示 Opportunity > 50K filter" 是 Solution Design。考题会给你一堆需求陈述，让你识别哪些是"污染了实现细节的伪需求"。记住：BA 负责 What 和 Why，Admin / Developer 负责 How。

**分不清 Business Rule（业务规则）和 Validation Rule（Salesforce 验证规则）** — 这两个概念每次考试必混淆。**Business Rule** 是客户业务层面的规定（"订单金额超过 10 万需要副总裁审批"），它是需求层面的东西，可以用 Approval Process / Validation Rule / Flow / Workflow / 甚至手工流程来实现。**Validation Rule** 是 Salesforce 平台上的一个具体功能，只是业务规则的一种实现方式。BA 文档里只应该写 Business Rule，不应该写"Create a Validation Rule on Opportunity"——那是 Admin 的决定。

**做 Stakeholder Analysis 时不用矩阵只凭感觉** — 考试高频考点：**Power/Interest Matrix** (也叫 Mendelow Matrix)。四象限：高权力+高兴趣 = Manage Closely（紧密管理，如 Sponsor）/ 高权力+低兴趣 = Keep Satisfied（定期汇报，如 CFO）/ 低权力+高兴趣 = Keep Informed（保持知情，如 end users）/ 低权力+低兴趣 = Monitor（最小精力）。考题会给你一个项目的利益相关者清单让你分类，或者问"这个 stakeholder 应该用什么沟通频率"，答案全在这个矩阵里。别和 RACI 矩阵混淆——RACI 是任务责任矩阵（Responsible / Accountable / Consulted / Informed），两者是不同的工具。

**忽视 UAT（用户验收测试）的 BA 责任** — 很多人以为 UAT 是 QA 团队的事，但 SFBA 考试明确把 UAT 放到 BA 的职责里（占 13% 权重）。BA 的 UAT 职责：编写 UAT 测试脚本（基于 Acceptance Criteria）、协调业务用户参与测试、记录缺陷并和开发团队对齐优先级、输出 Go/No-Go 决策文档。考题会问"UAT 脚本应该由谁来写" → 答案是 BA（不是 QA，不是 Developer）。