2、如何界定需求变更？对于软件产品，比如调整某个按钮，这种调整只需要5分钟就能修改好，这类要不要记为变更？如果算为变更，为修改这个问题走变更流程，反而效率低。如果不算变更，调整次数过多以及这类调整积到一起也是要花费一定时间的。

3、需求变更要不要分级别，比如一级变更、二级变更

首先，限定变更次数是不可行的，研发型项目中技术服务业业务，所以当对方以“业务需要”为理由是，你很难设置硬性的限制。所以很多时候原型阶段比较重要，在这个阶段，尽可能多的与Sponsor 做沟通，这里强调，第一是真正的Sponsor，而不是传话的人，另外所谓尽可能多，是你把所有你认为不清晰的都尽可能谈清楚，即使对方没有时间，甚至没有意愿，你也要不厌其烦地去和对方谈。产品团队与开发团队间，需要一个协调的机制，从产品团队的角度讲，确实也不能不负责任地改来该去，这一点在项目完成后的变更统计中应该可以看出来（有些企业以此作为绩效的一个指标）

2、如何界定需求变更？对于软件产品，比如调整某个按钮，这种调整只需要5分钟就能修改好，这类要不要记为变更？如果算为变更，为修改这个问题走变更流程，反而效率低。如果不算变更，调整次数过多以及这类调整积到一起也是要花费一定时间的。

理论上说，任何变更都要走流程、有文档，当然具体操作项目经理是有一定的决定权的。但技术上讲，走流程的好处不仅仅是评估时间与费用，有时也是为了记录和统计，是项目的绩效数据更加合理。同时走书面流程也是为了让发起者更加重视，项目中过多的“零成本”变更往往是无益的

3、需求变更要不要分级别，比如一级变更、二级变更

每个企业有不同的做法，我个人倾向有一个简单的分级系统，便于明确优先级。

2.界定需求变更一直都是项目管理的难题。要能清晰地界定出是否是需求变更，就要求范围基线的定义要细致、准确，包括工作说明书、需求规格说明书、范围矩阵等等，需求评审、需求签字的工作都要做到位、做出效果，而不是走过场。

3.需求变更要分优先级、重要性或紧迫程度。

一般客户的小的变更不满足，会影响客户满意度，但是如果客户还是愿意走变更流程的话，说明客户真有这方面变更的需要。