业务分析师：清晰交流可能抑制软件开发失败

尽管数十年来在编程语言和测试工具方面都有了很大的进步，但是应用软件开发项目仍然极度的令人不满意。

Standish Group咨询公司报道说，软件开发项目彻底失败的比率在降低——该组织最著名的“混沌”（CHAOS）报道第一次发表时候说，1994年为31.1%，而2006年为19%——一直需要进行改善。

专家说，如果想有更大的发展，这还取决于企业会在多大程度上随着应用软件的变化而改变需求；需求在多大程度上明确地传达给了开发人员；并且业务分析师需要明确——这是指在开发与业务方面的联络——将每一方的需求向另一方解释。

展望未来

“BA的关键作用不是仅仅明白在那个时刻的业务需求，而是询问需求——会发生什么、为什么它会发生、什么时候发生。”Dan Walker说道，他是International Truck and Engine, Warrenville, Ill供应链业务系统的领导之一。

Walker说，在很多年以前，当他意识到IT企业并没有完全与其它商业领域同步的时候，他们公司就已经开始重视BA的作用了。“我们不希望IT企业是一个黑洞”，这是指，如果对业务需求描述不够充分的话，就会造成很大的损失。

Joe Marasco是Ravenflow的CEO，一个Emeryville，他说，Calif.-based公司的产品希望与开发商的需求结合起来，软件工程中至少有一半的错误是因为“对需求理解不当”所造成的。

实际上，需求开发日志中（Requirements Development Journal，http://www.requirementsdevelopment.com/) 93%的读者抱怨，用户最初所期望的功能并没有完成，然而恶化的原因其中89%是因为列举不全需求所造成的，回答者中85%说他们不得不努力的去猜测这些模糊的需求。由于给了这些错误传达，Marasco说，“在失败的工程中，开发人员承担了不公正的责备。”

如果是更复杂的事情，需求将处于更不稳定的状态。然而，微软Visual Studio项目组的产品经理Ian Knox说，追踪收集到的信息越多，结果就会越准确，应用软件应该影响组织的需求。

设置基线

虽然每个变化都受到时间和/或预算的影响, 但是为应用软件建立一套基本的需求，这将有助于所有的利益相关者衡量不可避免的变化所产生的影响。

“你不得不在设计阶段花费大量的时间，”Arsu Group的创始人SeemaPvhull说，Phoenix-based公司在供应链商业过程中与客户就业务流程再设计方面进行协商。她说，业务和软件开发人员之间讨论最关键的时候就是，当应用软件第一次概念化的时候。“否则IT人可能逃开，并且开始将技术规格集中在一起，可能最后所采取的技术是有许多附加功能的，但这并不是企业最需要的。”

Ravenflow的Marasco说，人们对需求处理的过程和文档需求漠不关心。最可能发生的情况就是，业务分析师编写了一套足足有“曼哈顿岛黄页”那么厚的需求，然而这些需求并没有得到有效的处理。

其他人认为BA的职责是在那些早期的会议中, 在一个新的应用软件中帮助管理并掌握选择的范围。“高级执行官并不笨，” Kvevin Brennan解释道，他是业务分析师国际学院的副总裁，blue sands项目业务分析师，同时还在多伦多一家咨询公司工作，“告诉他们，对于新软件，他们能做什么，同时告诉他们为什么他们应该小心。”

业务问题有时候可以通过非技术方案进行解决。当出现这种情况的时候，有经验的BA就能马上意识到。

“如果有IT背景的话，你思考任何事情都会倾向于软件，” Barbara Carkenord说，他曾经是General Motors 的一位程序员，“但是一些困境可能是程序上的；其它一些可能是组织上的。”

Stamford和Conn的Gartner Group的副总裁和研究主管Michael Blechar说，BA在组织中的位置——他们最终所处的位置——能影响开发项目的成败。

“通常从IT方面来看它的职责是引导分析师收集需求，”Blechar说，“但是由于业务流程方面管理和已经在商业领域出现的主动改善，这个角色已经从IT方面转移到了商业领域。”Blechar主张，那是因为三分之二的业务流程“本质上是人对人的。它们不涉及到计算机系统。”