”政策
基于上面提到的变更的分类方法，我们可以得到这样一个变更管理的方法：
当一个需求（或者策划案）还处在策划阶段，还没有被送去开发与实现的时候，我们允许这个需求发生改变，甚至允许它发生任何的改变，没有任何限制。而一旦这个需求被送去开发与实现了，那么我们将不再允许这个需求发生任何改变，需求与设计将会被锁定，开发人员将会按照锁定的版本进行开发。
如果在开发过程中，策划人员实在忍不住要提出变更，那么他仅有两个选择：
1，要求项目经理彻底终断掉该需求当前的开发工作，将该需求从当前的开发列表中取消，待其将需求变更修改好后，再重新纳入到下一轮开发计划中；
2，等待已经送交开发的需求开发完成，在已经完成的基础上提出修改（作为一个新需求）并纳入到下一轮的开发计划中。
当一个需求被完成后，如果策划人员需要对已经完成的内容进行变更，那么他需要提出一个新需求，就叫做“对自定义聊天频道修改”，将这个需求纳入到需求库中，并要求项目经理纳入到接下来的开发周期中，作为一个新的开发任务来处理。
那么以上的假设是否可行呢？有没有人真的这么实践过呢？答案是肯定的，敏捷开发方法论（不论是Scrum与XP）都是在以这种方法在管理需求变更，实践的结果也是相当不错的；另外，据我接触的游戏公司中，也有一些公司在采用类似的方法来管理变更（金山的一些项目组就是这么做的，效果很好）。如果想更多的了解敏捷式变更管理，可以参考Ken Schwaber伯伯的书：《Scrum敏捷项目管理》（Agile Project Management With Scrum）
以上的做法，基本上满足了策划与程序的不同需求：策划需要变更，开发不需要变更。开发人员应该对这个方法很满意，既然变化是势不可挡的，但是只要不会直接影响当前工作，也是完全可以接受的；但是策划人员心里还是有一丝不爽：在漫长的开发周期内不能变更，是否太不人道了？
网络游戏开发应该是有周期性的，短迭代周期的增量式开发是比较好的开发模型。瀑布模型肯定是行不通的，如果还有公司在用瀑布模型开发网络游戏，唉，只能默默的祝愿他们一路走好了。长周期的迭代（半年一个周期）也是行不通的，这倒不是这种方法本身有什么问题，而是太长的迭代对于这个快速变化的花花世界来说，太痛苦了。
但是在我们访谈记录中，却发现很多游戏公司居然没有任何开发模型，完全是一种混沌的开发方法，买来一个现成的游戏引擎，想到什么就开发什么，感觉做的差不多了就打个包上线，没采用任何开发模型，没有什么明确的开发周期，一切都是凭着感觉来。这是一个很危险的事情，很多这样的公司，在游戏上线以后，会发现这个游戏制作工作彻底陷入了一团糟的境地，任何局域性方法都无法提供有效的帮助，最终公司进入一个死循环，解决的办法也变得很残忍：要么死掉，要么彻底改革。
任何的针对具体软件开发管理问题的解决办法，都是要在软件开发模型的大框架下才能起效果的。我们不可能把瀑布模型中制定计划的方法用在敏捷开发模型下，我们也不能把打牌估算的方式用在瀑布模型中，因为这些具体方法都是在具体的开发模型的框架下，才具备了生存的条件。就像生态系统一样，热带雨林里的鳄鱼，放到沙漠里面，肯定活不下去的。所以如果一个游戏公司连基本的开发模型都没有引入的话，那么就不要考虑变更怎么管理了；就像在真空中任何生物都无法生存一样，在没有开发模型的环境中，任何开发管理方法也都无法取得效果。
因此，上面提到的这种需求变更管理方法，在瀑布、长周期的迭代式开发模型中，都不会有太大的正面作用，但是在敏捷开发的大环境下，它就会发挥出自己的作用来，优化你的项目管理。