项目经理如何做项目需求分析

项目管理，尤其是甲乙双方的项目实施时，项目需求管理是一项非常重要的工作。在项目开始的时候，双方在需求范围上可能不会有太大的分歧，但是随着项目的进展和项目需要交付的产品的完成，在需求评审的时候通常会出现在需求范围上的分歧和冲突。

项目分歧和变更的原因分析

冲突的原因是双方的目标出现了偏差。作为客户，心理是整个产品工作已经基本完成。如果此时接受或者没有提出更完善的要求，那么可以肯定的是，对方以后不会增加人力投入。因此，我们应该借此机会提出一些完善的要求。就像平时在菜市场买菜一样。买了之后，我们总希望老板送点什么，这样我们的心理才会得到满足。

作为执行方，一般会遇到成本的压力。如果继续为客户做一些功能，成本会增加。这是公司不能接受的。不愿意增加的另一个原因是，在需求收集和分析的初始阶段，设计的整体应用架构会遵循一定的原则。如果新增加的需求是基于这个原则，那可能只是工作量的问题。但是如果新增加的功能和整体架构冲突，那就不是工作量的问题，很可能整个产品又要推倒重来，所以实施者会坚决抵制。

因此，需求管理在整个项目中非常重要。一个项目应该指派专门的需求分析师来做需求分析。还需要一个变革管理团队来处理变革。

需求分析师的职责和角色

首先设计整个产品的架构，根据产品架构的设计完善具体的功能需求。在实现过程中跟踪需求实现的质量和结果。

产品架构设计需求分析师要梳理业务架构、应用架构、数据架构、技术架构、安全架构等。这些架构的梳理需要相关架构图的支持。这里一个很重要的工作就是梳理用户组织结构，一定要在组织结构中梳理出可能使用系统的相关用户。

需求的设计和改进需要编写相关的需求规格说明书，并绘制相关的系统原型与用户确认。

在需求质量跟进的过程中，我们必须密切联系用户和客户，并得到他们的认可。以避免大量返工。

需求管理流程及注意事项

根据PMP的相关理论，需求管理对应于范围管理。当我们将范围管理应用于需求时，我们可以将需求管理的过程分为项目宪章阶段、需求架构阶段、需求设计阶段、需求接受-需求控制阶段。

需求租船阶段

需求宪章阶段要求项目经理和需求分析师从整个项目的角度来框定项目的范围和识别项目的风险。

有必要识别项目风险，例如，如果系统需要与多个系统接口。然后一般会有项目进度的风险。

建筑阶段

需求阶段是在项目章程的基础上设计系统架构。这个阶段不需要投入开发资源，只需要架构师或者需求者的参与。

架构阶段的主要目标是整理用户的业务逻辑。设计了系统的应用架构和实现流程。最后确定应用的具体模块组成和二级菜单，以及相关系统的用户和权限。

设计阶段

在设计阶段，根据需求框架，对用户进行访谈和调查。最后得出具体的功能和页面设计细节，可以根据这些功能和细节进行原型设计。

与用户就需求原型设计进行深入讨论，最终达成一致意见后才能交给工程师实施。这里有两点需要注意:

首先，必须得到用户的确认。

第二，可以采用敏捷迭代来加快进度。

接受和需求控制阶段

按说这两个不同的阶段应该是分开的，但是在实际的项目过程中，我们会发现这是一个不可分割的整体。

客户不会提出任何新的需求和变化，这往往是现实。但是一旦你尝试了完整的系统，你会立刻产生新的想法。

接受-改变-接受-改变-接受。一般项目都经历过这个过程。这个过程逐渐缩小管理和谈判的分歧，最终达成一致，完成验收。所以对项目经理的谈判沟通能力要求也很高。

每个项目经理首先要掌握规范的项目管理知识和技能，并在此基础上充分发挥自己的能力和主观能动性。