2014年6月23日星期一09:09

要求:关于业务

撰写者

 天线侠June23 必须交付什么才能增加价值。罗宾·戈德史密斯(Robin Goldsmith)在其有关“真正的业务需求”的书中(是的,他大喊大叫)明确了需求的定义。谁能争辩?在该短语中,我们直观地知道该短语中的三个关键单词是。 “价值” –如果没有价值,则就此停下来。 “必须”是开创性的,因为正是这个副词将讨论集中在需求(如果必须完成,这是一个需求)和“什么”上。 “什么”是您可以购买,放置,制造,编码或修复以改善业务或解决业务问题的东西。

然而,戈德史密斯先生实际上是在旷野里哭泣的声音。他公开承认与IIBA [i]和BABOK [ii]在需求方面存在分歧。当他使用第二个单词(著名的限定词)并谈论业务需求时,他的孤立感就显现出来了。在IT部门工作20年之后,我感到他的痛苦,分享他的挫败感,并希望“需求”一词的限定词消失。没有功能,非功能,技术,业务,高级,详细,限定词。只是“要求:必须做什么才能实现价值。”

作为IT从业者,我们没有勇气放弃这些形容词,因为当我们剥开葡萄皮时,我们知道有时候(也许甚至经常),最佳的发展路径与软件开发,修改或改进无关。在IT领域中,根本原因分析仅分解计算机程序(或缺少这些程序)以在其中找到一些“根本原因”。毕竟,进入其他问题可能带来的可能性的领域将超越我们的集体界限,对吗?但是现实是,业务是业务的起点,业务是业务的终点。我的意思是通用术语“业务”,即公司或组织的职能。总体而言,IT是完成业务的一组工具。它没有超越业务目标的内在作用,明显的例外是生产软件的公司。

IIBA和其他许多需求学者指出,业务需求是“高层次的”,并且暗示或公然地忽略了它们在完成软件项目中的作用。我要反驳的是,业务需求至关重要,而这些业务需求必须尽可能详细,以揭示业务面临的问题并提供解决方案的途径。这是Goldsmith的问题金字塔所基于的前提。他的文章写得很好,描述了您如何分解业务需求,然后为软件开发规定了转换为功能需求的过程。我在这里不会做单纯的书本报告,而是需要赞扬他的洞察力,他在讨论业务需求,质量和可测试性如何成为任何企业(尤其是软件开发)成功的关键。我在这里的目的是谈论他的基本前提,将其作为成功部署敏捷方法来开发软件的基石。

敏捷世界,尤其是SCRUM,充满了过度扭曲和通常可笑的隐喻。有时以某种方式执着做似乎掩饰了他们声称从更加结构化的同行那里获得的解放。我发现自己正在寻找窗帘后面的那个人,他按下操纵杆以使烟雾和火花四处飞舞。话虽如此,我认为敏捷原则是牢固的,其各种方法都是有效的。敏捷能够而且将是公司改善软件项目成果的最重要的单一转变。但是对我而言,这实际上只能归结为适当的敏捷组织所接受的一项基本原则—与业务有关。

在敏捷环境中成功的最关键的关键是问题,产品,挑战的业务负责人与负责解决上述问题/挑战的开发团队之间的积极,日常,参与,投资,领导和沟通。像大多数组织变革中的“动作”一样,敏捷将在一个没有自上而下的组织中丧命。主机代管只是总体事实的一种物理表现或要求,即如果没有拥有业务目标的人持续不断的积极投资,软件项目将最多只能表现不佳,并且失败或造成的成本超过合理的范围。从最坏的投资回报率分析中得出。使用SCRUM术语的“产品负责人”定义了业务需求。它们是否称为用户故事无关紧要,但是它们具有有用的详细程度也很重要。继续构建冲刺内容的“发现”过程必须限于其努力将如何为一开始就明确知道的业务目标做出贡献。如果您不了解造成痛苦或效率低下的原因,或者如果您没有找出阻碍最佳路径的具体差距,那么为什么要首先开始一个软件项目?我希望不是因为IT部门建议这样做。

痛苦中是否有软件程序甚至都没有关系。该软件的存在并不以为是业务问题的原因,甚至无法解决问题。如果软件对于完成业务至关重要,并且设计不当,则可能是问题所在。业务也可能有其他问题,更改或增强工具将无济于事。制定详细的业务需求将揭示根本原因。

敏捷开发可以并且应该以速度和重点进行;完成任务,与业务目标所有者确认,调整并重新完成,直到完成。但是,在制定业务需求之前,甚至不要一路走来。详细的业务需求。

那么详细的业务需求是什么样的?

考虑到一家公司希望通过某种提供“特殊”关注或定价的计划来奖励信誉良好的“活跃”客户。这可能是一个IT解决方案,也可能是一个IT解决方案。让我们专注于对业务有帮助的方面,并“具体说明”它。

分解的业务需求:创建首选客户程序

1.为经过验证的信誉良好的现有客户提供一种获得特殊定价和产品选择注意事项的方法。
1.1识别并定义“超级”客户。
1.1.1提供一种识别客户的输入机制。
1.1.2批准有效的应用程序输入
1.1.2.1指导申请人提供完整且可行的申请。
1.1.2.2提供一种准确的方法来甄别不是信誉良好的客户的“假装”

1.2验证现有客户的状态是否良好
1.2.1处理客户验证信息
1.2.1.1将经过验证的现有客户定义为最近3年与公司进行积极贸易的客户
1.2.1.2验证客户是否信誉良好
1.2.1.3为客户提供一种提供验证并轻松加入“首选”计划的方式。
1.2.2拒绝不符合条件的客户,同时鼓励其他销售
1.2.2.1在虚假的声称是首选客户和尚未达到阈值的客户之间进行区分
1.2.2.2提供资格的途径和激励措施
1.2.2.2.1设置试用会员资格以鼓励更多活动

1.3确保帐户存在,并且客户通过验证其“常规”帐户状态来启动特殊关系。
1.3.1设置一个规则,以使首选客户在验证其常规帐户状态之后有资格。
1.3.2为首选客户提供与公司联系的安全且简短的方法,以利用该客户有资格并被接受的特殊帐户。
1.3.2.1设置用户未注册或没有资格时可以参加该程序的尝试次数的限制。

所以…

当业务完成后,分解业务需求-诚实,详细地了解他们的差距和挑战-然后,他们才求助于IT,以了解他们是否掌握解决方案的关键。只有到那时,敏捷团队才能进行有意义的旅程,以“完成”和“发现”将利用技术来使事情变得更好的需求。

即使我们承认在此过程中发现了软件工程中的解决方案要求,“思考一切”仍然有回报。采用一种使您与业务问题紧密相关的方法,以便我们知道我们试图达到的“完成”在旅途中确实值得。

苹果在市场上的成功来自于对市场的了解,并将消费者的需求放在首位。我不知道他们是否由敏捷团队构建一切,是否采用看板原则,是否使用5 Ses并基于精益原则进行价值流映射。我只知道他们花了很多精力去了解人们的需求。对于苹果公司而言,这不是一项“高级”工作。这是根本。
保罗·安特曼 ,PMP,LSS,ITIL是Capgemini公司Sogeti的顾问。他已经在IT领域担任业务分析师和项目经理20多年。

参考文献:
戈德史密斯(Goldsmith),罗宾(Robin):《发现软件项目成功的真正业务需求》,c 2004 Artech House,马萨诸塞州诺伍德。
敏捷软件开发宣言, www.Agilemanifesto.org  
SCRUM联盟,www.scrumalliance.org

尾注:
[i]国际商业分析研究所
[ii]商业分析知识

 保罗·安特曼

保罗·安特曼 是一位经验丰富的项目经理和业务分析师,拥有20年的项目经验 /资产组合管理,需求确定和系统分析。保罗为每项工作带来了一系列强大的技术和商业技能,而这通常需要综合技能。他管理过传统的SDLC项目以及基于敏捷的工作。他通过了Lean Six Sigma,ITIL和Project Management的PMP®认证。保罗在其当前雇主的PMI认可的预科课程中,指导同事和客户进行PMI认证。 

©BA Times.com 2020

麦格雷戈徽标白色网站