需求调研之捕获

前面我们讨论了，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。但更让我感到遗憾的是，在我读过的许许多多关于需求分析的书籍中，讨论需求分析与建模的书很多，但讨论需求捕获的书籍却寥寥无几。确实，要讨论这部分内容，真的已经远远超出了软件开发这个知识领域。  那么，在软件需求捕获过程中，最根本、最容易犯错的问题是什么呢？我认为是一个态度的问题，是采用主动态度去捕获需求，还是采用被动的态度去捕获需求。如果需求分析人员总是诺诺诺，客户说什么，我们就记什么。客户处于非常强势的地位，给我们提出了非常多变态、技术难于实现的需求，而我们的需求分析人员却成为记录员，埋头记录客户说的每一句话，不加分析地就直接扔给了开发人员。这就是采用被动的态度去捕获业务需求的方式。毫无疑问，这样的需求分析必然将给项目开发的后期带来巨大的风险。  为什么会出现这样的情况呢？经过深入分析我们会发现，从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求。  什么是客户嘴中没有说出来的需求，并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。如果采用被动的方式去仅仅记录客户说出来的需求，毫无疑问会遗失这部分需求，这就是为什么直到项目后期，软件被研发出来即将交付使用，客户才提出说这不是我想要的软件，并提出大量变更需求的原因。这时，我们常常问客户，你们为什么不早说呢？而客户却十分委屈，这么简单的道理还需要我说出来吗？  举例说明吧：在我从事的税务行业中，对纳税人征收的税种包括增值税、企业所得税。增值税通常是按月征收的，而企业所得税是按季或者按年征收的。就拿增值税来说吧，税款所属期是开票日期的上个月，为什么呢？纳税人往往是在上个月产生销售收入，然后在下个月完成申报和缴纳税款。这些知识对于税务人员来说是太基本的常识了，所以在他们看来就是天经地义而不需要说出来的业务规则。但作为软件开发人员的我们却常常因为不知道而将业务弄错。  如何破解这样的问题呢？那就是要求我们在需求分析的整个过程，不断进行业务领域知识的学习。在我做需求访谈的初期，我往往不是跟客户谈需求，而是先跟客户谈业务。你们是怎样操作的？都经过些什么流程？谁来完成这些操作的？为什么这样操作？注意，在所有这些问题中，最后一个问题是最重要的。客户业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识，站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求。当一个需求分析员能达到这样的水平，客户嘴中没有说出来的需求就会被源源不断地被发掘出来，最终做出来的需求分析才是完整的、准确的。  另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问，客户压根儿没有想到的需求我们还提出来做什么？这种压根儿没有想到的，实际是在业务需求阶段压根儿没有想到的，并不代表最终都没有想到。很多开发人员总在埋怨，说客户需求总是在软件项目的后期改来改去，为什么？客户并不是软件研发领域的专业人员。在业务需求阶段，由于没有可以展示和操作的实物，客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定了客户会有很多自己压根儿没有想到的需求。那么为什么他们会在软件研发的后期提出来呢？因为软件研发的后期，客户能拿到那些研发成果的实物，去操作，可以看到。这时候，很多他们起初没有想到的需求就会源源不断地被提出来。但这时候，我们作为研发人员会很伤，我们付出的代价会很大。所以，以被动的态度去完成需求分析工作，必然会给项目研发带来巨大的风险。  如何解决这样的问题呢？首先，在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。从需求列表到产品需求说明书，这之间要经过一段长长的路，这段路就是我们的分析与设计，而不是简单的记录与编写文档。只有经过这样的过程，最后得到的才是高质量的需求分析，才能有效地指导软件研发，避免项目的风险。所以说，好的需求分析人员就是软件项目的司命，掌握着项目的生死。  我们再换一个角度来分析，客户之所以提不出需求，关键就在于他们没有可以展示和操作的实物，总是在空对空的凭空想象今后的软件应当做成什么样子。我们能否改变这样一种现状呢？于是，迭代式的需求分析与开发就出现了。我们先用最短的时间先做一个可以展示和操作的原型给客户看，让客户提一些意见。然后我们再在这个原型的基础上再多做一些，再给客户看。我们就这样一步一步推进，直到最终项目研发结束。采用这样的方式，最适合那些客户在项目初期提不出什么需求，也没用合适的参照物来进行需求分析的软件项目，特别是那些数据分析与决策类的软件项目。  接下来，我们再回到那些从客户嘴里说出的需求。在需求分析人员中，比较普遍的一个看法就是，只要是从客户嘴里说出来的，就一定是对的，我们必须照着做的，这种看法是不正确的。因为客户在软件开发方面是非专业的，所以他们在提出需求的时候往往会考虑不够周全。有一次，客户在提出来一系列业务操作以后，最后提出了一个统计报表的功能。这个统计报表是从前面这一系统操作数据中统计出来的，因此我们就对这些业务操作及其结果数据进行了一个详细的分析，最后发现根据这些数据统计出来的数据存在很多的问题，甚至可能出现相互矛盾的地方。随后我们与客户就这些问题进行了深入地探讨，最终客户不得不承认，他当初在设计这个报表的时候考虑不周全。在提出问题的同时，我们又提出了我们的解决方案，这是非常关键的。当我们提出我们的合理化建议以后，客户欣然接受了。同时，客户对我们这种非常专业的分析与处理过程大加赞赏，无形中也提高了我们在客户心目中的威望。  不仅如此，客户作为一个群体，客户与客户之前对同一问题也可能存在不同的看法，这特别突出地体现在那些多组织机构的管理系统中。因此，对于一些客户非正式的场合提出的需求我们要仔细甄别。一个比较可行的方法就是，先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的需求评审会、需求定稿签字确认会等等，以比较正式的形式讨论和确定下来。  最后，我不得不说，企业信息化管理实质就是一次改革，是企业摒弃手工操作，向信息化建设迈进的一次改革。既然是改革，就必须要改变过去不合理的管理流程，向更加合理和高效的管理流程迈进。因此，我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度，我们的需求分析就进入了一个更加崭新的层面（关于需求分析中的流程分析，我们还会在后面详细探讨）。