2020年5月27日星期三12:08

我们说的是同一语言吗?

撰写者

当涉及到需求时,业务涉众和解决方案团队可能会使用不同的术语。 

创建专门为一组或另一组量身定制的需求可能会导致混乱和无法实现的期望。 作为业务分析师,我们可以采取一些行动,以帮助确保利益相关者对具有下游利益的术语有共同的理解。

共享术语

大多数组织使用的术语范围从成立到现在。 术语的添加方式可能会代替术语,但含义可能会有所不同。 根据创建解决方案的时间,每个解决方案可能都采用当时流行的技术术语。 

一些术语是行业甚至公司内部特有的。 根据造成混乱的部门,某些术语可能具有不同的含义。 并购使情况更加复杂。 结果是整个组织中业务和技术词典的差异。

除了了解项目的当前术语外,业务分析师还可以与业务和解决方案团队的利益相关者合作,共同理解项目中将使用的术语。 这可能以字典,分类法或本体论的形式出现。 我发现决定一个主要术语及其定义会有所帮助,但还包括:

  • 别名(这可以是利益相关者组或先前条款之间的转换)
  • 别名差异(如果含义或关系存在差异)
  • 与其他术语的关系(本体允许多个结构化关系)
  • 允许值(如果适用)
  • 数据定义(通常在稍后的需求获取期间填充)
  • 例子

广告

在确定较高级别的需求时采用此方法可为进一步详细的需求奠定基础。 尽管利益相关者可能会因为“他们想开始”而拒绝这样做,但这对每个人都有好处。 一些好处是:

  • 更准确的要求
  • 重新讨论相同主题的时间更少
  • 可能减少开发时间
  • 改进的质量检查测试(尤其是如果使用Gherkin结构化语言)
  • 为数据架构提供基础
  • 更好的跟踪和积压可见性

需求架构

当您对术语及其含义有共同的了解时,这将使业务分析师可以更有效地定义需求体系结构。  根据BABOK 3.0,需求体系结构的目的是确保需求相互支持,以完全实现目标。当可以不同地理解术语时,很难做到这一点。

我无数次尝试寻找积压的项目,但是其中包含的术语是根据一个人对需求的解释量身定制的。 在创建需求时,我会考虑某个人如何尝试找到它并识别内容。 如果较早同意术语,我可以以所有利益相关者都可以识别的方式来命名需求。 

使用约定的术语还可以简化图和模型的创建。这可以减少工件的数量和复杂性。 这使需求评审和批准变得更加简单。

明确的共识有助于范围和期望。 如果企业使用的术语范围超出解决方案提供商所理解的范围,则可能会导致期望值丢失,并且只有在用户验收测试之前才能发现。 相反的情况导致不必要的范围增加。 

同样,这在将需求分解为可管理的待办事项时也有帮助。 知道术语的含义可以防止添加重叠或有空白的需求。 由于术语已经标准化,因此可以更轻松地识别需求重用的可能性。

 如果无法达成共识,则使用最常用的术语并包含别名。 当需要面对业务时,我避免使用会引起业务涉众困惑的技术术语。 

在项目期间,首选术语可能会更改。  我经常希望需求管理工具允许可变的占位符绑定到字典,分类法或本体。 如果该术语或相关信息发生了变化,我只需要在一个来源中编辑该变化。

能见度

在项目开始期间,项目团队应确定项目涉众及其对项目的责任。 他们需要确定需求的存储位置,需要访问的人员以及需要存储的属性。 这将为业务分析师如何共享业务分析信息制定计划。 

共享的术语和结构化的需求体系结构有助于查看项目范围。 利益相关者可以通过使用约定的条款进行搜索来确定特定要求适合的位置。  它可以减少会议或业务分析师交流的需要。

这对企业很有帮助,因为他们可以计划功能发布,SME可用性和UAT资源。 它可以帮助IT经理规划人员,硬件,安全性和其他方面。 如果涉及监管,则合规团队需要尽早参与,从而获得上述好处。

结论

由于公司有各种各样的词典,因此建立对术语的共享理解会带来巨大的好处。 业务分析师可以更准确,更有效地创建需求。 团队无需重新进行相同的讨论即可受益。 开发人员和质量分析师更有可能构建和测试涉众的意图。 共同确定的词典是创建结构化需求体系结构的基础。 这可以提高利益相关者的可见性,以便他们可以找到需求并为之制定计划。 

迈克·迈因里奇

迈克·迈因里奇是一名经过认证的业务分析专家,在交通,版权管理,审计管理和广告行业拥有超过14年的经验。当他发现每个项目或应用程序都是独特的时,他喜欢应用BABOK中的最佳实践来实现项目目标。可以通过电子邮件与他联系 [email protected]

©BA Times.com 2020

麦格雷戈徽标白色网站