2009年9月15日星期二10:25

Bad Ass BA;同行评审。第1部分。

撰写者

由丽贝卡·伯吉斯(Rebecca Burgess)合着

badassreq1

橡皮图章还是客观质量检查?

当我要求对需求文档进行“同行评审”时,我期望在将需求文档提交给涉众之前进行质量保证检查。有人认为:“哦,你是我的朋友。我永远不能批评你的工作。”但是,如果您只是盖章(未经严格审查批准)我的工作,那么您根本不是我的朋友。如果我的朋友/同行/同事/研究员BA没有“拿出红笔”(或打开曲目更改)并返回很多评论和问题,我会担心。你会告诉你的朋友,她吃了菠菜,然后让她午饭后回到办公室,不是吗?出于同样的原因,您是否会在将其需求文档提交给客户进行审核和批准之前对它的需求文档进行仔细审核?

应当在多个级别上审查文档。通常,它们是:

  • 业务案例同步检查
  • 需求文档完整性检查
  • 需求声明内容检查
  • 需求文件内务检查

这些检查是过滤器;也就是说,如果文档没有通过业务案例同步检查,则将停止审核。仅当文档和业务案例同步时,您才检查是否合理,然后,如果这两项检查均通过,请检查需求声明的内容质量。最后,对准备发送给客户的文档版本进行内务检查。

通过检查每个级别的需求文档,您将对您的同伴有所帮助,并帮助他/他提供最高质量的文档。我们将在接下来的三个月中详细介绍每次签入文章的目的和方法。

为什么要进行同行评审?

Why bother with 同行评审s in the first place? Here are a few concise reasons to use this powerful tool:

提高正在审阅的文档的质量-眼睛越多越好。

尽早在项目周期内识别并纠正项目问题,错误和遗漏-早期修复的成本降低了几个数量级。

从同事的见解和错误中学习-如果他们不能成为一个很好的榜样,那么它们可能是一个可怕的警告。

拓宽您对业务其他领域的了解-对业务的了解越多,就越容易升任“企业分析师”职位。

提出愚蠢的问题-请参阅 Bad-Ass BA课程。第2部分.

人们使用什么借口来避免同行评议?您如何应对这些借口?有很多借口,但这是最常见的:

太可怕了!他们不会大声说出来,但这是真的。您必须通过学习接受批评是建设性的和有价值的,而不是破坏性的,并且不惜一切代价避免的,将自尊与对工作的评价分开。

这需要时间!是的,但是回报是可观的,既可以最大程度地减少错误的影响,又可以使BA逐渐成熟。

我们已经落后了时间表!您愿意让客户抓住错误吗?或更糟糕的是,错过了错误吗?

我对该项目一无所知!因此,您可以将您的评论限制在更一般的BA级评论中。那仍然很有价值。另请参见上面进行同行评审的原因中的“扩大您的知识”。

很难做!真正。这些文章将使其变得更容易,因此请继续阅读...。

业务案例同步检查

需求文档需要与业务案例同步。确实如此。我们需要检查收益,ROI声明,ROI报告,成功标准以及验证成功的方法。

顺便提一句,对于本文,假定业务案例包含需要解决的问题,对问题的影响者以及财务和非财务方面预期要实现的收益,目标和成功标准的说明。有关业务案例的更多信息,请参见 建立业务案例 和/或BA BOK的“企业分析”部分。

如果您可以对正在查看的文档回答“是”,请选中该项目旁边的框。

 第1部分。业务案例同步

  • 需求文档中是否引用了业务案例文档?
  • 您是否可以从参考中访问业务案例文档(或者该业务案例可能是某人的想象力的虚构内容)?
  • 有利益相关者名单吗?
  • 需求文档的“批准”部分中列出的人员是否涵盖所有利益相关者?
  • 项目利益是否也对业务有利?如果企业没有收益,为什么要进行该项目?
  • 业务案例的目标和/或成功标准是否由需求表示(并且需求可以追溯到业务案例信息)?
  • 对于每个收益/目标/成功标准,是否在相关要求中描述了一种衡量实现收益的方法,这种测量方法有意义吗?
  • 是否有明确要求提供衡量该项目成功与否的新数据?
  • 如果已经实施了收益/目标/成功标准的度量标准,是否已将该收益作为基线(最近进行了测量),并且在适当的要求中是否引用了基线数据?
  • 福利指标是否有目标值和/或范围?
  • 是否有说明用户期望和何时展示解决方案带来的财务收益的实现(项目交付后)?
  • 要求描述了企业将如何定期报告其实现ROI的进度的要求是否支持ROI索赔(一段时间内的预期投资回报)​​?
  • 根据业务案例,您是否认为所有关键业务需求都由需求组成?

如果未选中这些项目中的一项或多项,则存在风险,即需求文档与业务案例不匹配。同行评审的任务是以建设性的方式传达这些错误和遗漏。如果希望您返回书面反馈,请花点时间解释错误或遗漏的内容,并在可能的情况下提供示例。如果您要参加同行评审会议,请记下您想说的话,以免听起来太消极。

您是否已使自己确信需求文档和业务案例是同步的?没有?然后,对需求文档的审查应立即停止。业务案例需要更新,并且每个人都需要同意业务案例仍然有效。一旦文档同步,就可以进行完整性检查,这将在第2部分中介绍。

本文是4部分系列的第1部分。四个部分是:

别忘了在下面留下您的评论


塞西莉·霍夫曼 是赛门铁克公司赛门铁克服务集团卓越业务分析中心的高级首席IT业务分析师。 Cecilie的职业热情是对技术和业务团队进行有关业务分析师角色的教育,并赋予业务分析师自身工具,方法,策略和信心。 Cecilie是IIBA硅谷分会的创始成员。她在balsamfir.com上写了一篇有关个人激情摩托车的博客。可以通过以下方式与她联系 [email protected].

丽贝卡·伯吉斯(Rebecca Burgess) 是赛门铁克商业生命周期转换办公室的业务流程方法学分析师,并且是经过认证的六西格玛黑带。经过多年的发现问题并确定了软件的根本原因之后,她现在将其BA技能应用于战略性流程设计和改进。可以通过以下方式与她联系 [email protected].

此类别中的更多内容: «超越需求分析-企业分析 重塑资源图»

©BA Times.com 2020

麦格雷戈徽标白色网站