2011年2月22日,星期二09:43

业务分析:这是您项目的瓶颈吗?

撰写者

项目经理,架构师或开发人员多久等待一次业务分析师来完成需求文档,完成模型或完成流程。正如所有业务分析师(BA)所知,识别所有利益相关者并与之交谈,提出需求,对其进行分析,然后进行文档编制和审查都需要花费时间。作为出色的业务分析师,我们都希望他们完美且详细,毫不含糊。但是,在期望值更高,截止日期越来越短,预算越来越紧张的项目中,您如何产生定义明确,清晰,简洁,无歧义和详细的要求。随着收集和记录需求的时间减少,记录需求的细节和质量也随之减少。我们都知道创建这些惊人模型需要花费多长时间。

我曾在许多组织和许多项目中工作过,在项目团队中通常只有一个人负责需求的业务分析,而有一组开发人员进行代码更改或从头开发软件。毕竟-通常只能生成一份需求文档,所以为什么要在上面放多个人。

获得高质量的详细要求对于项目至关重要,因此需要出色的业务分析师来进行生产。但是,为什么不将两个或三个甚至更多的业务分析师放在一个项目或职能上呢?您上一次从事项目的业务分析师人数超过开发人员的时间是什么时候?那么,为什么不让更多的人从事项目最关键的阶段之一呢?其中的一些优势是共享知识,协作,同行评审,更广泛的想法和可能的解决方案,以及在可用资源更多的情况下缩短了时间表。使用良好的项目和文档管理技术和工具可以克服任何弊端,甚至可以克服自负。但是通常公司的业务分析师的资源很紧张,并且在一个项目或职能上投入多个资源是不可能的。

因此,如果我们不能让更多的人来解决缩短需求时间表的问题,那么我们还能怎么做呢?好吧,我们看到越来越多的关于敏捷开发方法的讨论,在这些方法中,业务代表直接与开发人员交谈,从而消除了对BA的大量需求。这可以在正确的情况下和正确的环境中工作,但是许多公司和项目发现,如果不充分理解和理解,敏捷会导致更多的超支和质量问题。

我看到了一个项目工作,其中多个BA资源满足需求并专门针对特定领域。需求没有完全详细地预先列出,但是业务远景是明确的,并且高层需求被记录到可以进行估计的水平。然后,在每个业务领域的每个迭代开发阶段开始时,负责的BA会通过模拟屏幕截图或故事板,流程模型以及相关的业务规则,向开发团队详细口头介绍他或她的概念。让开发人员和测试人员看到完整的图片以及细节很重要,并且允许他们提出问题并立即寻求澄清,这可以加快信息传递的过程。如果有任何变化,那么高效和快速的变化管理过程就非常重要。

记录需求的过程通常是一个冗长的过程,会产生许多大文件。我知道我当时写了许多大型需求文档,其中包含详细的需求,用例和图表。从积极的角度来看,更多的时间可以使我们的要求更加详细和清晰,但是不幸的是,这通常会导致花费更多的时间进行更改和更改控制。

因此,大型需求文档或许多用例文档是最好的方法或最佳实践。答案是,要看情况。这取决于组织及其发展过程和规则,以及整个团队是否都在一起。一些组织仍然具有非常严格的瀑布式开发框架,严格的财务模型,在下一阶段进行之前,需要大量利益相关者的正式审查。他们依靠大量详细的需求文档和准确的成本估算。成本是此过程的很大一部分,在大型组织中很容易理解所有这些控制,但这确实意味着捕获,分析,记录和审查需求的需求过程需要很长时间。我们看到越来越多的关于敏捷开发方法的新闻,许多公司希望利用这些方法,而又不了解他们的整个开发框架需要如何改变。

因此,我们想要的是一种加快需求过程的方式,而又不会丢失任何细节或与利益相关者的沟通,这使他们可以确认需求,因此可交付成果是正确的。

远景文档非常擅长捕获涉众的远景和要交付的内容的需求,而用例和用户案例则是沟通某人与系统交互方式和系统响应方式以及捕获所有重要信息的有效方法替代条件和异常条件。服务质量要求也很重要,因为它们为我们提供了系统必须依据的参数。其他补充规范文档包含报告和接口要求。因此,重要的是我们要捕获所有这些内容并将其传达给利益相关者和开发人员以供批准。我们这样做的方式可以改变并加快流程。

我知道我是否必须站起来在一个房间里向一群我真的想知道和理解我在说什么的人提出要求或用例,所以我不仅可以很好地陈述自己,还可以回答他们的问题。因此,如果我必须向利益相关者或开发人员提出要求,并提出建议的系统,那么我也想知道我已经掌握了所有细节并很好地理解了它。当有人在那里回答问题时,人们似乎也更愿意提出问题。当您在解释可以让您重新表达或简化您所讲内容的内容时,您还可以查看人们是否感到困惑或迷路。

我发现通过与利益相关者和开发人员交谈,您可以在短得多的时间内传达更多的信息和理解,而不仅仅是书面文档。但是重要的是,每个人都能听到相同的信息并获得相同的图像。因此,正如我们在敏捷开发中所看到的那样,向开发人员口头传达需求被视为加快开发过程的答案,尤其是如果您始终可以让开发人员与他们确认细节时。与任何事物一样,存在风险,但是有减轻风险的方法。

因此,以我的经验,中间立场很重要。我们需要在文档中记录业务的愿景,因为它会被大量引用,并且重要的是我们必须详尽而清晰地捕获它。

对于需求和用例,捕获高层次的视图很重要,但是许多细节可以通过口头传达。我们需要捕获足够的细节,以确保我们已经识别出所有内容,并且具有足够的细节来执行初步估算。详细的用例对于应用程序的关键或高风险部分很重要。与开发人员,架构师和测试人员紧密合作非常重要。毕竟,这与解决方案有关,而不仅仅是要求。

不要忘记在下面留下您的评论。


罗斯·威尔逊 是位于新西兰奥克兰的Equinox Limited的首席顾问,专门研究需求管理。他从事IT工作已有27年,在许多不同的行业中拥有丰富的项目经验。在过去的14年中,他专注于业务分析,项目管理和团队领导。可以通过[email protected]与Ross联系。

罗斯·威尔逊的最新消息

©BA Times.com 2020

麦格雷戈徽标白色网站