商业分析师成功的关键和障碍

BA成功的关键因素

• 利益相关者参与和承诺：BA必须在项目生命周期中，尤其是在项目启动阶段，获得利益相关者的参与和承诺。获得利益相关者的支持，可以有效降低项目阻力，并提高最终产品被使用和支持的可能性。由于最终产品（通常是系统）是面向最终用户的，因此让最终用户参与到项目的各个环节中至关重要，例如帮助推动最终产品的可用性和使用，帮助定义业务规则，进行用户验收测试等等。

• 准确的需求管理：用户/利益相关者需要什么，以及最终交付了什么，两者之间存在直接关联，这就是“需求管理”；即需求规划、收集、征求行动、促进、文档化等等。重要的是要坚持适当的征集方法，准确地捕捉正在设计和构建的系统/产品的关键要素。这将有助于系统的建模工作。

• 有效的建模/表示：系统的不同模型/表示可以非常有效地表示系统的“现状”和“未来”。不同的模型可以对不同的利益相关者提供完美的表示，而不同的受众成员，其细节的程度可能有所不同。一些常见的模型包括流程图、ER图、用例图、系统图、架构图、原型，甚至演示文稿。注意：需要添加参考图片，来自“现代分析师”的著名插图，一个需求以多种不同的方式进行了解释。

BA成功的障碍

关键工件/需求定义不明确：通过确定需要哪些工件，并对每个工件有一个清晰的认识，可以避免很多混乱。BA可以提出的问题包括：我需要创建功能性需求还是非功能性需求？我需要创建业务用例吗？我需要创建系统用例吗？我需要创建用户故事吗？根据现有的方法，是否需要用例？
不一致，不遵循现有的方法：BA必须清楚地了解正在使用的方法：例如 - 是敏捷开发？瀑布模型？迭代开发？SCRUM？通过引入与组织中使用的方法不一致的活动，可能会浪费很多工作量，在不需要的活动上浪费时间，并会导致计划和时间安排不充分。例如 - 如果SCRUM方法已经到位，那么就不需要用例。用户故事可以起到与用例类似的作用，但不需要用例。
缺乏工具：一些工具有助于使BA的工作更容易，尤其是对于需求管理。如以下例子所示，缺乏一些工具会使BA的工作更加耗时，并会阻碍与其他团队成员（如质量保证人员）的合作。例如：用于保存用例等的仓库（如RequisitePro），可以轻松跟踪修订版本；测试工具（如Quality Center），可以保存测试用例，并可以将这些测试用例与用例同步；缺乏像QTP这样的自动化测试工具（更适合质量保证人员）。
BA和其他角色之间的界限模糊：当BA扮演多个角色的帽子时，可能会增加复杂性 - 例如：BA vs.测试人员；BA vs.项目经理。当界限模糊或交叉时，可能会在分工、利益冲突等方面造成问题。当然，也有一些情况，由于各种限制，BA需要扮演多种角色；例如，在资源有限的小团队/实体中。
需求管理不足：如果BA没有注意尽量减少非增值活动，就会有很大的风险，会导致浪费大量工作量。例如，开发比需要的更多工件和模型，创建超出业务范围并可能包含设计元素的需求，陷入过早澄清所有需求的陷阱。在缺乏变更控制的情况下，需求可能会不断变化，这会导致项目范围扩展。如果有必要，必须设定冻结点，禁止对特定版本进行任何进一步更改，并将进一步更改处理到未来的迭代中。
缺乏利益相关者和最终用户的支持：如果利益相关者没有被项目说服，他们更有可能不会做出推动项目前进的决定，也不会参加会议和讨论，甚至会导致项目无法启动。如果项目最终完成，可能会得不到进一步支持，或者后续阶段可能无法构建。如果最终用户没有完全被项目说服，那么项目在构建完成后可能不会被使用，这是一个很大的风险。