项目成功的基础是什么？有的人说是项目资源，万事以人为本，人肯定是基础；有的人说是技术能力，技术上没有可行性，项目就无法完成；还有的人说是项目管理方法，无规矩不成方圆……

不同的人有不同的看法、不同的角度。其实，不同的想法都源于实际项目开发中面临不同的环境。就我开发过的项目来说，虽然这些都很重要，但是我认为项目成功的基础是项目的需求分析。

为什么这么说？因为项目对于技术要求并不高，项目体量也不大，唯一有难度的是业务需求比较复杂，专业性非常强。举个例子，基本每个项目都会涉及行业深度的业务逻辑，很多时候需要抽象出来搭建业务模型，所以需求分析是项目成功的关键步骤。

3.3.1 需求的概念

需求是什么？简单来讲需求就是一个对于最终软件各方面的描述文档。我们再来看看几个权威机构对需求的定义是什么样的。

电气与电子工程师协会（IEEE）的软件工程标准词汇表中对需求的定义是：用户解决问题或达到目标所需的条件和能力；系统或系统部件为满足合同、标准、规范或其他正式规定文档所需具有的条件和能力；以上条件和能力的文档说明。

能力成熟度模型集成（CMMI）的需求管理规范中对需求的定义是：需求是对产品或过程的操作、功能和设计的特性或约束的表述，这些表述是明确的、可测试的、可度量的，而且对于产品或过程的可接受性(被顾客或内部质量保证措施)来说是必需的。

《活用PMBOK指南》（第6版）中对需求的定义是：为满足业务需求，某个产品、服务或成果必须达到的条件或具备的能力。

《需求工程》一书中对需求的定义是：系统必须实现什么样的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

可以看出，虽然表述各有不同，但是都表达出同一个核心观点：需求的提出和实现就是帮助用户解决问题和痛点的。

3.3.2 需求分析的四个步骤

当我们明确需求的概念后，就可以开始做需求分析。我把需求分析分成四个步骤，即明确背景、调研收集、整理分析、编写文档。

1. 明确背景

了解某一个事物，需要结合这个事物所处的环境，项目需求分析同样要了解项目的背景知识。可以说，对于项目背景的理解有助于项目的需求分析。结合我自己的实际工作经验，总结出项目背景一般有以下几类。

（1）解决现存问题：这也是大部分项目的需求背景，通过项目解决目前工作中某些环节或流程中存在的问题。

（2）政策的出台和法律法规的要求：每年国家都会出台相关政策，指导各行各业更好地发展，公司也是通过项目的形式来落实政策。而国家和各地方政府也会定期更新或者颁布新的法律法规，公司也需要及时按照新的法律法规依法生成项目。

（3）战略需要：公司根据其公司战略或经营战略的需要，对不同的项目有不同的要求。我以前在某外企工作时，有个1000多万元的项目，公司最后和客户签订的合同金额是600多万元，我当时不太理解，领导说该项目是战略性项目，不是盈利项目。经过这么多年的发展，那个项目确实具有战略性，带来的价值是不可估计的。

（4）竞争赛道和抢占市场：每个行业都向着精细化发展，对公司来说，赛道越分越细，竞争越来越激烈，为了弥补某种产品或者服务的缺失而进行的项目实施。

（5）引入新技术：目前人工智能、大数据、区块链、数据可视化等技术发展迅猛，如果项目中不引进这些最新技术，市场竞争力会大大降低。由于新技术的发展，公司也会需要启动一些项目，专门引入新技术。

2. 调研收集

在项目的需求调研过程中，针对不同的对象，会产生不同的需求分类。

（1）业务需求：反映组织、公司或客户对系统、产品高层次的目标要求，它们在项目章程及需求范围文档中予以说明。

（2）用户需求：描述的是用户，也就是使用者的目标，即用户（使用者）能使用系统做什么。常常需要用户调研后，通过用例、场景描述、流程图等描述。

（3）功能需求：产品系统的功能需求，即用户可以利用这些功能完成任务，满足用户需求和业务需求。一般用户需求调研分析后的流程图、原型图、需求文档等描述。

3. 整理分析

需求的整理分析其实就是一个需求筛选的过程。

首先是把收集到的需求与项目范围做对比，项目范围内的留下，项目范围外的暂时搁置，根据实际情况再与客户确认。

其次是分析，对于如何分析，每个人都有自己的想法，不管如何变化，项目需求分析的手段都有一些共同的特点和方法。

比如，需求分析的一般过程为：需求的产生过程分析、需求确认分析、需求表达分析、功能要求分析、技术要求分析。大家也许会发现，这个过程好像非常熟悉！没错，其实这个过程就是需求规格说明书的目录。从业务需求和用户需求到功能需求是需求转化的过程。业务需求和用户需求只有经过需求分析的转化，变成产品的功能需求后，才能得到实现。

举例说明

你准备结婚了，家里人要给你买一套婚房。整理的需求分析如下。

（1）需求的产生：需要买结婚用的房子，家里出钱和自己出一部分钱。

（2）需求的确认：除了买房子，还需要装修，因为这是结婚后马上要入住的。

（3）需求的表达：婚房想要面积100平方米以上的，北欧式的装修风格。

（4）功能要求：房本上的名字必须是你和准新娘两个人的，房子必须是三房两厅，房子装修必须美观，硬装修必须是北欧式的风格，必须安全等。

（5）技术要求：为了满足设计的功能要求，应该请什么资质的公司装修，房间布局是否需要改造，水电如何设计，应该安装监控系统和电子锁等。

通过这个比较直观的例子，大家就可以理解需求分析的过程了。

在实际工作中，根据之前的调研结果，比如访谈记录、业务流程图、场景和规则的描述、业务的目标、用户的痛点等，也就是按照业务、用户、功能三大需求逐一按照这个过程进行分析，就能得到我们需要的结果。

4. 编写文档

一般情况下，我们在做完第三步需求整理分析后，就已经完成了很多比如文字性的需求描述，用例图、流程图，甚至原型图等，那么在最后一个步骤，就需要再与甲方进行讨论和验证，并编写整个需求分析文档。

完成需求分析文档后，开始对需求进行管理，而且需求管理要贯穿整个需求分析的过程中。需求管理对文档的依赖性非常强，一定要重视文档。有人觉得写文档太浪费时间了，可是从长远来看，文档其实是能大大的提升效率。

如有新人进入团队，想了解团队之前的工作，他可以直接从文档中就能了解大概。如果没有文档，那他只能点点滴滴都去问其他人了，中间的苦衷就不言而喻了。

对于大型且长期的项目，如果没有文档记录并管理需求，就很容易发生项目需求蔓延或者镀金的情况，这是很多新手项目经理经常犯的错误，也是造成项目延期或失败最主要的原因。当然，对于需求管理同样涉及很多过程及方法，篇幅有限，这里只分享常见的需求文档管理方法。

3.3.3 需求变更的管理

需求的变更不可避免，由于各种原因，如调研不完善、规划不全面、业务有变化等，需求池也是不断变化的，那么如何对这些变化进行管理呢？

1. 版本管理

由于需求的记录还是要用文档的，当需求变化或更新时，要及时更新文档。

规范的需求文档一般都会有文档的“更新记录”这样的类似的章节，每次对版本做详细说明，如本次修改了什么内容、修改人姓名等。

2. 优先级管理

我们都知道，项目的时间是有限的，需求有轻重缓急，必须对需求进行优先级划分，项目经理可以根据需求的优先级进行后续的产品设计和迭代。

3. 完成度管理

对于每项需求的完成度的管理，也是项目经理需要关注的要点，每个需求都是项目范围的一部分，当完成了每个项目的需求后，就意味着完成了项目范围内的工作。

3.3.4 需求分析中的错误认识

需求分析其实就是通过需求采集、需求分析、需求筛选，以及需求变更的管理的一系列过程，挖掘客户描述需求背后的真实诉求和需要解决的问题。

需求分析不是简单的需求搬运工，而是要处理正确的需求。更多时候，客户或用户提出的一般都不是需求，而是问题。他们希望我们需要对问题进行提炼，转化为软件需求（解决方案），然后转交给开发人员。

从问题到解决方案就是一个收集、思考、分析的过程。比如客户提出“所有的工作都要用软件管起来”，这就是一个非常抽象的问题，项目经理需要对问题做深入的了解并转化，才能成为软件需求。很多时候客户的想法并不是最终需求，所以要通过分析识别错误的需求或伪需求，这里不再一一举例。本章最后一节，我们将专门探讨到底什么是真需求。

需求分析的过程也是把控范围的一个过程，比如本次项目的任务是给客户做一个OA管理系统，但客户突然提到他们的办公用品台账管理太乱了，这个问题明显不属于OA的建设范围。技术也是一步一步发展的，客户提出的所有需求并不是技术都能实现的，所有不能实现的需求也要靠分析识别出来。但是需求的收集、分析是项目经理的基本能力，能够引导客户、挖掘需求才是优秀项目。

满足客户提出来的需求不是目的，建立客户在行业领域的标准化管理体系才是目的。这决定了用户提出的需求不一定都要实现，没有提出的需求也不一定不实现。让用户提需求只是实现这个目标的手段之一。

关于需求分析中的错误认识，挑最常见的两点来说明。

（1）没进行需求分析，或者需求分析没完成就急于进入编程阶段。客户期望在后续一边编码一边确定需求，这样的结果就是边写边改，永远改不完，范围蔓延是肯定的，项目延期是必然的结果，而且大多数的结局就是项目失败，项目经理“背锅”。

（2）因为客户缺乏相关知识，认为软件是可以随意更改的。有些客户认为不是硬件做出来就没办法改变了，所以项目需求不断变更。这样的后果是一样的，项目范围永远没有边界，失败是迟早的。

以上这两个现象很常见，不仅很多甲方这么认为，很多乙方的负责人和高层也都是这样的思维。在这种情况下，项目经理一定要有足够的韧性，要有底线思维，利用一切可以利用的资源，做好需求分析工作，为后续项目的成功奠定坚实的基础。