一提跟业务人员做“需求分析”，许多IT人员立刻就头大了，要么不在同一个“频道”讲话，要么“变来变去，定不下来”。如何跟业务部门谈需求分析呢，我们带着这个问题，与聚冠因尚的咨询顾问杨春波展开了讨论。
1、 有的IT主管抱怨业务部门提出的需求，IT人员看不懂甚至根本不能称之为需求，您觉得为什么会出现这种情况？
聚冠因尚杨春波：
这是比较常见的现象，“语言不通”是造成这种情况的主要原因之一。在企业信息化程度不高的情况下，业务人员的系统使用经验较少，他们提出的需求往往用的是“业务语言”，比如说，“我需要在录入这两项数据之后，分摊成本能在这个窗口直接蹦出来……”。而我们IT人员熟悉的是“系统语言”，比如“能以这个字段为关键字，按照结算时间顺序排列，出个报表”。
从“业务语言”到“系统语言”，需要一个“翻译”的过程。如果IT人员在公司时间不长、或者是对业务不熟的话，难度确实是不小的。我们的IT主管们也别上火、少抱怨，应该注意培养IT人员的业务知识、鼓励IT人员经常与业务部门多交流。早就听说财务人员要“走出账房”了，我们的IT人员也应该不时地“远离电脑”。
2、 业务人员与IT人员在需求分析阶段的分工是什么样的？
聚冠因尚杨春波：
在需求分析阶段，IT人员切忌只做“聆听者”，还要兼做“翻译师”和“培训师”。
“聆听”业务人员的需求是第一步，但IT人员要尽量避免“你只管说，我只管做”的局面。“系统反正是按业务部门提得需求做出来的，好不好用别怪我” ，这种想法看似很安全，其实是找麻烦，等到系统被改来改去的时候，才发现双方都浪费了时间。
IT人员还应做好“翻译师”。将业务需求整理并转化为“业务需求说明书”，并将整理好的文件与业务部门进行充分的沟通，来确认是否准确、完整地表述出业务部门的需求。
IT人员还应做好“培训师”。在企业信息化程度不高的情况下，培训工作尤为重要。IT人员应建议业务骨干参加有关信息化内训或外训课程，让他们多听“IT理念”、多了解“信息化案例”，促使双方有更多的“共同语言”。
3、 您觉得该怎么确保需求分析阶段得出的项目需求，能充分反映业务部门的需求？
聚冠因尚杨春波：
我们发现，业务人员在提需求的时候，经常是从个人的实际业务需要出发，非常关注与自己日常工作相关的内容。如果需求调研过程只找个别业务人员来问问，必然会出现需求不完整的情况。
在需求分析阶段，应该“多方位”、“多层次”地选择需求调研对象，不仅要找不同的业务管理人员了解业务管理需求，也要找多个业务执行人员了解操作需求。这样的需求调研方式，才有可能得到一个相对完整的业务需求。
4、 在需求分析阶段IT部门与业务部门的沟通上，您有哪些经验？
聚冠因尚杨春波：
我对IT人员与业务部门的沟通方面的建议是，“以诚待人、学会倾听、活泼一点”。
“以诚待人”是良好沟通的基础。不管业务人员的职位高还是低、对信息化懂还是不懂，我们都要真诚、虚心地进行沟通。
“学会倾听”不是说让我们摆出一幅“专心听讲、认真记笔记”的姿态，更重要的是要“会听”，要明白业务人员某句话背后实际是想说什么想要什么，这要求IT人员具备一定的业务经验和领悟能力。
“活泼一点”是对那些平常较为严肃的IT人员的建议。与业务人员特别是营销人员交流时，沟通方式不妨活泼一点，更能拉近彼此距离、更能碰撞出火花。
在上一节中，我们就需求分析过程中IT部门与业务部门的分工、沟通等方面，与聚冠因尚的咨询顾问杨春波进行了交流。接下来我们继续就以下三个问题，与专家探讨“如何跟业务部门谈需求”。
1、在需求分析阶段，您觉得获取IT“需求”的途径有哪些？
聚冠因尚杨春波：
至少有三个途径。一个是“拿来主义”，一个是“直接调研”，一个是“混合式”。
首先说“拿来主义”。现在是“知识爆炸”的时代，在互联网上很容易找到可供参考的需求文件。即使没有同行业的资料，找到同业务领域的应该说不难。比如要找“重型卡车预算报价系统需求”，虽然找“汽车行业”的需求文件有点困难，但在网上找到“预算报价系统需求”还是比较轻松的。IT人员通过阅读和理解“拿来主义”的文件，找到功能需求的相似之处，会帮助我们更好地获取实际业务的IT需求。
再说“直接调研”。直接找到业务部门人员进行需求调研，这也是最常用的一种方式。
比较有意思的是“混合式”，也就是将“拿来主义”和“直接调研”结合起来的一种方式，首先让业务部门直接提需求，再提供“拿来”的需求文档给他们做参考，来达到进一步启发需求的目的。
有些IT人员会说，没必要搞这么复杂吧。说这话的人一般都喜欢“直接调研式”，反正按照业务部门要求的做就是了，他要吃烧饼咱就烙烧饼，没必要推荐什么“披萨”。完全按照业务部门定制需求的方式造成的直接后果是，IT人员辛辛苦苦做出的系统被要求无休止的改来改去。
2、有时候业务部门往往会提出一些无法满足的“过分”的需求，您觉得IT主管该怎么对这些需求进行取舍？
聚冠因尚杨春波：
业务部门可能会提出一些“过分”的需求，如果系统恰好是IT部门主导开发的，这种情况就更常见了。
“过分”这肯定是对于IT部门来说的，从业务角度，任何“过分”的需求肯定有合理的地方。对IT部门而言，“过分”的需求要么是系统实现的难度很大，要么是对设备的性能要求较高。
IT主管应对“过分”的需求进行评估，可以从四个方面考虑：
首先是需求的重要性，结合实际业务，判断该需求是否为核心需求；其次是需求的难度，从整体实现难度上进行等级划分；第三是实现需求的成本，比如说需要多少个开发人月和测试人月、需要多少经费来提高设备性能；最后是有无替代的解决方案，比如说业务部门要求业务系统中的人员信息要与HR系统里的人员信息实时同步，要实时难度很大，是否可以考虑三天同步一次、或者一天同步一次。
IT主管要将评估结果与业务部门进行沟通，甚至可以和业务部门负责人一起探讨从高层获取资源的可能性。这样，IT部门就是和业务部门一道来解决问题，而不会因为直接对业务部门说“不”，产生一些节外生枝的结果。
3、在需求分析阶段结束之后，甚至项目进行过程中，业务部门往往还会增加新的需求，这无疑会打乱原有的项目部署，您遇到过这种情况吗？该如何处理？如何避免这种情况的出现？
聚冠因尚杨春波：
曾经遇到过。如果是核心需求，那就考虑立即调整计划，将其增加进来。如果是非核心需求，可以考虑说服业务部门放在下一阶段实现。
出现这种情况，我认为有两种原因，首先是需求分析工作不充分，其次是缺乏对需求的分类分级。
需求工作不充分体现在两点，一个是有明显遗漏、一个是缺乏预判。解决需求遗漏问题，只能靠多层次多方面的调研访谈、资料搜集、沟通交流来完成。解决需求预判是对IT人员的需求分析能力提出的更高要求。在需求分析的过程中，不但要面向现有业务流程，还要对一定阶段内可能的业务变化做充分的预判和探讨。举例来说，IT主管要跟高层和业务部门讨论一下短期内是否有组织架构方面的变动、业务模式或业务流程是否会发生变化等等。
需求的分类分级是需求分析工作中很重要的环节，要把所有需求在一期项目中完成是不现实的。我们对需求按业务领域进行了分类，从重要性及实施难度上进行了分级，经与业务部门的讨论，对实施过程的阶段进行明确，第一阶段实现哪些需求、第二阶段实现哪些需求，这样整个项目才能达到“明确规划、逐步推进，快速见效”，才能让业务部门满意、让IT部门轻松。
