2014年2月25日星期二09:04

都知道

撰写者

在业务分析领域中有很多重复出现的问题。重复出现问题的原因可能是因为没有答案。我们希望对困扰业务分析师的一些问题有明确的答案。实际上,对于某些问题有明确的答案,但不幸的是,这些答案来不及实现。

我们到了吗?

例如,我们什么时候完成需求定义的问题?我们怎么知道什么时候完成?我们什么时候可以获得完整的信息,以便我们可以知道该项目生产的产品可以完全解决业务问题?我们希望有一个清单或公式表明:“当您完成,达到或达到这一点时,您便已完成了需求过程”。

需求是信息的结果。业务分析师收集信息,分析信息并产生需求。为了拥有“完整的要求”,您必须以正确的形式获得与问题和解决方案相关的所有信息,并确认它们是准确的,并且没有歧义或矛盾。表面上这是可能的。

问题在于,除非事后考虑,否则您永远不会知道自己拥有“完整的信息”。在IT行业从事46年的工作中,我敢说,在开始编码(非常小的项目)时,我们只能说一次或两次我们拥有完整的信息(因此也有完整的需求)。在大多数情况下,我们处于测试的后期阶段,但仍在获得新的信息(和要求)。当用户实际看到产品时,就会出现新信息。在很多时候,产品交付时,只有当用户在日常活动中使用这些功能时,我们才能获得所需的真实信息(通常会导致后续发行)。

我们必须接受这样的前提,即可能永远无法获得完整的信息。

这里没有责备。没有人故意地隐瞒信息。没有人故意地提供虚假或矛盾的信息。尽管有许多开发人员(和业务分析人员)提出相反的抗议,但用户确实确实知道他们想要什么,甚至可以以一种可以理解的方式表达它。只是在他们看到我们正在发展的思想之后,新信息和观点和想法。有些事情我们根本不知道,很多时候我们都不知道我们不知道。然后,突然间,我们做到了。我们在新情况下发现新信息,而新信息多次使旧信息无用或可疑。我们称这些为“变化”,也称那些给我们“变化”的人更糟。出于某种原因,尽管开发过程中出现了新的信息,IT部门一直希望业务部门确切地知道他们想要什么,然后不动摇该请求。

信息鸿沟

在软件开发以及整个项目中,很大程度上,我们已经设计出许多方法来缓解由信息鸿沟引起的问题。敏捷方法假设我们将不断学习。敏捷方法主张增量交付,每两周左右交付一次新的“解决方案”。这以反馈的形式提供了新信息的连续流。

即使采用线性管理或瀑布式软件开发方法,我们也倾向于在我们的流程中添加原型,以便业务人员可以看到他们将会得到什么。而且我们可以通过反馈的形式获得更多信息,而在此之前我们可能无法获得信息。人们对稻草人的反应比对模糊概念的反应更好。

线性或瀑布式方法表明,如果我们花更多的时间在前面,则可以获取很大一部分信息,从而减少了对变更,失望或彻底失败的需求。敏捷方法假设我们无法或可能永远无法获得所有信息,那么为什么要尝试呢?由于许多信息都是在产品至少可以正常使用之后获得的,因此让我们开始工作并从那里进行调整。

两种方法都可能起作用,但是无论采用哪种方法,都必须准备好管理层和项目团队-适当的预算,人员,时间表。
如果您正在寻找在设计或编码之前需要提供的所有信息,并且您遵循的是敏捷方法,您将对所有更改以及开始时显然缺乏信息感到沮丧。如果您希望以敏捷的方式获得信息并跟随瀑布走动,那么最初收集信息所花费的时间将使您感到沮丧,因为您肯定会改变。

需求文档是一个计划

需求就像计划。您可以将需求文档视为解决问题或开发产品的计划。 (需求文档几十年来一直被软件开发专家称为“蓝图”)。计划项目就有意义,而对产品的计划就有意义,这体现在一组需求中。但是,长者赫尔穆特·冯·莫尔特克(Helmut von Moltke)的一句名言:“没有计划能够与敌人保持联系”也适用于要求:“没有一套要求能够与开发商(或用户,您选择的)保持联系”。德怀特·艾森豪威尔(Dwight Eisenhower)提出了可用于需求的类似计划建议:“计划不算什么,计划就是一切。”在需求中引用的内容可能是:“需求无所谓,收集信息并定义需求就是一切”。换句话说,定义需求的过程对项目和组织而言是重要且有价值的,而不是需求文档本身。

在这种情况下,为什么要打扰记录?

因此,如果我们不能真正知道何时获得了完整的信息并提出了完整的要求,我们什么时候停止?而且,如果价值在于流程而不是文档中,那么文档的目的是什么?

我不建议我们不要以某种形式制作需求的纸质版:书面的用户故事,功能列表,业务需求文档或产品积压单上的项目。记录需求很有价值。但是,该文档不能成为我们的主要目标。解决业务问题是。

与任何文档一样,需求文档的目标是证明过程已完成。到目前为止,需求文档显示需求过程已经完成。用户案例是信息收集和对特定解决方案所需的功能部件进行分析的结果。对于用户故事,可能会暗示需求过程才刚刚开始,因为团队随后讨论用户故事并将其分解为较小的用户故事,然后可能会或可能不会写下需求。同样的态度也适用于需求文档:正如Alan Davis所说,需求是“系统发展的控制点”,需求也在发展。

一种不礼貌的解决方案

由于需求文档理论上是解决方案的完整,正确和准确的表示,因此您可以始终在系统投入生产后上交需求文档。在上世纪90年代的合同中,我们保证所提供的软件完全符合要求,否则客户不必付款。当我们提交完整且经过批准的软件时,我们通过提交要求来履行该义务。客户接受了需求文档应该反映已安装的软件,并且最终交付的内容可能与人们一开始所想的完全不同。因此,随着系统的发展,我们也对需求进行了发展。当我们交付系统时,实际上我们确实交付了与该系统匹配的一整套要求。我们知道我们已经完成了。

我们做不到

史蒂夫,听起来您是在建议我们只是开始编写软件并按照要求定义需求?

否。这是我们最后提供的需求文档,而不是需求。在大多数情况下,会涉及一个提案或一个业务案例。我们根据提案和初步概述,当然也包括我们对整个行业的了解,为伊利诺伊州埃文斯顿的一家保险公司编写了所有软件支持系统。对于看门供应公司和电信计费系统而言,同样适用。但是,我们为假肢制造商编写了该系统,这对我们来说是全新的业务,而为一家进出口碎布的公司编写了另一种系统。 (在这种情况下,我什至不知道生意兴隆)在这种情况下,我们进行了业务分析工作:我们提出问题,直到我们了解该业务或至少是问题域,整理信息,确认我们对什么的理解为止。完成和需要什么,然后在概念上提出解决方案。从那里开始,需求随着系统开发而发展,并在项目结束时交付,完成。

现在,我不建议您更改需求和系统开发的方法。向您的管理人员建议,如果您没有被嘲笑到外面或被强迫休假,您可能会随同完成的系统一起交付《业务需求文档》,这可能不会赢得任何政治意义。但是,您可以以这样的态度开始您的需求流程:在解决方案实施之前,您将没有关于问题和解决方案的“完整”信息(因此也没有“完整”的要求)。您可以假设在团队开发解决方案时会继续提供其他信息,并调整您的思维方式以及项目和软件开发过程以适应这一事实。

我看不到视线的尽头

但是我们怎么知道我们完成了?正常的流程是说,当固定的和已批准的一组需求已变成代码或以其他方式实施并准备好投入生产时,我们便会完成。如果某些时候需求没有确定,那么什么时候完成项目?

在敏捷中,答案通常是“从不”,但实际上是“何时”。 “任何时候”是指“每当资金用完或重新分配给优先级更高的项目时”或“每当产品所有者(客户)决定该项目结束时”。作为业务分析师,您可以根据您的经验,直觉和更多行人因素(例如时间限制或截止日期)来确定完整性。当您拥有“足够”的信息来构想可行的解决方案时,您就可以确定“完整性”。基本上,确定文档完成的基本问题是:“这些要求是否定义了问题的完整解决方案?”

并且,当项目完成时,您可以说,除了要在下一个版本(或下一个sprint)中添加的更改以外,要求是根据您当前的信息完成的。直到那时,您永远无法真正知道自己不知道的东西。

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

史蒂夫·布莱斯

PMP 史蒂夫·布莱斯在业务分析,项目管理和软件开发方面拥有超过43年的经验。 他为开发业务分析流程的公司提供咨询服务。他是IIBA BABOK指南3.0的委员会成员。他是《业务分析:成功的最佳实践》一书的作者。

©BA Times.com 2020

麦格雷戈徽标白色网站