2009年4月28日,星期二,01:00

外包团队的需求定义

由Matthew Morgan撰写

在当今的经济环境中,企业组织要求集中精力关注财务纪律。 IT组织发现自己被要求以固定预算支持生产中的应用程序,并且新开​​发很大程度上仅由效率规则来批准。软件应用程序是提高效率的重点,因为合并和集成项目既可以减少多个孤立应用程序的支持成本,又可以简化最终用户的业务流程。

为了事半功倍,IT软件团队在2009年开始寻求创纪录数量的外包。据《 IT World》报道,2009年的经济崩溃使软件项目的外包商使用率达到创纪录的1级。

随着CIO将外包视为提高软件项目效率的战略要务,正在引入新的挑战,这些挑战威胁着CIO正在实现的相同效率。

根据定义,外包引入了第三方商品和服务以增强能力。由于IT软件具有关键任务意义,因此这种第三方影响会给业务带来新的负担,以确保这些外包团队得到正确的目标导向,正确的指导和正确的管理,以确保生产力。

尽管有很多方面可以确保外包商成功,但研究表明,IT软件项目的真正控制点是应用程序需求定义。

接下来的内容探讨了行业,分析师和客户的建议,以重点关注如何确保应用程序开发准确性和控制风险的要求,以便IT组织可以将这些效率转化为更大的动力并降低运营成本。

需求沟通:IT项目团队的挑战

需求沟通的质量对于IT项目团队来说是一个巨大的挑战,无论它们位于同一地点还是分布在各个地方。在软件开发生命周期中,专用于需求定义的时间主要花费在

在生命周期的早期阶段,它涉及数十名主题专家,通常具有业务分析师或业务系统分析师的头衔。

但是,最近的研究表明,尽管业务分析人员确实消耗了项目预算文档要求规格2的10%,但他们的努力结果通常是以难以理解的书面文档的形式。这些基于纸张的文档主要由IT项目团队使用,他们必须努力理解作者的意图,并将业务需求转化为详细的规范文档。

即使在主要由内部开发团队组成(即未外包)的IT项目中,也可以测量由此产生的返工和浪费。 IAG告诉我们,需求不佳的典型浪费和返工水平直接导致了预算消耗的40%以上3。

随着IT组织逐渐接受外包团队作为IT软件项目团队的扩展,沟通要求的挑战变得更加严峻。 MetaGroup告诉我们,利用外包团队的组织中,有超过50%的组织在内部开发人员的心中拥有关键的业务应用知识,而这些知识已被外包劳动力池剥夺了权利。4.由于失去了主题专业知识,导致外包IT组织增加了对客户的依赖

生成高度精确和特定的需求文档。 MetaGroup还告诉我们,外包服务提供商的周转率平均为15%至20%,这可能会导致分配给您的项目的特定人才在项目周期内发生流失的可能性。这继续加强了对易于参考和消耗性需求指导的需求。经验丰富的外包客户和行业分析师已经确定了适当的重点领域,以确保IT项目团队在部署外包时获得成功。尽管有许多方面可能影响已转向利用外包团队的IT团队的成功,但也有少数几个可以极大地提高成功。 IDC最近关于外包成功的控制点的报告帮助将重点吸引到了最重要的领域。

IDC继续阐明控制点,以确保外包是一项 效率的机会 而不是 对效率的威胁 将战略接触点纳入外包团队。 IDC将这些接触点记录为需求定义,质量保证和进行中的项目协作5。其他分析师(例如Gartner,voke和Forrester)都提供了支持研究,这些研究都指向相同的控制点。

控制控制点

如前所述,在协调外包团队时,要求,质量保证和协作的重要性是公认的原则。但是,当IT人员将控制点彼此相对地布置时,将揭示需求的逻辑焦点优先级。如图A所示,质量保证和项目协作控制点直接受项目需求定义阶段的深度,质量和理解的影响。实际上,很少有单个质量保证测试方案不能直接基于(或追溯到)功能或非功能需求。现代质量保证趋势是朝着基于测试的开发的方向发展,这种趋势随着外包团队的发展而加速。基于测试的开发在测试用例和需求之间建立了一对一的关系,其中,一个测试用例实际上可以用作需求资产。此外,与开发的协作通常直接与业务需求的实施或软件如何影响该需求相关联。

图A:与质量检查和协作需求的关系

通过专注于改进需求定义,利用外包组的IT项目团队可以更好地管理所有控制点,从而改善质量保证和进行中的协作工作的影响和重点。

需求沟通问题

正如我们在上一节中讨论的那样,与外包商合作带来了围绕项目目标调整分布式第三方资源的明显挑战。仅位置挑战就可能会引入时区和协作障碍,从而给生产力和效率带来负担。但是,对于第三方组织,IT团队可能会引入其他挑战,包括流程,工具,培训,上下文,领域专业知识和激励措施。

需求沟通恰恰是这一挑战的中心。正如我们所讨论的,传达需求的传统方法,包括功能,功能需求和非功能需求的枚举列表,业务流程图,数据规则等,通常记录在大型文字处理或电子表格文档中。当应用于外包团队时,这种沟通方法会造成巨大的浪费和失败的机会,因为理解的障碍太大而无法克服。

错误的解释和缺乏需求确认会造成人为的(或错误的)目标,从而消耗宝贵的外包资源。由于软件开发的性质,这些错误的目标通常会在错误实现的代码中体现出来,从而导致成本高昂的浪费和返工。外包提供商通常将返工视为“变更”,然后将这些“变更”退还给客户。这将继续削弱IT组织在最初采用外包时努力实现的效率。

模型,验证和需求合同

为了显着降低通过自然语言文档进行无效需求沟通的可能性,IT组织正在过渡到更精确的手段来传达需求。

这些工具之一就是采用基于模型的方法以高度可视的方式传达需求。需求模型通过高度精确的数据结构提供了详细的上下文捕获。完整的模型包括使用普遍接受的格式作为结构指南,并将它们相互链接在一起,以创建未来系统的整体表示。这些整体表示中使用的格式包括基于角色(或参与者)的流程的用例,用户界面屏幕模型,数据列表以及决策点与业务流程定义的链接。这些结构增加了功能和非功能需求的枚举列表。

模型的好处包括使用仿真来确保了解需求。仿真是一种通信机制,可以使需求涉众按线性顺序遍历流程,数据和UI流程,以表示系统应如何运行。利益相关者能够详尽地见证功能,以结构化的方式使用信息,从而完全消除沟通不畅的现象。模型和仿真还为 验证。验证是一个过程,在此过程中,利益相关者按适当的顺序审查每个需求,做出适当的评论,然后签字以确保需求是准确,清晰,理解且可行的。可以将需求确认视为可以为外包计划实施的最具成本效益的质量控制周期之一。

由于需求是系统的“蓝图”,因此外包的利益相关者可以在实施过程中利用需求模型和模拟来了解项目目标。模拟通过提供目标的视觉表示消除了歧义,从而消除了解释。

出于各种原因,对于大多数IT项目来说,丰富的需求文档通常是指定的交付物,其中包括监管合规性(Sarbanes Oxley,HIPAA等),内部过程规范以及其他内部审核周期。

该文档还充当客户与外包提供商之间的合同。模型可以作为本文档的基础,下一代需求工作台解决方案(例如Blueprint需求中心)可以将模型转换为丰富的自定义Microsoft Word文档。由于这些文档是自动生成的,因此构建和维护这些文档所需的工作量很小

摘要与详细:外包商参与需求定义

外包提供商已经学到了大量有关如何提高需求通信效率的知识。许多提供者正在转向更多地参与需求定义过程。其他人继续在更传统的模型中运行,该模型将他们从需求定义过程中抽象出来,而这留给了客户。

西方外包商已率先开创并实践了一种方法,其中包括努力与客户一起阐明,记录和传达需求。这种方法的价值主张的一部分是,外包提供商减轻了误会的风险,并确保外包团队的成员对项目目标和可交付成果有了更清晰的了解。这种方法通常称为 详细方法 用于外包项目中的需求定义。

印度和欧洲的外包商在很大程度上继续采用从需求的定义中提取外包提供商的做法。这种抽象意味着客户有责任向外包提供商清楚地记录和阐明需求。这就要求客户知道项目需求的解释中存在文化,时区,过程和一致性障碍,因此他们必须非常准确,精确地指定项目需求。这种方法通常称为 抽象方法 用于外包项目中的需求定义。

对于IT组织而言,重要的是要了解这两种方法中的哪一种,因为它们可以极大地改变确保清晰地了解项目要求所需的方法和实践。

解决方案:案例研究

应该在项目的最早阶段考虑并应用本文中描述的原理,这不仅为后续工作奠定了基础,而且由于发现和解决了错误的时间越早,这些错误的影响就越便宜。正如错误的成本在生命周期中发现的时间越晚呈指数增长一样,推论也是正确的-尽早发现并处理这些错误可以节省成倍的成本。在外包开发的情况下,这应该甚至在选择外包供应商之前,即在招标书(RFP)的开发过程中发生。

蓝图合作伙伴Knowsys提供了这种情况的示例。 Knowsys的工作人员被合同推迟到RFP周期的后期,而RFP周期却在北美一家主要的金融机构出现了问题。该公司需要为其财富管理业务重新架构其整个电子商务平台。在RFP流程中已经进行了大量投资,当Knowsys到达时,客户刚刚开始与供应商的高级主管一起参加一系列供应商演示,总结了他们对外包合同的出价。随着演讲的继续,“房间里的大象”变得越来越大。很明显,出了什么问题。

RFP中指定给供应商的要求不完整。信息冲突且细节级别不一致。经过进一步分析,发现整个业务领域都被忽略了。事实更加复杂的是,主题专家错误地假设了业务的某些领域是如何运作的。这些错误进一步加剧了各个供应商的竞价(总共七个),他们根据自己的假设进行了补充以填补空白。结果是一系列供应商的演示文稿,它们之间截然不同,几乎就像是他们试图解决七个不同的问题一样,而这些问题都不是客户的。除了发现RFP要求中的这些主要缺陷之外,该活动还明显表明邀请供应商的过程并不完美。显然,有些人在提案中投入了大量时间和精力,而其他人则少了一些。没有人对客户的业务或情况有足够的了解,无法指出明显的缺陷。

实际上,按下了重置按钮。高管们指示该小组重新参与RFP,而该小组现在已参与Knowsys。这次,高管人员的赞助是头等大事,业务的各个方面都被定向为易于访问和支持该计划。全面分析了业务的所有相关方面,并将其需求合并为需求的统一表示。进行验证以确保覆盖范围,深度和清晰度。供应商选择投标的过程更加严格(与第一个周期中使用的公开邀请形成对比)。邀请了一群了解客户业务的专注于卖方的小公司。 Knowsys团队还确保与供应商的关系更加协作,同时尊重招标过程所需的公正性。他们确保了与客户-供应商联系的多个方面,并采取了措施以确保所有假设均得到验证。最后,重点还放在质量保证和测试方面(而不是只关注要建造的产品的要求),以使投标人的建议更加全面。

这些举措的最终结果是巨大的。与上一轮相比,第二组的介绍由一组人数少得多的竞标者进行,就像白天和黑夜。很明显,每个供应商都非常准确地了解了客户的问题和目标。每个提案都很引人注目,并且各自提出的解决方案都有独特而有趣的变化。

由于最初的RFP周期失败,因此选择了一家供应商,并且该项目正在进行中,比预期的要晚。每个人都对拥有如此重要的开发计划,现在拥有的规格,他们选择的供应商以及拟议的解决方案充满信心。当项目即使在项目过程中发生意外的业务变化时,也能按时,按预算交付且满足所有成功标准时,这种信心得到了验证。如果这家金融机构在第一轮中选择了一家供应商,然后在此基础上进行开发,那么结果无疑将大不相同。

结论

在最近的经济形势下,随着公司拼命寻找降低IT成本的方法,软件开发外包的稳步增长已经增加。节省成本的承诺是可以实现的,但只有那些专注于外包安排中三个重要的需求控制点的人才能实现:需求沟通,需求参考和需求验证。通过掌握这些

适当的流程,实践和自动化将大大提高外包业务成功的可能性,从而节省所需的成本。

脚注

[1] 2009年挑战技术离岸的五种趋势
[2]棘手的需求问题手册2005-流程影响-Karl。 E.威格斯。
[3] IAG需求调查,2007年
[4] MetaGroup,搜索CIO近海世界的十大风险
[5] IDC分析师Melinda Ballou,通往ALM的海上途径,RedmondMag


马修·摩根(Matthew Morgan) 是一位15年的营销和产品专业人员,具有成功推动数百万美元营销,产品和地理业务扩展工作的丰富经验。他目前担任高级副总裁,首席营销官 蓝图,是需求生命周期加速解决方案的全球领导者。在此职位上,他负责战略营销,合作伙伴关系和产品管理。他过去的任期包括将近十年在Mercury Interactive(由HP Software以$ 4.5B的价格收购),在那里他担任了价值7.4亿美元产品类别(包括Mercury的质量管理和绩效管理产品)的产品营销总监。他拥有南阿拉巴马大学的计算机科学理学学士学位。他拥有南阿拉巴马大学的计算机科学理学学士学位。

©BA Times.com 2020

麦格雷戈徽标白色网站