过渡要求
我们将举一个简单但令人沮丧的示例。高管希望将所有工人任务组织在花费多少时间上。这个想法是通过先快速完成任务来完成更多任务(不要笑-如果您没有遇到过这样的事情,那么您很幸运,可能是BA,但是可能会因为缺乏曝光而缺乏技能)。
这个要求有什么问题?如果您的答案是“无”,则无需阅读其余内容。如果不确定,请继续阅读。如果您可以准确地说出错误所在和原因,则应该编写此博客。
让我们将此需求分为所有需求类型和级别的BABOK类别。
第一步:高管对BABOK的“要求”是什么?
首先,它是“利益相关者”的要求,并且需要某种分析(思想)才能使其成为“实际”要求。根据BABOK的说法,“要求”是“已声明”和/或已确认的(“您真的说过吗?–好,知道了”)
第二步:什么样的分析?
我们可能会考虑将声明分解为更详细的内容-任务是什么,每个任务花费多长时间。这是幼稚的分析师(幼稚的IT分析师)方法,如果不立即停止,将导致实施失败。
业务分析师的方法是考虑推动利益相关者“需求”的业务需求。因此,什么是业务需求分析可以帮助解决利益相关者的“需求”(保存或建立它)–您的时间已不多了。
也许业务需求是一个愿景:“让我们先完成最短的任务,这样我们才能完成更多的工作。”
NOPE(无济于事)重新提出了利益相关者的要求,因为愿景使我们离开了我们的位置,甚至BABOK都说,“愿景”是如所述的持续/有效的可能性最小的“要求”。
也许业务需求就是业务需求:“我们需要首先完成最短的任务才能完成更多的工作。”
ICK –再次重申利益相关者的要求是“业务需求”并没有解决问题–我们仍然坚持以“过于简单”的方式组织任务,或者与利益相关者进行斗争。
也许业务需求是能力上的差距:“我们无法完成足够的工作,因为我们无法首先组织最短的任务。”
Phooey –这无济于事,因为尽管它是正确的(我们无法找出最短的任务,因此无法首先完成它们),但尚不清楚填补这一空白是否会导致制胜法宝。
也许业务需求是一种业务解决方案方法,例如“让我们首先完成最短的任务就可以完成更多的工作”。
嗯……这可能更好,只是因为它表明:
- 我们想要完成更多的工作(或者至少要执行)。
- 我们可以使用首先执行最短任务的方法。
现在我们进行一些分析–我们将利益相关者的需求分为两个部分–一种业务解决方案方法,另一部分。另一部分–是否也有要求?
BABOK提供解决方案范围的业务要求,如“业务解决方案应完成更多工作”。
否-我已经看到了这样的要求,但称它们为“解决方案范围”已关闭。
BABOK提供了业务案例要求,如“组织最短优先的任务将在相同的时间内完成10%的任务”。
这听起来像主管的想象,但是请注意,上面的陈述不是商业案例,因此也不是商业案例的要求。该声明是“证明”声明,没有证据或分析成本与收益的关系。如前所述,它只是利益相关者的另一项“要求”,即利益相关者思想的陈述减去任何证明可行性或估算投资回报的认真尝试。
将其转变为“业务案例”需求将建议制定一个实际的业务案例,包括可行性(最短的任务是什么-如果首先尝试它们会发生什么-最长的任务是什么,以及它们与短任务的关系?) 。我一人赞成,但我知道,如果我坚持一个商业案例,那听起来就像是我对高管的思想提出了质疑,在理论上,在为项目编写支票之前,谁负责尽职调查。
同样,没有好,除非:
- 我们不喜欢高管,而是想大声疾呼(要求业务案例,并因被解雇或其他原因避免高管)
- 我们打算在不讨论的情况下构建我们认为的任何内容,因此有可能发生冲突
- 我们打算建立高管人员似乎要求的内容(是的,当IT建立您告诉他们建立的内容时,可能意味着“您要的是它”,以及单词不代表他们的意思,而是三语!) IT团队认为您应得的“更多”。
- 即使您选择参加诸如管理或销售之类的“人事工作”,并在数学上得到B(C),您仍然是IT天才。
- 即使您不听,IT也不喜欢您做正确的事
- IT部门从经验中知道,如果您发现与您的确切说明有任何出入,您将提出合适的建议,而他们早在几年前就放弃了,并准备
我们已经超出业务需求,并且我们当然不希望“让我们先完成最短的任务以完成更多工作”成为解决方案要求(功能或“质量”非功能)或过渡要求。
答案是什么?您如何提出利益相关者要求:“首先让我们围绕“最短的任务”来组织系统,以便完成更多的工作。”通过这种方式,它可以开始讨论,而不是切断与执行官的交流和信任(对她的想法非常聪明)。
在下面的评论中回答,以便有机会在这个空间中撰写您自己的博客(是,有社论帮助),并拥有有趣,无所畏惧的文学士读者!
不要忘记在下面留下您的评论。