错误的需求分析对任何CIO来讲都是一场噩梦。在需求分析阶段看似微不足道的疏忽，都有可能成为项目失败的罪魁祸首。无论CIO的项目管理经验多么丰富，基于错误需求分析的IT项目，其结果只能以失败而告终。但是，即便如此，IT项目前期的需求分析仍然没有引起CIO们的普遍重视。他们往往更多地关注项目的时间、成本、质量、组织、范围和客户满意度，却没有意识到，需求分析是所有项目成功要素发挥作用的前提，如果需求分析有误或者不到位，任何IT项目管理技巧和对IT项目的任何控制，都是没有价值的。
与此同时，对于缺乏经验的CIO来讲，需求分析恰恰又是整个项目中最容易让人焦头烂额的阶段——业务部门提出的需求往往文不对题并且不断变化，甚至在项目接近尾声的时候，业务部门仍然在不断地提出新需求。挖掘业务部门的项目需求时，CIO往往感觉力不从心，业务部门对项目需求的反复无常，又让CIO措手不及。那么CIO该如何确保项目需求分析的正确与充分，面对业务部门反复无常的项目需求又该如何应对呢?为此，记者NSIGHT近日请到了武汉健民集团信息中心主任柳骏、浙江吉利控股集团信息系统部副经理章正柱、AMT咨询深圳公司总经理杨春波，围绕“需求分析”相关话题展开了讨论。
记者：我们经常会听到一些CIO抱怨说，对业务部门提出的需求IT人员看不懂，甚至根本不能称之为“需求”，为什么会出现这种情况?
章正柱：我就遇到过这种情况。业务部门对IT不太了解，他们有时候会把IT想象得过于神化，觉得系统上了之后就会无所不能，往往提出一些脱离实际的需求。
我印象比较深的是我们集团的“一车一档”系统，这是做ERP的时候业务部门提出的需求，他们希望在ERP中实现这样的功能。一车一档系统管理的内容比较多，从汽车生产的订单接收，到生产的组织，再到最后的销售结果反馈等环节都有涉及。对于业务部门提出的这个需求本身，我觉得是合理的，但是如果要做“一车一档”系统，必须要有采购系统、生产系统、物流系统和销售系统做支撑，在没有销售系统的情况下，单纯依靠ERP去实现“一车一档”系统就显得不切实际了。
柳骏：对于任何IT项目的需求分析，如果主要依靠业务部门去提是绝对不行的，因为他们对系统功能的认知非常有限，很难在项目前期提出有效的需求。实际上，很多项目在需求分析阶段，业务部门压根就提不出什么具体的需求，倒是在系统上线之后，他们的需求才能慢慢地涌现，最后甚至铺天盖地地呈现。我在很早以前就遇到过这种情况，前期做需求分析的时候，业务部门会说：“我们没什么需求，你们IT部门根据自己的想法去做，做出来我们能用就行了。”结果系统做出来了以后，业务部门的需求才真正爆发出来，搞得项目组焦头烂额。杨春波：前面两位IT主管都提到了业务人员对IT的不了解，我觉得还有一个很重要的原因，就是“语言不通”。在企业信息化程度不高的情况下，业务人员的系统使用经验较少，他们提出的需求往往用的是业务语言，比如说：“我需要的是在录入这两项数据之后，分摊成本能在这个窗口直接蹦出来??”而我们IT人员熟悉的是系统语言，比如：“能以这个字段为关键字，按照结算时间顺序排列，显示出一个报表。”
从业务语言到系统语言需要一个翻译的过程。如果IT人员到公司时间不长或者是对业务不熟的话，难度确实是不小。不过CIO们别上火、别抱怨，他们应该注意多培养IT人员的业务知识，鼓励IT人员经常与业务部门多交流。很早就有人提出，财务人员要“走出账房”，我觉得IT人员也应该时不常地“远离电脑”。
记者:柳骏刚刚提到了在需求分析阶段仅仅依靠业务部门提需求是不够的，那么你们认为获取IT需求的途径应该有哪些?
柳骏：需求分析不能完全依赖业务部门，在这个阶段，IT人员不仅要充分介入进去，还要钻到业务中，与业务部门绑在一起，和业务人员成为朋友，尽量成为业务方面的专家。
具体来讲，IT人员可以先通过访谈的方式，了解业务流程的大概状况，然后再深入到业务部门，跟着业务人员，把业务流程整个走一遍，以充分熟悉业务流程的每一个环节。我觉得需求分析有点类似于机械行业的工艺卡片，工艺卡片是以工序为单位，详细地说明整个工艺过程的一种工艺文件，用来指导工人生产，帮助车间管理人员和技术人员掌握整个零件加工的过程。做需求分析也要像编制工艺卡片一样，细化到业务流程中的每一个动作，这是非常有必要的。因为只有对业务流程的每一个细节都足够了解了，才有可能在此基础上进行流程优化、重组，尽可能多地挖掘出业务部门对系统的潜在需求，进而形成项目需求分析报告。
除了分析业务部门的工作流之外，还要收集他们日常工作中用到的各种单据、报表和表单等，也就是通常所说的票据流。实际上，票据流是业务部门工作流的载体，通过这些载体，不仅可以对工作流有更加深入的理解，还可以分析出业务部门对信息的需求是什么。
杨春波：我觉得至少有三个途径，一个是拿来主义，一个是直接调研，再一个是混合式。
首先说拿来主义。现在是“知识爆炸”的时代，在互联网上很容易找到可供参考的需求文件。即使没有同行业的资料，找到同业务领域的应该说也不难。比如要找“重型卡车预算报价系统需求”，虽然找“汽车行业”的需求文件有点困难，但在网上找到“预算报价系统需求”还是比较容易的。IT人员通过阅读和理解“拿来主义”的文件，找到功能需求的相似之处，会帮助他们更好地获取实际业务的IT需求。
再说直接调研，就是直接找到业务部门人员进行需求调研，这也是最常用的一种方式。比较有意思的是混合式，也就是将拿来主义和直接调研结合起来的一种方式。首先让业务门直接提需求，再提供“拿来”的需求文档给他们做参考，来达到进一步启发需求的目的。有些IT人员可能会说：“没必要搞这么复杂吧。”说这话的人一般都喜欢直接调研式，反正按照业务部门要求的做就是了，他要“吃烧饼”咱就“烙烧饼”，没必要推荐什么“比萨”。完全按照业务部门定制需求的方式容易造成的直接结果是，IT人员辛辛苦苦做出的系统无休止地被要求改来改去。
章正柱：我们的做法主要是通过培训，这是获得需求的一种很好的途径。比如上CRM项目之前我们会先对相关业务部门做培训，通过项目概念的导入，业务部门就清楚CRM到底是做什么，这样他们才能够把真正的需求提出来。否则，如果连这个系统是做什么的都不知道，让他们提需求最多也只能泛泛而谈。与此同时，我们还会进行一些访谈，与业务部门，特别是和领导面谈，询问他们对项目相关领域的需求和想法。
目前我们主要是通过培训和访谈这两种方法，实际结果显示也是比较有效的。当然，还有其他一些手段，比如问卷调查，但是效果要差很多。
记者:看来获得需求的途径并不是惟一的。业务人员与IT人员在需求分析阶段的分工是什么样的呢?
杨春波：我认为，在需求分析阶段，IT人员切忌只做聆听者，还要兼做翻译师和培训师。聆听业务人员的需求是第一步，但IT人员要尽量避免“你只管说，我只管做”的局面。“系统反正是按业各部门提得需求做出来的，好不好用别怪我。”这种想法看似很安全，其实是在给自己找麻烦，等到系统被改来改去的时候，才发现双方都浪费了时间。IT人员还应做好翻译师。将业务需求整理并转化为业务需求说明书，并将整理好的文件与业务部门进行充分地沟通，来确认是否准确、完整地表述出了业务部门的需求。
此外，IT人员还应做好培训师。在企业信息化程度不高的情况下，培训工作尤为重要。IT人员应建议业务骨干参加有关信息化内训或外训课程，让他们多听IT理念，多了解信息化案例，促使双方有更多的共同语言。章正柱：IT人员的主要工作是概念的导入和系统功能的介绍。要让业务人员明白，我们要做什么样的系统，能解决什么样的问题，这个系统有哪些具体的功能。业务部门的职责主要是对现有业务现状的描述，他们要告诉IT人员现在是怎么管理的，未来希望怎么管理。
柳骏：目前来看，我们需求分析阶段的工作大部分都是IT人员完成的，因为业务人员对IT需求不是很明白，在项目的需求分析阶段，业务部门很难提出具体量化的、可以直接被IT人员提取的需求。他们提出的需求往往需要IT人员进行编译或者翻译，把他们的业务语言转化成IT语言。因此在这个过程中，业务人员承担的工作很少。
记者:你们觉得该怎么确保需求分析阶段得出的项目需求，能充分反映业务部门的实际需求?
杨春波：我发现业务人员在提需求的时候经常是从个人的实际业务需要出发的，非常关注与自己日常工作相关的内容。如果需求调研过程只找个别业务人员来问，必然会出现需求不完整的问题。
在需求分析阶段，应该多方位、多层次地选择需求调研对象，不仅要找不同的业务管理人员了解业务管理需求，也要找多个业务执行人员了解操作需求。这样的需求调研方式才有可能得到一个相对完整的业务需求。
柳骏：我刚刚谈到的获取需求的方法有三步，第一步是访谈，第二步是IT人员跟着业务人员走流程，第三步是搜集业务人员工作中的票据流。但是，这三步之后拿出来的只是一些需求的简单罗列，还不能称之为真正意义上的需求。还有一个环节，就是对罗列的这些离散的信息和数据加以提炼，整理出系统的、规范性的需求。
记者:柳骏提到“要对离散的信息和数据加以提炼”，提炼的过程也就是对需求进行取舍的过程，各位对取舍的标准有哪些建议?
柳骏：这主要看系统设计过程中关注的点在哪儿。一般来讲，我们关注的点主要是业务控制和管理控制的节点，同时也应该是系统的控制节点，所以重点应该满足这些控制节点。同时在取舍过程中，要尽可能地征求业务部门的意见。虽然业务部门在需求提出阶段，很难提出像样的需求，但是在这些需求的取舍上，业务部门很有发言权，他们也可以提供很多有价值的意见。刚刚谈到的需求分析阶段，这个环节是业务部门参与最多的地方，即关键控制节点和管理节点的确认，以及离散需求的取舍。
章正柱：以我的经验，首先是看项目的范围，不能把所有的需求都“朝一棵树上靠”，如果是项目范围之外的需求，我们肯定会舍弃。项目范围之内的，我们会从业务部门的需求紧迫程度、实现难度以及IT基础设施和资源等各方面综合考虑，在与业务部门充分沟通之后，去掉一些边缘性的、非核心的需求。
杨春波：需求的取舍，在大部分情况下更多是针对业务部门提出的。因为业务部门可能会提出一些“过分”的需求，如果系统恰好是IT部门主导开发的，这种情况就更常见了。
“过分”肯定是对于IT部门来说的，从业务角度看，任何过分的需求肯定有合理的地方。对IT部门而言，这种“过分”的需求要么是系统实现的难度很大，要么是对设备的性能要求过高。
CIO应对“过分”的需求进行评估，可以从四个方面进行考虑：首先是需求的重要性，结合实际业务，判断该需求是否为核心需求;其次是需求的难度，从整体实现难度上进行等级划分;第三是实现需求的成本，比如说需要多少个开发人月和测试人月，需要多少经费来提高设备性能;最后是有无替代的解决方案，比如说业务部门要求业务系统中的人员信息要与HR系统里的人员信息实时同步，但是如果实现难度很大，是否可以考虑3天同步一次或者一天同步一次。
此外，CIO还要将评估结果与业务部门进行沟通，甚至可以和业务部门负责人一起探讨从高层获取资源的可能性。这样IT部门和业务部门一道来解决问题，就不会因为直接对业务部门说“不”而产生一些节外生枝的结果。
记者:需求分析阶段结束之后，甚至项目进行过程中，业务部门往往还会增加新的需求，这无疑会打乱原有的项目部署，这时候该怎样处理?
杨春波：出现这种情况，我认为有两种原因，首先是需求分析工作不充分，其次是缺乏对需求的分类、分级。需求工作不充分主要体现在两点：一个是有明显的遗漏，一个是缺乏预判。解决需求的遗漏问题，只能靠多层次、多方面的调研访谈，资料搜集以及沟通交流来完成。解决需求预判是对IT人员的需求分析能力提出的更高要求。在需求分析的过程中，不但要面向现有业务流程，还要对一定阶段内可能的业务变化做充分地预判和探讨。例如，CIO要跟高层和业务部门讨论一下短期内是否有组织架构方面的变动，业务模式或业务流程是否会发生变化等等。
需求的分类、分级是需求分析工作中很重要的环节，要把所有需求在一期项目中完成是不现实的。所以我们要对需求按业务领域进行分类，从重要性及实施难度上进行分级，经过与业务部门的讨论，对实施过程的阶段进行明确，第一阶段可以实现哪些需求，第二阶段可以实现哪些需求，这样整个项目才能达到“明确规划、逐步推进、快速见效”，才能让业务部门满意，让IT部门轻松。
在项目进行过程中，由于业务部门提出的新需求而打乱原有项目的部署，这种情况在做IT项目时是很普遍的。如果是核心需求，IT部门就应该考虑立即调整计划，将其增加进来;如果是非核心需求，就可以考虑说服业务部门，把这个新需求放在下一阶段实现。
章正柱：需要明确的是，这种情况是不可避免的，几乎每一个IT项目主管都有可能碰到。因为随着业务部门参与项目的不断深入，他们对系统的理解也会有一个逐步提升的过程，可能刚开始提出一个过高的、理想化的需求，或者提出了一个过低的需求，随着对项目理解的不断加深，可能会对需求不断进行调整。
通常我们把项目实施分为项目准备、业务蓝图设计、系统实现、上线准备、运行支持这么几个阶段。其中业务蓝图设计就是需求分析和设计阶段，在这个阶段，要把对项目的最终需求以流程图的形式绘制出来，让相关业务部门负责人签字确认。
这个阶段结束之后，如果业务部门再提出新需求，需要走项目变更流程。通过变更流程，对新需求进行分析，这时候取舍的标准和之前有所不同，并不是业务人员提出了一个更好的需求，我们就一定会进行调整，这要看实现成本。如果实现成本比较大，涉及到原有工作调整比较多，就会按照原定流程进行。
柳骏：针对这种情况，比较有效的防范措施就是在需求分析完成之后，一定要让相关业务部门签字确认。和做项目管理一样，必须每一个步骤都要有确认的过程，每一个阶段设置对应的里程碑，防止业务部门最后盲目提出变更。因为软件架构一旦成型，往往“牵一发而动全身”，业务部门不理解，他们往往认为“就是细微的改动吗，很简单”，实际上不是这样的。针对业务部门临时提出的需求，我的处理办法是，在需求分析结束之后，即使业务部门提出新的需求，我们也不会进行任何相应的变更，而是会把这些需求记录下来，到了某一个时间点，比如半年以后，把这些需求归纳起来，对系统进行统一的升级，或者发布新版本。否则，一个项目往往涉及到多个部门的多个岗位，今天改一下，明天改一下，到最后整个项目就乱了。
需求分析阶段一定要把握住主脉，不要被业务部门牵着鼻子跑。在做IT项目的时候，既要依靠业务部门，把他们的业务需求充分展示出来;也不能被业务原有的流程束缚，不能完全在他们现有需求上进行量身定制，一定要有所提升。否则，项目将很难成功。
