项目管理，特别是实施甲乙方项目的时候，项目需求管理是一个非常重要的工作。在项目开始的时候双方可能就需求的范围没有太大的分歧，但是随着项目工作的进展等到项目需要交付的产品基本完成以后，在进行需求评审的时候一般会发生对需求范围的分歧和冲突。
项目分歧和变更原因分析
冲突的原因是双方的目标存在了偏差，作为客户方的心理一般是整个产品工作已经基本完成，如果这时候进行验收或不再提出更加完善的需求的话那么肯定以后对方不会再增加人力投入。所以要趁着这个机会提一些完善型的需求。这就像是我们平时在菜市场买菜一样，买完以后总想让老板赠送一些东西，这样自己的心理才会得到满足。
而作为实施的一方，一般会遇到成本的压力。如果继续给客户在做一些功能，成本就会加大。这对于公司来说是不可接受的。另一个不愿意增加的原因就是在最开始需求收集和分析阶段，设计的整体应用架构会遵循一定的原则，如果新增加的需求是在这个原则上的新增也许只是工作量的问题。但是如果新增的功能与整体架构发生冲突的话，那就不是工作量的问题，很有可能是整个产品推倒重来的事情，所以作为实施方才会坚决抵制。
所以需求管理在整个项目中都非常重要，一个项目做好指派专门的需求分析人员来专门进行需求分析工作。还有要成立需求变更管理小组来应对变更。
需求分析师的职责和作用
首先是设计整个产品的架构，并根据产品架构的设计来完善具体的功能需求。在实现的过程中对需求实现的质量和结果进行跟踪。
产品架构设计需求分析师要梳理业务架构、应用架构、数据架构、技术架构、安全架构等。这些架构的梳理需要形成相关的架构图做支撑。在这里有一个非常重要的工作就是用户组织架构的梳理工作，一定要梳理出在组织架构中有可能使用系统的相关用户。
需求的设计和完善需要撰写相关的需求规格说明书，画相关的系统原型来和用户确认。
在需求质量跟进过程中一定要紧密的联系用户和客户得到用户和客户的认可。以避免大面积的返工。
需求管理过程及其注意事项
按照PMP相关的理论，需求管理对应范围管理。我们把范围管理套用成需求，就可以把需求管理的过程分成项目章程阶段、需求架构阶段、需求设计阶段、需求验收&需求控制阶段。
需求章程阶段
需求章程阶段需要项目经理和需求分析师站在整个项目的角度，来框定项目的范围，识别项目的风险。
识别项目风险是非常必要的，例如如果系统需要和多个系统进行对接。那么一般会存在项目的进度风险。
需求架构阶段
需求架构阶段是在项目章程的基础上，进行系统的架构设计。在此阶段不必投入开发资源只需要有架构师或需求人员参与。
需求架构阶段主要目标是梳理清晰用户的业务逻辑。设计系统的应用架构和实现流程。最后确定应用的具体模块组成和二级菜单，以及相关系统使用人员及权限。
需求设计阶段
需求设计阶段在需求架构的基础上，与用户进行访谈和调研。最终得到具体的功能和页面设计细节，并能够根据这些功能和细节进行原型设计。
与用户就需求原型设计展开深入的探讨，最终达成一致然后才能交给工程师进行实现。这里有两点需要注意：
一是一定要得到用户的确认
二是可以采用敏捷迭代的方式加快进度
需求验收&需求控制阶段
按说这是两个不同的阶段应该分开，但是在实际的项目过程中我们会发现这是一个不能分开的整体。
往往出现的现实情况是平时客户不会提出任何新的需求和变更。但是一旦试用了已经完成的系统以后就会马上产生新的想法。
验收—变更—验收—变更—验收，一般的项目都会经历过这样的过程，这个过程通过管理和谈判分歧逐渐收窄，最终达成一致完成验收，所以对于项目经理的谈判和沟通技能要求也很高。
需求管理万变不离其宗，每个项目管理者首先要掌握标准的项目管理知识和技能，在这个基础上来发挥自己的能力和主观能动性。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。