在实际工作中，遇到最多的情况就是需求变更，不仅会让开发人员对产品产生厌烦感，同时会使得计划的工期发生延误或者其他情况。
如何有效处理需求变更呢？总结起来就是区分出需求的所属层次，判断的标准很简单，就是需求方变更的需求是否会影响到关键路径业务，如果不加这条变更的需求，已有的是否能满足关键路径业务，如果不能影响，那么可以按照需求的紧急、重要程度做排列，【紧急、重要>重要、不紧急>紧急、不重要>不紧急、不重要】,划分出需求的程度，各块再按照从1-5作个标识，添加进下一版本作为优先开发的需求。
如果此条变更需求，已经影响到关键路径业务，不改，满足不了先有需求，那么和需求方商量，分析更深层次的需求在哪里，是否有其他更好的解决方案，都考虑周全，实在必要的，在进行需求变更，当然流程上需要需求方提出变更申请，尽量不要让需求方与开发人员直接沟通接触（实例，容易产生生产事故）
