在当今的敏捷/ DevOps项目中：对当前问题的分析我们会考虑的各种可能性和替代方法，这本身可能会导致僵局；有时，我们可能会推迟做出决定，直到“所有”数据可用为止；有时，某个决定会被延迟，以便稍后做出最佳决定；有时我们可能会付出不必要的努力进行研究。
所有这些都会导致生产阶段的缓慢移动。以下是一些管理方法：
- 启发是一个反复的活动，其可交付成果也是递增的。它通常也不是独立的活动。确保您正在与利益相关者一起审查业务分析和启发工件。自我审查，内部审查和质量检查表的文化也有帮助。
- 维护与您的分析活动有关的风险列表。您可以将它们添加到诱因跟踪器中，或者您想要维护单独的风险登记册。关键是要提及风险以及对评估和缓解计划的共识。这将有助于防止分析瘫痪，并有助于迈出下一步。
分析孤岛
业务分析师产生的东西不是利益相关者所需要的和/或没有被正确的利益相关者充分审查的东西，业务分析师需要与业务团队的利益相关者进行协作，例如领域中小型企业，合作伙伴，供应商和赞助商。业务分析师还与IT团队和利益相关者合作，例如开发，质量保证，体系结构，基础架构，支持和治理。利益相关者参与不足的根本原因还可能是，利益相关者分析在项目开始时未完成或在项目期间未更新。另一个根本原因可能是害怕收到反馈的惯性。利益相关者参与不足以及分析瘫痪是一个风险区。以下是一些管理方法：
- 与每个利益相关者群体的共识是至关重要的。识别并与每个利益相关者群体一起审查。了解他们将如何为该计划做出贡献。了解您作为业务分析师将要执行的每个任务的RACI也会有所帮助。关键是确保您与合适的利益相关者合作，并知道谁将成为每个业务分析任务的决策机构。
- 制定有效合作计划也很重要。为了进行定期检查和反馈，请确保您将如何协作（哪些工具），频率，时间等。如果您是大型项目团队的成员，并且在诸如scrum之类的结构化框架中工作，则可能已经绘制了这些图。尽管项目规模大，类型大，但主要是要使与正确信息相关的利益相关者充分参与，并采用首选格式。
需求表达模糊
业务分析师需要处理来自大量来源的信息。信息可以采用各种形式，例如口头，白板快照，电子邮件，粗略的注释，录音等。为每个利益相关者组创建正确的需求视图集至关重要。有时没有现有文档或现有文档不完整。所有这些可能会导致需求不完整，而需求缺口很大。尤其是那些刚开始从事业务分析工作的人可能会发现这是一个艰巨的问题，他们的书面需求可能仍然含糊不清。以下是一些管理方法：
- 通过问题开始为启发活动做好准备，并通过某种跟踪器跟踪答案。确保您有准确的问题并使用简单的语言。另外，请记住您在问哪些利益相关者。
- 在将启发性注释转换为业务分析可交付成果时，请确保准确表达需求。在需要时，提供工件，例如流程模型，数据模型，决策表等。通过将用户案例，用户案例，流程模型，BRD，FRD等与正确的工件链接起来，确保需求的可追溯性。这将有助于提高影响分析的清晰度和跟踪性。像业务用户一样思考并编写逐步接受标准也是至关重要的部分。