[转]主题：咱们应当怎样作需求分析

又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太多往事的回忆。过去的10年，毫无疑问是中国软件业发展最快的10年。当咱们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而如今却几乎看不到它们的踪迹，换来的是诸如J2EE和.NET这样的大型web应用。而这期间，RUP、XP、敏捷开发、持续集成••••••一个接一个的新概念层出不穷，使人眼花缭乱。如今想来，恍如隔世。 但更令我印象深入而难以忘怀的，是我亲自经历的、亲眼目击的、道听途说的一个又一个的软件项目，它们有的得到了成功，但更多的是使人沮丧的失败。套用一下大文豪托尔斯泰体：幸福的家庭都是同样的，不幸的家庭却各有各的不幸；幸福的软件项目都是同样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是同样的，失败的项目却各有各的问题。我经常在想，咱们的项目开发到底怎么了，进而把它们一个一个的剥开来深刻分析，居然触目惊心。它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的仍是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是咱们在需求分析过程存在的巨大隐患，最终致使了那么多项目的失败。也许你认为我在危言耸听，好吧，我来举几个典型事例分析分析吧。 个人第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，据说这个项目以前是东软作的。当时东软在作这个项目的时候，整个过程经历了10屡次结构性的大变动，局部性的调整更是不可胜数。听说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。以后客户对修改的内容仍是不满意，又不得不将几百处修改从新改回来。最后这个项目致使的结果是，整个这个项目组的全部成员都离开了东软，并彷佛今后不肯涉足软件开发领域。多么惨痛的教训啊！我经常听到网友抱怨客户老是对需求改来改去，但客户对需求改来改去的真正缘由是什么呢？当咱们对客户的需求没有真正理解清楚时，咱们作出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，因而就在一点儿一点儿试，因而这种反复变动就这样发生了。若是咱们明白了这一点，深刻地去理解客户的业务，进而想到客户的心坎儿上去，最后作出来的东西必然是客户满意的。记住，当客户提出业务变动的时候，咱们必定不能被客户牵着走，客户说啥就是啥。咱们要从业务角度深刻的去分析，他为何提出变动，提得合不合理，我有没有更合理的方案知足这个需求。当咱们提出更加合理的方案时，客户是乐于接受的，变动也变得可控了。 第二个故事来自我本身的项目，一个早期的项目。在这个项目中，客户扔给了咱们不少他们目前正在使用的统计报表，要咱们按照报表的格式作出来。这些报表都是手工报表，许多格式既不规范，又很难于被计算机实现。这些报表令我耗费了很多脑细胞，直到最终项目失败都无法完成。这件事留给个人深入教训是，不能客户怎么说软件就怎么作。客户提出的原始需求每每是不考虑技术实现，基于非计算机管理的操做模式提出来的。他们提出的不少需求经常比较理想而不切实际，毕竟人家是非技术的。但咱们做为技术人员，需求分析必须实事求是的、基于技术能够实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。因此咱们必需要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。若是咱们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优点从何而来呢？所以，咱们作需求就应当首先理解现有的管理模式，而后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操做与管理。 2007年，我参与了一个集团信息化建设的项目。这个项目中的客户是一个庞大的群体，他们分别扮演着各类角色。从机构层次划分，有集团领导、二级机构人员、三级机构人员；从职能角色划分，有高层领导、财务人员、生产管理员、采购人员、销售人员，等等。在这样一个复杂场景中，不一样人员对这个项目的需求是各自不一样的。很是遗憾的是，咱们在进行需求分析的时候没有认真分析清楚全部类型人员的需求。在进行需求调研的时候，老是集团领导带领咱们到基层单位，而后基层单位将各方面的人员叫来开大会。这样的大会，各种型的人员七嘴八舌各说各自的需求，还有不少基层人员在大会上由于羞涩根本就没有提出本身的需求。这样通过数次开会，需求调研就草草收场。咱们拿着一个不充分的需求分析结果就开始项目开发，最终的结果可想而知。直到项目上线之后，咱们才发现许多更加细节的业务需求都没能分析到，系统根本无法运行，不得不宣告失败。一个软件项目的需求调研首先必需要进行角色分析，而后对不一样的角色分别进行调研。需求调研的最初须要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，而且不少问题都不是能一蹴而就完成的，咱们必须与专家创建联系，反复沟通后完成。需求分析必须听从的是必定的科学方法，而不是盲目的大上快上。 个人最后一个故事可能典型到几乎每一个人都曾经遇到过。咱们的项目从需求分析到设计、开发、测试都十分顺利。但到了项目进行的后期，快到达最后期限时，咱们将咱们的开发成果提交给客户看，客户却对开发成果不满意，提出了一大堆修改，并且这些修改工做量还不小。怎么办呢？加班、赶工，测试时间被最大限度压缩。最后项目却是如期上线了，但你们疲惫不堪，而且上线之后才发现许多的BUG。需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。以上这个事例，若是咱们提前将开发成果给客户看，提前解决问题，后面的状况就将再也不发生。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决全部的需求问题，所以在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时得到反馈。只有这样才能及时纠正需求理解的误差，保证项目的成功。 以上的故事各有各自的不幸，各自都在不一样的开发环节出现了问题。但通过深刻的分析，各自的问题最终都归结为需求分析出现了问题。为了使咱们从此的软件项目不会重蹈覆辙，彷佛真的有必要讨论一下咱们应该怎样作需求分析。