一、需求获取

　　需求开发在CMMI中有一个专门的过程域来描述，它在项目管理过程中也是很重要的一块，因为后续的设计、开发等都是基于需求。如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来的话，那么在后期选择弥补时，将会造成项目延期以及成本的大幅度增加。

　　需求开发的目的是产生和分析客户、产品和产品组件需求。需求是客户在项目立项时就有的一个远景，在项目管理过程中它得到不断的变更和细化。客户根据需求会决定在整个项目的需求中，要承办方具体要做些什么，即承办方的任务，承办方具体要实现哪些需求。承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。

　　需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户是无法完整地讲述其需求，因此需求获取是一件看似简单，做起来很难的一件事情。在需求获取过程中，主要需要弄清楚3个问题，即：明确需要获取的信息（What）、明确所获取信息的来源和渠道（Where）和怎样获取需求（How）。下面我们分别对这三点进行讲述。

　　1、明确需要获取的信息（What）

　　需求分析师应在需求获取前明确需要获取的信息，以确保在实施需求获取时有的放矢。

　　通常需求获取要获取的信息包括三大类：

　　1）与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；

　　2）与要求解决的问题直接相关的信息；

　　项目管理问题。

　　3）用户对系统的特别期望与施加的任何约束信息。

　　2、明确所获取信息的来源和渠道（Where）

　　接着需求分析师还应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。

　　需求信息的来源通常包括：

　　1）来自客户的需求：

　　a）旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求；

　　b）系统的潜在用户或客户对系统的需求。

　　2）竞争对手的产品优势与不足；

　　3）国家政策、业务规则以及相关行业标准；

　　4）实施产品设计所需满足的需求；

　　5）执行测试验证工作所需满足的需求；

　　6）实施系统安装、维护所需满足的需求。

　　获取需求信息的渠道包括：

　　1）用户或客户；本文转自项目管理者联盟

　　2）公司研发管理部门；

　　3）公司技术管理部门 

　　4）项目实施部门；

　　5）营销管理部门；

　　6）旧有系统的研发项目组；

　　7）来自项目组内。

　　3、怎样获取需求（How）

　　接下来项目经理应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：

　　1）用户访谈用户访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对性地进行；非结构化是只列出一个粗略的想法，根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。

　　用户访谈具有很好的灵活性，有较广的应用范围，但实际操作时存在许多困难，例如客户经常很忙，难以获得充足的访谈时间；客户访谈需要需求分析师有很强的沟通能力，同时也要求需求分析师有足够的相关业务领域知识。

　　2）用户调查

　　用户调查是通过精心设计提问问题形成调查问卷，然后下发到相关人员手中，让他们填写答案，来获取用户需求。

　　用户调查的方法最大的缺点是缺乏灵活性，由于缺乏面多面的交流，所获取的信息量也比较有限。因此在实际工作中，我们建议可以先采用用户调查的方式获取一定量的信息，然后有针对性地开展用户访谈。

　　3）现场观摩用户的工作流程，观察用户的实际操作

　　俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。

　　4）从行业标准、规则中提取需求

　　如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则，需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。 

　　这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向，这对从技术出生的需求分析师来说是一个巨大的考验。

　　5）文档考古

　　对于一些数据流比较复杂的、工作表单较多的项目，有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究，考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告，获得所需的信息。

　　6）需求讨论会

　　这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表，分析人员，开发人员，通过有组织的会议来讨论需求。

　　在会议之前，应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。

　　7）原型法

　　原型（prototype）即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。

　　原型法的优点是：

　　i）鼓励业务管理者的积极参与；

　　ii）有助于解决业务管理者之间的差异；

　　iii）能给业务管理者一个对最终系统的直观感受；4）周期短；5）成本低；6）用户较满意。

　　但原型法也有缺点，主要为：

　　i）导致人们认为最终系统将很快产生；

　　ii）对系统操作权限的说明较弱；

　　iii）不适合于开发大系统；

　　iv）开发过程管理困难。

　　在实际开发过程中，笔者所在公司一般比较常用的需求获取方法是用户访谈、需求讨论会和原型法。对于相对较小的项目，笔者极力推荐原型法，因为通过可视化的界面，可更容易的、更快的挖掘客户的需求。

　　二、人员配置

　　在整个项目的生命周期中，可能涉及到开发方的角色如下：

　　1、需求分析师

　　完成产品或项目的需求调研和开发，将客户的需求变成产品需求，参与需求的讨论和分析，完成需求规格说明书等的编写。

　　2、系统架构师

　　系统架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，他侧重于系统的质量属性设计，包括系统的可靠性、可测试性、可重用性、可维护性、可重用性、可扩展性、性能指标、组件框架设计、共用基础结构等。

　　3、系统分析员

　　该角色是系统设计中的一个主要角色，他参与需求分析、系统功能设计、系统质量属性设计等过程。

　　4、项目经理 

　　项目经理是项目沟通的纽带，他执行项目的进度跟踪、质量管理、客户非技术人员业务交流、项目成员共同、非技术风险管理等职责。

　　5、配置管理员

　　该角色的职责是完成项目中各文档的管理等。

　　6、QA

　　重点关注软件过程的质量，在项目中，主要执行的是监督的作用，他参与需求评审、设计评审等过程。

　　7、开发人员

　　完成系统的编码，在有些公司，开发人员还需要进行部分功能模块的设计。

　　8、测试人员

　　进行系统的测试，例如功能测试、集成测试、系统测试和验收测试等，在测试前期，需要编写测试计划，并编写测试用例来辅助测试。

　　9、美工

　　负责美化系统界面。

　　项目管理者联盟文章，深入探讨。

　　10、项目实施人员

　　职责为进行项目的实施。

　　三、项目管理中需要注意的问题

　　大家都知道，项目管理的四要素为：质量、进度、成本和资源。这四项如果有一项超出控制，项目就可能会失败。在笔者的实践过程中，总结了如下注意事项：

　　1、明确各人员的任务

　　明确各人员的任务并对其进行确认。例如，对各开发人员任务的详细分配后，有些开发人员并不一定清楚了自己所要做的事或理解有出入，做到后来，才发现所做的和项目所需要的南辕北辙，到了这个时候才发现问题，补救不及时的话很可能引起进度的拖延和成本的增加，所以项目经理需要进行确认。

　　2、跟踪项目情况

　　很多开发人员都有这样的情况，前期开发比较轻松，一到要验收的时候，才发现很多功能还不完善，存在很多bug，于是为了在指定时间内完成任务，只得加班加点。其实这也是管理不善引起的，因为没有定期的跟踪项目，对项目所处的状态不太清楚，所以导致了这种情况。

　　3、进行风险分析和管理

　　在项目管理过程中，风险分析也是一个很重要的方面，风险包括很多方面，例如技术风险、人员风险等。若在项目管理不注意风险的管理，那么当项目中的风险发生时，很可能引起项目管理的四要素的问题出现。例如若项目组盲目引入新技术，在中后期才发现该新技术在该系统中不合适。再例如，若在项目后期主要设计或开发人员跳槽，若没有风险管理，没有采取规避或减弱措施，那么当这些风险产生时，将会带来很大的影响。 

　　4、重视需求开发

　　有些项目组对需求开发不太重视，做需求开发时没有深度挖掘客户的需求，在中后期还在进行需求的大幅调整，在进度等方面当然也会受到很大的影响。需求是后续开发的根本，后续的设计、开发、测试等都是基于它的，因而也是重中之重，需要引起大家的重视。

　　本文浅析了项目管理过程中需求开发、人员配置以及项目中需要注意的问题，项目管理是一个很复杂的过程，需要项目组各成员的努力。