有效的需求分析员

在繁忙的工作之余回想一下，你是如何从一个普通的开发人员变成一个需求分析员的？也许只是突然有一天，你的上司拍着你的肩膀，微笑着的对你说：“这个项目的需求就由你来做吧！”。欣喜之后，心里不禁有些发虚，“我能够成为一个有效的需求分析员吗？”。

    有效的需求分析员为什么难以产生

    不容置疑，需求分析的正确、完整直接影响着项目的成败，而需求分析员是需求分析正确与否的直接责任人。可是我们所受的教育 ，所处的工作环境制约了我们，让我们很难成为一个有效的需求分析员。

    大学里，老师们讲课完毕后，就会留给学生几道习题，而这些习题几乎是不用经过思考就可以知道它的要求是什么，根本谈不上需求分析，更加不需要考虑如何去进 行有效的需求分析。然而，同样是这些学生，毕业后却要面对错综复杂、频繁变化的需求，需要像专家一样发现需求、挖掘需求，但是这些没有经过良好训练的“士 兵”仅仅靠天赋和勤奋就能打赢这场艰苦卓绝的“战役”吗？

    大多数的需求分析人员都是从开发人员成长起来的。工作中，我们长时间一言不发，面对着冰冷的显示器，手指在键盘上翻飞，嘴角带着神秘的微笑，用一种奇怪的 符号在写着什么。我们生活在一个数字的世界中，我们当中可能很多人从来没有和任何一个客户接触过。可是突然有一天，我们发现自己不得不面对一大群用户，更 加糟糕的是这些人竟然不懂什么是C++ ，也没有听说过互联网 。“天啦，我能和他们说什么啊？”

    现在存在着这样一种谬论，认为优秀的程序员 也 会是有效的需求分析员，但是我们所接受的教育，我们的工作并不能教会我们如何成为一个有效的需求分析员。就像编码，测试，项目管理一样，需求分析也存在着 大量的技巧。很难想象不经过艰苦的训练就能够很好的掌握一种编程语言，需求分析也是一样。但是现实中，很多的程序员没有经过任何的训练就变成了一个需求分 析员，变成了一个缺乏足够技巧的需求分析员。

    什么是有效的需求分析员？一个有效的需求分析员需要在需求分析过程中在工作中和用户建立真正的伙伴关系，能够在错综复杂的现象中发现问题背后的问题 （the problem behind the problem），在陌生的领域内能学得更快，而且还要用共同的语言和用户进行交流在工作中和用户建立真正的伙伴关系。

    和用户建立真正的伙伴关系

    我们知道用户的业务目标是什么吗？我们知道用户三年甚至更久的发展方针是什么吗？我们知道我们的软件能够给用户带来哪些利益吗？用户把我们当作朋友吗？

    和用户建立伙伴关系往往是写在纸上，而不是放在心里，更难落实在实际行动中。和用户建立伙伴关系不是空泛的口号，而是要为用户的经营结果负责。它不是隔靴 搔痒式的善愿，而是要求苦乐与共的团结、有用信息的交流和协力谋求成果。我们作为一个需求分析员，扪心自问，在需求分析中真的把用户的商业目标放在第一位 了吗？真的把用户看成我们伙伴了吗？不了解用户的目标，不尊重用户的利益，我们能够分析出让用户惊喜的需求吗？能够开发出为用户创造大量价值的软件吗？

    怎么才能和用户建立真正的伙伴关系呢？首先，要转变我们的态度。很多IT人都是自诩为“社会精英”、“高科技人才”，在和用户，尤其是传统行业的用户交流 的过程中，几乎是习惯性的傲慢。如果需求分析员带着这样的态度去工作，用户会是什么感受？是我们给用户服务，还是来教训用户？带着居高临下的态度，我们又 怎么能够做到“像用户一样思考”？所以，我们必须要改变自己的态度，真心实意的把用户当作上帝看待。要明白，是用户的钱养活了我们。第二，培养人际关系。 需求分析不是做交易，不是把收了钱就可以置诸脑后的一锤子买卖。我们要真诚的面对客户，用真心换取真心，尽力和用户成为朋友。第三，我们要展开我们的商业 想象力。大胆寻求满足用户需求的更佳途径。象用户一样看待事物远远不够，我们要争取看得更清晰，也就是常说的“超越用户”。 发现问题背后的问题

    当一个软件项目开始后，用户的要求往往是开发完成某个功能（如人事管理，财务等）的软件，用来解决目前存在的问题。但是软件真正能够给用户创造的价值是什么，这是每一个需求分析员必需思考的问题。

    需求分析应该是一种系统思考，是一种需要“见树又见林”工作。有效的需求分析员要把企业看成一个系统，并且把它融入大社会这个大系统中，全面的观察用户的 工作，而不是片段的、一幕一幕的个别事件。比如用户需要开发一个人事管理软件，表面上的需求可能是更方便的对员工进行管理，但是实质上的需求可能是通过人 事管理软件来解决工作纪律松散、考勤不严格、人员流动随意等问题。同样的，用户需要开发一个财务软件，除了更好的管理资金，其真正的目的可能是为了解决内 部财务制度混乱的问题。如果需求分析只是停留在表面的问题，而不能够发现用户真正关心的问题，很难相信开发出来的软件能够让用户发自内心的满意。

    如果发现问题背后的问题呢？在大多数公司，除了存在一些正式的组织之外，还存在着各种非正式的组织，这就需要需求分析员在需求分析的过程中，除了要利用正式的渠道（会议 、访谈等）外，还要善于利用非正式的渠道（午餐中的交谈、私人会谈等）来了解用户的需求。我们会发现非正式的渠道往往是发现问题背后的问题的关键。

另外，我们还需要掌握一种有效的分析方法——“深耕法”。下面是一个深耕法的例子：

    问题--原因

    今天早晨发生一起机床停工事故 　
　      因为机床的密封圈漏油了
    密封圈为什么会漏油？ 　
　      因为采购回来的密封圈质量不合格
    为什么要采购质量不好的密封圈？ 　
　      因为价格低10％
    为什么这么小的差价还要采用质量不好的密封圈？ 　
　      因为采购人员的绩效是按照采购成本来评定的。
    所以，问题的根本是要改变采购人员的绩效评估标准 ！ 　

    通过一系列的“为什么？”，我们能够很有效的发现问题的背后的问题到底是什么。

    “用户真正需要的是什么？”，每一个需求分析员在进行需求分析的过程中都应该不断的问自己，要记住一个事实，“事情往往比它看起来复杂”。只有真正的融入到用户当中，成为用户团体中的一员，才能发现问题背后的问题，才能做出真正让用户满意的产品来。

    学得更快

    不正确需求已经成为了导致软件开发失败的最大罪魁祸首，尤其是运用于非计算机行业的软件。需求分析员往往不是行业专家，在十天半个月的需求分析中，我们很 难完全理解一个拥有十几年经验的行业专家。这是一个很残酷的现实，也是一个我们必须面对的事实。正是因为理解上的片面和偏差导致了很多软件项目以悲惨的结 局收场。

    一个有效的需求分析员应该是一个善于学习的人。只有学得更快才能让一个需求分析员能够在短暂的需求分析阶段成为一个“行家里手”，能够像一个行业专家那样 思考、行动。但是学习能力也不是一朝一夕就能提高的，需求分析员要在日常的工作学习中不断的加强，尽可能的用更快的速度来学习。只要坚持不懈，一定会大有 收获。

    一个有效的需求分析员也应该乐于学习的人。当他面对一个全新行业的时候，他能够用超乎想象的热情和速度去学习，去理解，去融入，而不是排斥、厌恶，甚至诅 咒。很多IT人都有一种不好的想法，就是对传统行业有一种近乎“天然”的排斥感，这种排斥感往往会导致需求分析员与用户之间的隔阂和矛盾，其结果可想而 知。

    用共同的语言进行交流

    当IBM AS400发布的时候，IBM专门在众多的专家中找出一位既精通技术，又能够把晦涩难懂的技术术语“翻译”成易懂的口头语言的专家，结果这位专家在发布会上用平实的语言说出了AS400的所有优点，在场的所有记者都能够轻松的理解，从而使得发布会获得了前所未有的成功。

    作为一个需求分析员，对技术应该是有相当的了解的，但是我们不能奢望我们的用户也能和我们一样对IT技术有同样精深的了解。用户可能不知道什么是“组件 ”，什么是“面向对象”，甚至搞不清楚“10M带宽网络和100M带宽网络有什么区别”。对于用户而言，他们更加熟悉的是他们所在行业的术语和标准。于是 奇怪的现象出现了，用户和需求分析员用着互相不能理解的语言在交流，就好像是一个中国人和一个法国人各自用着自己的母语在交流，也许更多的是混乱，而不是 共识。在这样的情况下面，我们能够奢望取得准确，全面的用户需求吗？

    一个有效的需求分析员应该怎么解决这个问题呢？首先，应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户。这就需要我们大量 的阅读用户所在行业的资料、文章，尽量多选取一些整体性介绍的文章，这样可以在短时间内能够对该行业有一个全面的认识，这样我们就能够较好的和用户进行交 流了。第二，应该尽量不使用IT行业的术语，而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语，以便用户能够很好的理解。我们可以向用户这样解释 10M带宽网络和100M带宽网络有什么区别：“10M带宽的网络就像是双车道的柏油路，容易堵车，而100M带宽的网络却是二十车道的高速公路，堵车的 可能性非常小”。这样的解释用户就能够很好的理解了。但是，用平实的语言解释IT行业的术语并不是一件容易的事情。一方面它要求对该术语有透彻的理解，另 一方面需要很好的表达能力。在平时的工作中，我们不妨试着把一些难懂的术语用平实的语言表达出来，甚至可以向一些不了解IT技术的人解释一些艰深的概念。 只要能够坚持做下去，一定会有让我们惊喜的进步。

    需求之所以难以捕获，是因为它们存在与用户的头脑中。有效的需求分析员必须用自己智慧、行动和真诚去发现需求、挖掘需求。好的方法和习惯能够让我们的需求分析更加有效，也会让我们成为一个有效的需求分析员！

 

转自：http://pm.csai.cn/requirement/200706261207351141.htm