BA Best Practices

BA 最佳实践技能

目的

指导 AI 助手应用专业的 BA 最佳实践，确保需求质量高、协作有效，并取得成功的项目成果。

需求质量属性

1. 清晰

• 使用简单、明确的语言
• 避免使用未定义的术语
• 每条陈述只包含一项需求
• 具体、明确

❌ 不佳：“系统应易于使用” ✅ 良好：“系统应在最多 3 次点击内完成结账流程”

2. 完整

• 包含所有必要信息
• 考虑边缘情况
• 记录例外情况
• 覆盖成功和失败场景

3. 一致

• 不与其他需求矛盾
• 全文术语一致
• 与业务目标保持一致
• 遵循文档标准

4. 可测试

• 可通过测试进行验证
• 验收标准可衡量
• 结果可观察
• 可客观判定通过或失败

❌ 不佳：“系统应快速加载” ✅ 良好：“系统应在 4G 网络下于 < 3 秒内加载主页”

5. 可追溯

• 与业务需求关联
• 记录来源
• 具有唯一标识符
• 可进行影响分析

6. 可行

• 技术上可实现
• 符合预算限制
• 时间安排合理
• 资源可用

文档标准

命名约定

需求 ID：

• 格式：[TYPE]-[MODULE]-[NUMBER]
• 示例：FR-AUTH-001、NFR-PERF-005、BR-PRICING-003

文档：

• BRD_ProjectName_v1.0.pdf
• FRS_ModuleName_v2.1.pdf
• UseCases_FeatureName_v1.0.pdf

版本控制

语义化版本：

• Major.Minor.Patch（1.0.0）
• Major：重大变更、结构调整
• Minor：新增章节、添加需求
• Patch：修正、澄清

变更日志：

日期	版本	作者	变更	原因
2026-01-15	1.0	John	初始版本	新项目
2026-01-20	1.1	Jane	添加 FR-005-010	利益相关者反馈

文档结构

标准章节：

1. 文档控制（版本、审批、分发）
2. 目录
3. 简介（目的、范围、受众）
4. 正文
5. 附录（术语表、参考资料、图表）

需求可追溯性矩阵（RTM）

目的：将需求与业务需求、设计和测试关联起来

需求 ID	业务需求	设计元素	测试用例	状态
FR-001	BN-001	DES-UI-001	TC-001, TC-002	已实现
FR-002	BN-001	DES-API-003	TC-003	进行中

优点：

• 确保所有业务需求均得到处理
• 分析变更影响
• 验证测试覆盖率
• 提供审计跟踪

变更管理

变更请求流程

1. 提交请求

   • 变更说明
   • 业务依据
   • 影响评估
   • 优先级

2. 影响分析

   • 受影响的需求
   • 设计影响
   • 开发工作量
   • 测试影响
   • 时间安排影响
   • 成本影响

3. 评审与审批

   • 变更控制委员会（CCB）评审
   • 利益相关者审批
   • 预算审批（如需要）

4. 实施

   • 更新需求
   • 更新设计
   • 沟通变更
   • 更新可追溯性

5. 验证

   • 验证变更是否正确实施
   • 更新文档
   • 关闭变更请求

变更请求模板

# Change Request CR-001

**Date**: 2026-01-20
**Requested By**: Marketing Manager
**Priority**: High

## Change Description
Add social login (Google, Facebook) to registration process

## Business Justification
- Reduce registration friction
- Increase conversion by estimated 25%
- Competitive parity

## Impact Analysis
**Requirements**: Add FR-AUTH-015, FR-AUTH-016
**Design**: New OAuth integration components
**Development**: 2 weeks (40 hours)
**Testing**: 1 week UAT
**Timeline**: Delay release by 2 weeks
**Cost**: $8,000

## Approval
- [ ] Product Owner
- [ ] Technical Lead
- [ ] Project Manager

## Decision
☐ Approved  ☐ Rejected  ☐ Deferred

**Reason**: _____________________

评审与审批工作流

需求评审清单

内容评审：

• 所有需求均符合质量属性
• 明确记录业务规则
• 明确说明假设
• 确定约束条件
• 梳理依赖关系
• 定义验收标准

技术评审：

• 技术上可行
• 确定集成点
• 性能要求切实可行
• 满足安全要求
• 考虑可扩展性

业务评审：

• 与业务目标一致
• 业务价值明确
• 满足利益相关方的需求
• 优先级合理
• 预算和时间表切实可行

审批级别

文档类型	审批人	时限
BRD	业务负责人、产品经理、财务	1 周
FRS	技术负责人、架构师、业务分析师	3 天
用户故事	产品负责人、Scrum Master	1 天
变更请求	CCB、受影响的利益相关方	2-5 天

沟通最佳实践

与利益相关方沟通

频率：

• 高管：每月更新状态
• 产品负责人：每周同步
• 开发团队：每日站会、Sprint 活动
• 最终用户：里程碑演示、UAT 会议

沟通渠道：

• 正式：电子邮件、正式文档、演示文稿
• 非正式：聊天（Slack、Teams）、简短通话
• 协作：研讨会、工作会议
• 广播：通讯、全员大会

会议最佳实践

会前：

• 提前 24 小时发送清晰的议程
• 分享会前阅读材料
• 明确目标
• 邀请合适的参会者

会中：

• 准时开始和结束
• 按议程进行
• 记录会议纪要和行动事项
• 鼓励参与
• 暂缓讨论无关事项

会后：

• 在 24 小时内分享会议纪要
• 分发行动事项，并注明负责人和截止日期
• 跟进各项承诺

协作技巧

混合团队协作

挑战：

• 时区差异
• 沟通脱节
• 工具碎片化
• 文化差异

解决方案：

• 安排重叠工作时段，以便实时协作
• 采用异步沟通（Lark、Notion）
• 为文档建立唯一可信来源
• 定期进行视频通话，以建立关系
• 清晰记录决策

冲突解决

利益相关方意见不一致时：

1. 了解双方观点

   • 积极倾听各方意见
   • 提出澄清问题
   • 记录各方关注点

2. 寻求共同点

   • 确定共同目标
   • 聚焦业务价值
   • 区分立场与利益

3. 探索可选方案

   • 集思广益，提出替代方案
   • 考虑折中方案
   • 评估取舍

4. 运用数据

   • 客户反馈
   • 分析数据
   • 竞争分析
   • 成本效益分析

5. 必要时升级处理

   • 记录冲突
   • 提出方案并说明优缺点
   • 由决策者作出决定
   • 接受决定并继续推进

常见陷阱及规避方法

陷阱 1：过度设计

问题：添加不必要的功能 解决方案：始终将需求与业务价值挂钩，对“锦上添花”的需求提出质疑

陷阱 2：范围蔓延

问题：需求不受控制地增加 解决方案：采用正式的变更管理流程，明确范围边界

陷阱 3：分析瘫痪

问题：过度分析，始终无法完成 解决方案：为分析设定时间限制，追求“足够好”而非完美，采用迭代方式

陷阱 4：想当然地认为理解一致

问题：未与利益相关方验证需求 解决方案：始终确认双方理解一致，使用原型，并获得签字确认

陷阱 5：忽略非功能性需求

问题：只关注功能，忽略性能和安全 解决方案：明确收集 NFR，并纳入 DoD

陷阱 6：文档质量差

问题：文档不完整、过时或不清晰 解决方案：制定文档标准、进行版本控制并定期评审

陷阱 7：利益相关者参与度低

问题：利益相关者未参与或缺乏投入 解决方案：定期沟通、展示价值、让他们参与决策

持续改进

回顾

每个项目／冲刺结束后：

• 哪些方面进展顺利？
• 哪些方面可以改进？
• 我们今后会做出哪些改变？
• 制定改进措施

需要跟踪的指标

需求质量：

• 审批后发生变更的需求百分比
• 可追溯至需求的缺陷数量
• 需求评审周期

利益相关者满意度：

• 调查评分
• 反馈主题
• 参与度

交付：

• 按时交付的需求百分比
• 按范围交付的需求百分比
• 返工率

专业发展

认证：

• CBAP（认证业务分析专业人士）
• PMI-PBA（业务分析专业人士）
• IIBA 认证
• 敏捷认证（CSPO、CSM）

持续学习：

• 行业会议
• 网络研讨会和工作坊
• 专业社群
• 阅读（BABOK、行业博客）

工具与模板

推荐工具

文档：

• Lark Docs（协作）
• Notion（知识库）
• Confluence（企业级）

图表：

• Figma（UI/UX）
• Miro（协作）
• Lucidchart（流程图）
• Mermaid（基于代码的图表）

需求管理：

• Jira（敏捷）
• Azure DevOps
• Lark Base（灵活）

沟通：

• Lark（一体化）
• Slack/Teams（聊天）
• Zoom（视频）

参考资料

• BABOK® Guide（IIBA）
• PMI-PBA Handbook
• Agile Extension to BABOK®
• IEEE 29148 Standards
• Requirements Engineering（Klaus Pohl 著）