业务分析流程：分步教程
查尔斯·摩尔
业务分析流程中应遵循哪些步骤？
以下是业务分析流程所涉及的步骤。它将指导您从第一天的业务分析过程直到规划阶段的结束。
步骤 1）收集有关项目的所有信息
它是 业务分析师 负责通过向与项目相关的人员（项目经理、项目发起人、职能经理或企业主）提问来收集与项目相关的每一个细节。
收集的信息应涵盖以下主题：
- 项目范围和边界
- 影响组织的当前因素
- 项目风险和限制
- 更广泛的组织背景
确定积极参与项目的利益相关者。这也是进行以下工作的良机： 利益相关者需求分析.
收集完这些信息后，分析你在项目中的角色，并制定一份作为业务分析师可以包含在内的清单，例如：
- 你可以将以往经验中的哪些教训应用到当前项目中？
- 当前项目所需的文件和规划
- 与利益相关者讨论项目的可能结果
- 确定参与项目的成员
- 需要更多意见时，安排与客户和利益相关者的会议。
- 预期交付成果及其所需格式
- 您可以查阅现有文档，以便更好地了解项目。
- 方法论（敏捷或瀑布最适合该项目的
步骤 2）识别利益相关者并建立 Rev会议
第二步，设置一个 审查会议 与项目经理、利益相关者和团队成员沟通。议程不明确往往会导致项目失败。
- 明确说明项目预期成果。
- 让项目经理、利益相关者和团队成员参加会议，并提出与项目相关的问题。
- 如果你正在进行一个全新的项目，请咨询项目经理或之前在该领域工作过的联系人。
步骤 3）分析所有与项目相关的文档
接下来，正确地 分析 所有与项目相关的文档，例如：
- 业务流程文档
- 业务和系统需求文档
- 商业案例
- 图表和流程图
- 项目计划
- 组织架构图
- 战略文件和业务计划
- 政策和立法
挖掘出业务需求文档中隐藏的任何信息， trac现有系统、流程、程序和操作存在差距。您收到的文件可能已过时，因此在将其视为最终版本之前，请务必核实您发现的每一项事实。
第四步）记录你发现的所有事实和信息
在调研和分析过程中，你会发现许多关于项目的有用信息，这些信息可能需要修改或实施。请记录下每一项发现，以便日后查阅。
- 业务要求，包括报告要求
- 业务流程和支撑系统
- 功能性和非功能性需求
- 当前影响项目的问题和风险
步骤 5）理解问题领域
到这时，你已经对项目有了扎实的了解，所以你可以 确定问题域你需要弄清楚：
- 哪些业务职能会受到影响
- 影响业务的风险和因素
- 影响项目的政策和限制
- 决定项目重要性级别的价值观
- 目前支持业务活动的系统
- 总结问题领域的文档，例如年度报告。
- 目前阻碍企业实现预期目标的各种问题
- 所提出的变更是否会对问题领域产生影响
步骤 6）提出业务需求
收集完所有业务需求并了解问题领域后，下一步是…… 提出业务需求 向利益相关者或项目经理进行演示。常用的演示技巧包括：
- 表格或电子表格
- 图表或图表
- 原型或模拟
- 结构化文本模板或结构化句子
业务分析师流程概述术语表：
- 目的： 定义拟议计划所需的业务分析活动的目的
- 范围： 定义包含和排除的可交付成果
- 根本原因： 明确已发现问题的根本原因。
- 当前的状况： 明确导致变革需求的根本问题。
- 计划开展的活动： 定义活动的原因、可交付成果和交付日期
- 利益相关者参与计划： 概述利益相关者参与过程
- 质量管理： 描述确保项目交付成果质量的各项活动
- Target 店铺条件： 阐明如何解决已确定的关键问题。
业务分析师的快速提示
- 在会议中提问
- 在利益相关者会议或审查之前做好准备
- 适应变化和新体验
- 管理期望
- 回复反馈
业务分析过程中产生的常见交付成果
每个业务分析流程都会留下一系列文档，项目团队、发起人和审计人员都可以查阅这些文档。 trac回到正题。持续交付这些成果是使流程能够在各个项目中重复进行的关键。
- 业务分析计划： 描述分析工作的具体方法、时间表和利益相关者参与计划。
- 利益相关者登记册： 列出所有利益相关者及其角色、影响力、期望和首选沟通渠道。
- 业务需求文档（BRD）： 用非技术利益相关者能够理解的语言，概括高层业务需求、目标和成功标准。
- 功能性需求和非功能性需求： 将业务需求文档转化为开发人员和测试人员可以据此进行开发的系统行为、质量属性和约束条件。
- 流程模型和用例： 使用 BPMN 图、UML 用例或活动图来展示当前状态和未来状态的工作流程。
- 申请条件 Trac能力矩阵（RTM）： 将每个需求与其来源、设计元素以及验证该需求的测试联系起来。
- 变更请求日志： 记录范围的每一次变更及其影响、决策和审批人，以便保持审计跟踪的完整性。
这些交付成果应该存储在共享存储库（例如 Confluence、SharePoint 或专用需求管理工具）中，以便每个团队成员都能使用相同的版本。
业务分析过程中应避免的常见错误
即使是经验丰富的业务分析师，在交付压力下也会落入同样的陷阱。注意以下错误可以避免项目后期出现大部分返工和范围意外情况。
- umping 在明确问题之前就想出解决方案： 在不了解根本原因的情况下提出系统、工具或功能，会导致代价高昂的返工，并且最终的解决方案无法解决真正的业务需求。
- 跳至ping 利益相关者验证： 未经系统使用者签字确认而记录需求，会造成漏洞，这些漏洞只有在用户验收测试期间才会显现出来。
- 将需求视为静态的： 项目过程中业务需求会发生变化。如果业务分析师不维护需求库，那么他就无法胜任这项工作。 trac能力矩阵很快就会失去对范围的控制。
- 过度记录而非协作： 制作一份 200 页却无人阅读的业务需求文档，还不如制作一份简短的文档，并定期召开工作会议，使用可视化模型。
- 只关注快乐的道路： 缺少异常情况处理、错误处理和非功能性需求会导致缺陷进入生产环境，并削弱用户信任。
- 各自为政： 如果没有开发人员、测试人员和运维团队的参与，需求分析就会忽略可行性风险和下游限制，而这些问题在联合审查中是可以发现的。
- 使用含糊不清或模棱两可的语言： 诸如“用户友好”、“快速”或“灵活”之类的词语，如果没有可衡量的验收标准，就会造成分歧，而这些分歧只有在功能演示时才会显现出来。
支持业务分析流程的常用工具
合适的工具集能够支持业务分析流程的每个阶段，从需求收集到最终确认。大多数团队会将轻量级的待办事项列表工具、建模工具和文档平台结合起来使用。
- 吉拉和 Azure DevOps： Trac在敏捷交付团队中管理 k 个史诗、用户故事和缺陷，并将需求与冲刺工作联系起来。
- Confluence、SharePoint 和 Notion: 将业务分析计划、会议记录、决策和业务需求文档存储在利益相关者可以访问的可搜索空间中。
- Microsoft Visio, Lucidchart以及 draw.io： 绘制 BPMN 流程图、用例图和数据模型，使工作流程和交接过程可视化。
- Jama Connect， IBM 门， Modern Requirements以及 Visure： 利用基线大规模管理需求 trac受监管项目的可行性及影响分析。
- Miro 以及壁画： 促进远程发现，用户旅程图ping以及亲和力图ping 实时研讨会。
- 巴尔萨米克和 Figma: 在开发开始之前，制作低保真线框图和高保真原型，以便与业务用户验证拟议的屏幕。
小型团队通常从 Jira、Confluence 开始， Lucidchart规模较大或受监管的项目会添加一个专门的需求管理工具。 trac能力建设、基线和审计跟踪成为强制性要求。
