错误的需求分析对任何CIO来讲都是一场噩梦。在需求分析阶段看似微不足道的疏忽，都有可能成为项目失败的罪魁祸首。无论CIO的项目管理经验多么丰富，基于错误需求分析的IT项目，其结果只能以失败而告终。但是，即便如此，IT项目前期的需求分析仍然没有引起CIO们的普遍重视。他们往往更多地关注项目的时间、成本、质量、组织、范围和客户满意度，却没有意识到，需求分析是所有项目成功要素发挥作用的前提，如果需求分析有误或者不到位，任何IT项目管理技巧和对IT项目的任何控制，都是没有价值的。
　　
　　与此同时，对于缺乏经验的CIO来讲，需求分析恰恰又是整个项目中最容易让人焦头烂额的阶段——业务部门提出的需求往往文不对题并且不断变化，甚至在项目接近尾声的时候，业务部门仍然在不断地提出新需求。挖掘业务部门的项目需求时，CIO往往感觉力不从心，业务部门对项目需求的反复无常，又让CIO措手不及。那么CIO该如何确保项目需求分析的正确与充分，面对业务部门反复无常的项目需求又该如何应对呢？为此，CIOINSIGHT近日请到了武汉健民集团信息中心主任柳骏、浙江吉利控股集团信息系统部副经理章正柱、AMT咨询深圳公司总经理杨春波，围绕“需求分析”相关话题展开了讨论。

　　CIOI：我们经常会听到一些CIO抱怨说，对业务部门提出的需求IT人员看不懂，甚至根本不能称之为“需求”，为什么会出现这种情况？
　　
　　章正柱：我就遇到过这种情况。业务部门对IT不太了解，他们有时候会把IT想象得过于神化，觉得系统上了之后就会无所不能，往往提出一些脱离实际的需求。
　　
　　我印象比较深的是我们集团的“一车一档”系统，这是做ERP的时候业务部门提出的需求，他们希望在ERP中实现这样的功能。一车一档系统管理的内容比较多，从汽车生产的订单接收，到生产的组织，再到最后的销售结果反馈等环节都有涉及。对于业务部门提出的这个需求本身，我觉得是合理的，但是如果要做“一车一档”系统，必须要有采购系统、生产系统、物流系统和销售系统做支撑，在没有销售系统的情况下，单纯依靠ERP去实现“一车一档”系统就显得不切实际了。
　　
　　柳骏：对于任何IT项目的需求分析，如果主要依靠业务部门去提是绝对不行的，因为他们对系统功能的认知非常有限，很难在项目前期提出有效的需求。实际上，很多项目在需求分析阶段，业务部门压根就提不出什么具体的需求，倒是在系统上线之后，他们的需求才能慢慢地涌现，最后甚至铺天盖地地呈现。我在很早以前就遇到过这种情况，前期做需求分析的时候，业务部门会说：“我们没什么需求，你们IT部门根据自己的想法去做，做出来我们能用就行了。”结果系统做出来了以后，业务部门的需求才真正爆发出来，搞得项目组焦头烂额。杨春波：前面两位IT主管都提到了业务人员对IT的不了解，我觉得还有一个很重要的原因，就是“语言不通”。在企业信息化程度不高的情况下，业务人员的系统使用经验较少，他们提出的需求往往用的是业务语言，比如说：“我需要的是在录入这两项数据之后，分摊成本能在这个窗口直接蹦出来??”而我们IT人员熟悉的是系统语言，比如：“能以这个字段为关键字，按照结算时间顺序排列，显示出一个报表。”
　　
　　从业务语言到系统语言需要一个翻译的过程。如果IT人员到公司时间不长或者是对业务不熟的话，难度确实是不小。不过CIO们别上火、别抱怨，他们应该注意多培养IT人员的业务知识，鼓励IT人员经常与业务部门多交流。很早就有人提出，财务人员要“走出账房”，我觉得IT人员也应该时不常地“远离电脑”。
　　
　　CIOI:柳骏刚刚提到了在需求分析阶段仅仅依靠业务部门提需求是不够的，那么你们认为获取IT需求的途径应该有哪些？
　　
　　柳骏：需求分析不能完全依赖业务部门，在这个阶段，IT人员不仅要充分介入进去，还要钻到业务中，与业务部门绑在一起，和业务人员成为朋友，尽量成为业务方面的专家。
　　
　　具体来讲，IT人员可以先通过访谈的方式，了解业务流程的大概状况，然后再深入到业务部门，跟着业务人员，把业务流程整个走一遍，以充分熟悉业务流程的每一个环节。我觉得需求分析有点类似于机械行业的工艺卡片，工艺卡片是以工序为单位，详细地说明整个工艺过程的一种工艺文件，用来指导工人生产，帮助车间管理人员和技术人员掌握整个零件加工的过程。做需求分析也要像编制工艺卡片一样，细化到业务流程中的每一个动作，这是非常有必要的。因为只有对业务流程的每一个细节都足够了解了，才有可能在此基础上进行流程优化、重组，尽可能多地挖掘出业务部门对系统的潜在需求，进而形成项目需求分析报告。
　　
　　除了分析业务部门的工作流之外，还要收集他们日常工作中用到的各种单据、报表和表单等，也就是通常所说的票据流。实际上，票据流是业务部门工作流的载体，通过这些载体，不仅可以对工作流有更加深入的理解，还可以分析出业务部门对信息的需求是什么。
　　
　　杨春波：我觉得至少有三个途径，一个是拿来主义，一个是直接调研，再一个是混合式。
　　
　　首先说拿来主义。现在是“知识爆炸”的时代，在互联网上很容易找到可供参考的需求文件。即使没有同行业的资料，找到同业务领域的应该说也不难。比如要找“重型卡车预算报价系统需求”，虽然找“汽车行业”的需求文件有点困难，但在网上找到“预算报价系统需求”还是比较容易的。IT人员通过阅读和理解“拿来主义”的文件，找到功能需求的相似之处，会帮助他们更好地获取实际业务的IT需求。
　　
　　再说直接调研，就是直接找到业务部门人员进行需求调研，这也是最常用的一种方式。比较有意思的是混合式，也就是将拿来主义和直接调研结合起来的一种方式。首先让业务门直接提需求，再提供“拿来”的需求文档给他们做参考，来达到进一步启发需求的目的。有些IT人员可能会说：“没必要搞这么复杂吧。”说这话的人一般都喜欢直接调研式，反正按照业务部门要求的做就是了，他要“吃烧饼”咱就“烙烧饼”，没必要推荐什么“比萨”。完全按照业务部门定制需求的方式容易造成的直接结果是，IT人员辛辛苦苦做出的系统无休止地被要求改来改去。
　　
　　章正柱：我们的做法主要是通过培训，这是获得需求的一种很好的途径。比如上CRM项目之前我们会先对相关业务部门做培训，通过项目概念的导入，业务部门就清楚CRM到底是做什么，这样他们才能够把真正的需求提出来。否则，如果连这个系统是做什么的都不知道，让他们提需求最多也只能泛泛而谈。与此同时，我们还会进行一些访谈，与业务部门，特别是和领导面谈，询问他们对项目相关领域的需求和想法。
　　
　　目前我们主要是通过培训和访谈这两种方法，实际结果显示也是比较有效的。当然，还有其他一些手段，比如问卷调查，但是效果要差很多。　
　

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。