需求变更这件事，每个开发人员都遇到过，每个产品经理也都遇到过。
　　以前，我们会追求需求不变更，但无论是产品型团队还是项目型团队，需求不变更都是天方夜谈，不可能实现的。即使把需求变更的成本提得很高，流程搞得很复杂，又要填变更单，又要几级经理审批，又要需求评审，依然无法避免。
　　于是，团队的目标变成了少变更，希望尽量少的变更既能满足业务的需要，又能减少开发团队的反感。但‘少’是个相对的概念，我们无法在数量上区分什么情况是少。
　　现在，在敏捷开发模式下，团队要拥抱变化，响应变化，甚至要积极变化。需求是在不停的变，但麻烦也来了，开发团队因为需求变更有了额外的支出，与产品经理的矛盾也在加深，变还是不变，成为产品团队与开发团队PK的永恒话题。
　　显然，有效的变更是所有人员都不否认的，也是对用户有利、对公司有利的双赢结果。那么在变来变去之间，如何减少变更的成本，提高变更的收益呢？
　　在这里我想谈的是发挥需求优先级的作用。
　　在软件需求管理中，有关于需求优先级管理的必要性、定义、识别方式等很多相关的内容，这里不再赘述。我们还是来看一个迭代过程当中比较典型的情况，随着迭代的进行，开发出来的交付物的增多，产品经理提出某个需求要变更，这个时候如何来做？
　　如果这个变更是一个删除行为，即该需求不在本迭代做了，那通常容易解决，开发团队也乐于处理，但做为管理者要注意的是这里有开发成本的浪费。即使该需求没有投入开发，那也经过了需求评审、技术方案设计、测试用例撰写、交互设计输出等工作。不过这个既然不是与开发人员的矛盾之处，不再多说了。
　　如果这个变更是一个修改行为，即对正在开发中的某个需求进行修改，产品经理需要将变更交给开发团队进行可行性和工作量评估，如果工作量比原来启动会上的要少或相当，也问题不大，至少不影响迭代计划，大家都可以接受。如果工作量在增多，那与新增需求的处理方式相同了。
　　如果这个变更是一个新增的需求，需要投入更多的工作量，那么要想在有限资源的前提下满足迭代产出，必须进行优先级调整，产品经理要明确这个变更是必须的、有条件的、还是可选的，开发团队用这个优先级来决定开发顺序。如果是必须的，且已经没有资源支持，那么要重新评估未开发的需求优先级，对其他的部分进行降级等调整。同时，优先级的定义过程，也是产品和开发团队深入思考需求的又一个契机，会促进整个团队对需求、成本、目标方面的一致性理解。
　　当然，这也为产品经理提了更高的要求，那些10个需求使用了10个优先级的产品经理，你这样的优先级定义你们Boss造吗？
　　总之，需求变更不可避免，敏捷开发拥抱变更，但变更是有成本的，也是易于产生矛盾的，优先级定义是缓解矛盾的工具之一，利用优先级，把好钢用在刀刃上。