第二章 需求获取与分析(上)

 

第 二 章    需求获取与分析

“你不说我怎么知道你想要呢？…”——唐僧

在开发一个项目的时候，需求是项目成功的根本，如何能够获取准确的需求，有很多问题需要探讨。笔者以下就自己的经验谈上一二。

2.1         项目类别

笔者将项目进行了尝试分类，包括：科研类项目、工程类项目、产品类项目。

科研类项目主要来源是国家的科技主管部门（科技部、各地科技委等）。承担者多是学校、科研院所等。科研类项目主要目的在于研究、探索，解决的问题是前沿性、研究性的。主要目的是做出创新。对于软件的工程性要求并不高。考核的指标也不是界面友好性、易用性、规范性等，而是发表的文章，做出的创新性成果。

（场景1：老师：小张，那个XX3的课题做的怎么样了，发表了多少文章，有没有能演示的东西？马上要验收了！！

             小张：差不多了，文章凑够了。系统正在把界面调整一下就可以了。

             老师：好好干。毕业不要急，多学点东西再到社会，对你有好处。

             小张：是（汗！）

）

工程类项目主要是指信息化项目。主要是用信息化技术来解决生产、工作中的问题，提高效率。像MIS、CRM、ERP等都是此类项目。这些项目的成败在于软件工程是否能够贯彻、执行。

产品类项目主要是做软件产品，其目的是做成产品进行销售。其需求并无具体的用户来提出。而面向的是潜在的广大用户。目的是做出市场需要的产品。

对于以上的这三类项目，其需求的来源和获取方式也各不相同。

科研类项目的需求是解决新的科研问题，主要是能够说明该问题解决方案的可行性。也就是说做出的系统通常是原型系统，能够说明可行就达到目的了。

工程类项目则基本上不存在新的科研问题，通常都是使用成熟的开发工具来实现满足甲方需要的应用系统。工程类项目的需求获取是重点，是影响到项目成败的关键所在。必须能够获取清晰、甲乙双方理解一致的需求，才能够在后续的项目进展中不出问题，不走弯路。在下面的一章中笔者将详细介绍需求获取问题。

产品类项目的需求没有明确的用户来提出需求，需要产品调研人员来给出需求，也可以融合技术人员的创造性思维。

目前的信息化项目通常都是工程类项目，而这些项目的成败关键点在于用户需求的获取，以下将具体介绍项目的过程、需求的获取方法和一些经验。

2.2         项目的出现

通常的项目是由甲方提出并发起招标，公开招标的项目会在指定的招标网站上作公布，并由招标公司对这个项目组织招标，感兴趣的投标方购买标书，并进行应标。举个例子来讲，某单位要建立一套办公系统，决定招标集成商来建设此项目。该单位寻找招标公司来负责招标，由招标公司发布标书，标书包括了该单位对系统的需求以及商务需求。

招标类型包括公开招标、邀请招标。公开招标的对象没有限制，只要满足标书中的条件的投标方均可投标；邀请招标是该单位/招标公司可以邀请一些公司/投标方来参加投标。只有在邀请范围内的投标方是有效的。招标的要求可以参考《中华人民共和国招标投标法》。

（场景：

领导（兴奋状）：小张，XX单位要招标啦！快去买标书，写应答，投标。。。

小张（郁闷）：哦。

小张（心想）：看来又要干活了。

 ）

投标方在获得标书后，需要针对标书进行应答，编制投标文件，然后在截止日期前（通常不小于二十天）把投标文件密封好交给招标公司。如果投标方少于三家，那么这次招标就作废，需要重新招标。在投标截止日期的当天，招标公司把所有的投标人召集到一起，打开标书并公布各投标方的投标价格和投标内容。

开标后，招标公司会组织评审专家对各方的投标文件进行评审，评审专家进行打分，评选出中标结果。

对于系统建设招标，通常还要做技术应答，针对招标文件中的用户需求，设计相应的方案，并进行方案评审，由投标方向评审专家介绍系统方案，评审专家进行评审。

（此处画流程图）

中标的单位不出意外的话，就会开始和甲方签合同，正式成为乙方，并开始组织项目组，开始干活了。

（场景：

领导老张（狂喜）：小张，咱们的标中了！看来工作做的好，呵呵。

小张（笑脸相迎）：是呀，领导辛苦了。

小张（心想）：看来不愧是领导，果然有攻关能力。。。

领导老张（严肃状）：小张，马上准备成立项目组，要开工了！

）

对于科研类项目，就需要到相关的部委网站上找申请指南，然后针对指南中的课题，编写申请书来进行申请。

（场景：

老师：小张，下午开会，讨论XXX课题的申请书，下周要报上去。通知一下你们师兄弟，中午少睡一会，下午早点来。

小张（面临大敌状）:：是的，老板。

）

2.3         项目组的成立

拿到项目后，乙方要成立项目组，指定项目负责人/项目经理，组织项目组成员，通常要包括需求分析人员、系统设计人员、开发人员、测试人员、系统集成人员。根据项目的大小和重要程度，配备人员。对于大型、重要的项目（比如政府部门的项目），通常乙方老总级别人物要牵头，协调人员、资源。

（场景：

老总：同志们，我们这次中标，老王、小张都辛苦了。这次的甲方是XX部，这可是我们的大客户呀，我们一定要尽百分之二百的努力，让用户满意！

众人（目光坚定状）：是！

老总：下面我宣布项目组成，项目负责人是总工老张，项目组包括XX、XX、XX、….。我来给你们做后勤保障。下面老张讲几句。

老张：这个项目对我们公司很重要，老总让我做项目负责是对我的信任，我感到很光荣，也感到压力很大…。

老张：我想把这个项目组分成几个小组，XX、XX、XX做需求分析，XX、XX…做设计、XXX、XX…写代码、XXX、XX…测试。具体的分工和计划咱们会后开项目会，拿出一个详细的项目计划书，回头向老总做汇报。

老总（满意状）：老张办事我放心。你们就大胆的干吧。

众喽啰：听领导的话，跟领导走。。。

）

项目组的人员配置是项目成败的关键因素，选对了人（特别是项目经理），可以拿下难度很大的项目，但如果选错了人，特别是项目经理不行，那通常情况下就会导致项目失控等情况，导致最后无法完成项目。

在CMM/CMMI的规范里，强调了项目成败的三要素：人、过程、技术。人是指参与项目的人员，他们的素质和水平决定了项目所能达到的程度，如果选择了很弱的人员，项目的结果就可想而知了。

（场景：

某单位领导：上次的乙方太差劲了，派的都是些什么人！都是些大学刚毕业，拿我们的项目学习来了，做得真是一蹋糊涂，项目一拖再拖。最后我们请他们出局了，别干了！

老总：领导放心，我们派的都是精兵强将，绝对保障这次项目的成功。

领导：嗯，X总，我们听说你们的口碑是很好的，做了很多不错的项目。但我们的这个项目非常重要，在国家都是挂了号的，你们要是干的不好，影响可是非常大的亚！一定要给我派最强的人，不能出问题。

老总（冷汗）：是是，这次您放心，全是我们公司总工、经理组成的团队，我来督阵，绝对没问题。

）

过程是指CMM/CMMI定义的软件过程，可以参考[CMM/CMMI]。

 

2.4         需求的获取

       项目组成立了，就要开工干活了。于是乎，项目经理带着大小喽啰进入甲方所在地，开始调研项目需求。

       通常而言，甲方会有配合项目的人员，协助乙方进行需求调研、需求分析、验证等工作。需求的调研一般会通过会议，现场调查等方式进行，最后要形成《需求说明书》，作为后续设计工作的基础。

       （场景：

       甲方业务人员：我们希望这个系统能够帮我们作……，还能够…..，减轻人工劳动，系统能做得全都给我们作了。

       乙方（点头）：是，我们的目标也是能够帮大家解除人工操作的烦琐事情。以后系统做好了，大家就能轻松多了。

       乙方：我们把大家刚才讲的记录了一下，想跟大家再确认一下，行吗？

       甲方业务人员：好呀！

       乙方：#￥（*……*—（*

       甲方业务人员：关于…，我们的想法是…..

）

       需求讨论是个漫长、反复的过程，如果要把项目做好，需求调研是基础工作，“基础不牢、地动山摇”，前期需求的确定必须要通过甲方、乙方的认真讨论和确认，特别是甲方的用户要参与整个需求调研工作。

       需求调研通常会遇到的几个问题：

（1）       甲方没有经验，没有派出真正的用户来提供需求，乙方没有接触和获取到甲方真正的业务需求。

（2）       甲方派出的用户七嘴八舌，就同一个问题提出多种想法，搞得乙方无所适从，不知道该听谁的。

（3）       甲方的用户对于计算机一无所知，寄希望于通过计算机系统来解决所有的问题，通常的提法是，用这个系统把我们所有的事情都能解决了。

（4）       乙方的人员对甲方的业务领域不熟悉，也不擅于沟通，开会时与甲方没有办法形成互动，大眼瞪小眼，形成冷场。

笔者的解决经验是：

n         对于第一种情况，在项目开始时，乙方一定要首先请甲方派出协调管理人员加入项目的需求调研组，并请甲方派出实际操作业务的人员也加入。另外，乙方要尽可能的调查甲方的业务流程，业务数据模版等，并判断开会时获取的需求是否与实际的需求一致。一定要能够识别真正的业务需求。什么是真正的业务需求？就是业务工作的实际情况，解决业务工作中的实际问题，它不一定是要和现有的业务完全一致，因为有了信息化系统之后，对现有的业务会带来改善，可能会使得业务流程发生变化。总的来件，需要的是在信息化的条件下，实际的业务模式，业务流程，业务数据，业务人员这些方面的情况。

n         对于第二种情况，乙方也一定要请甲方由人负责业务需求的制定，对于甲方中各方面的业务需求建议和意见进行综合、归纳，并能够协调各种需求人员。能够给乙方一个明确的需求。对于五花八门的意见，有所取舍，有所定夺。能够找到合适的这个人选，乙方就是运气很好了。

n         对于第三种情况，也是非常常见的。在这种情况下，甲方得需求管理人员一定要能够分清楚，哪些是计算机可以做的，哪些是机器不能做的，需要人工作的。也一定要向用户耐心的解释好，通常情况下，用户是会理解的。也会在后续的工作中协助乙方的。

n         对于第四种情况，就是乙方的问题了，乙方要能够派出合格的需求获取人员，最好是由用户领域的专业知识，这样能够很快地和用户打成一片，沟通无障碍。如果没有该领域的专业知识，则需要尽快地熟悉用户的领域，以及专业词汇，首先要能做到沟通起来没有二义性，否则用户讲的和你讲的都是同一个词，但是两个意思，两张皮，没有捏合到一起，就很被动了。

（场景：

用户A：关于这个问题，我有个想法，是否我们能够这么…..。

用户B：我不同意你的意见，我觉得这个事情应该这么….。

小张（困惑状）：到底应该听谁的？

老张（沉稳状）：各位讲的都很好，我们听了很有启发。是否请贵单位的业务部门领导来给我们做个指示，采取那种方式来做…。

甲方领导（官腔）：同志们讲的都很好，充分的发挥了主观能动性，这个问题，我是这么认识的，。。。。。

众人（豁然开朗状）：对、对、对，就是这样。

老张：小张快记下来，写到需求说明书中。

小张：是。

）

       另外，在记录每项需求时，记录下需求的提出人和原因，建立起需求在用户处的可跟踪性，以后对于此项需求如果存在疑问，可以询问直接提出者来解答。