管理需求变更的目的不是为了要避免变更，而是有序的控制变更，减少和降低（比必要）需求变更，保障项目的有序进行。
项目一旦开工，往往都是开工没有回头箭，硬着头皮都要往死里整的节奏，特别是甲方的项目。在IT领域，最难搞的就只有甲方的项目了，而且它有先天的特性————付费方往往都是大爷。
所以需求的变动那是家常便饭，没有变更往往不正常。
任何项目都有一个特色，那就是项目之前群情激昂，至于过程和结果，有的怨声载道，有的劫后余生，万象丛生都很正常，越大的项目故事往往越多。
中国人办事，在事情还没正式开始时，往往什么话都好谈，丑话讲前头，往往好办事。
所以这个良机千万不可错过，必须在确保所有相关方头脑清醒，态度温和的动工之前，把未来可能预知的风险尽量评估，并形成有力的项目环境，以及良好的决策沟通机制。
所以，接受一个新项目新任务，首先要做的不是谈需求，写文档，画原型，而是要明确规则，启动项目之前首先要搞清楚边界，梳理好规范，什么是必须要做的，什么是可以变更的，通过什么机制，流程来实施变更等等。。。。。。
否则，你面临诸多不可调和的矛盾，在所难免。
要知道，产品经理的一个重要职责就是确保团队始终朝着确定的方向前进。什么是方向？迈开腿之前就要说清楚。
作为PM，你只有在有序、可控的情况下，才能确保项目的按质按量的交付，通常你都不可能在频繁的接受需要变更的情况保证项目的质量和进度，以及资源投入。
变更都是有代价的，你需要让你的团队，你的客户都深刻的理解需求变更的代价，任何在项目之初的轻视都会埋下隐患。在评估代价（包括成本、时间等多方面）过程中，一定要让相关方一起做判断：“我可以修改，但您能接受后果吗？”
所以，只有当你建立起了一定的，看上去像那么回事的机制，你才可能有机会拎得到你的变更管理三把斧。
第一板斧：统一需求入口
为什么需要产品经理，产品经理的使命是什么呢？
其中至少有一个极强的因素，那就是控制需求入口，搞清楚要做什么，该做什么，以及能做什么。
切记：并不是所有的变更都要修改，也不是所有变更都要立刻修改，明确需求变更管理流程的目的是为了决定什么类型的变更需要修改和什么时候修改。
所以，你需要牢牢的控制需求的入口——需求的接收渠道和管理平台，它决定整个项目的边界范围，力保大方向不要变动。为此，你应该有足够的心里准备，你需要面对N多方的压力和“撕逼”。
甚至，为了项目交付的这一终极目标，你需要有不惜得罪人的思想准备。越是大项目，越是牵涉多方的项目，风险和协调都会是指数级的放大。
当一个项目，失去统一的需求入口，当一个产品经理失去对入口的控制，意味着项目的失控。
第二板斧：评审后再动手
“不要接到需求就直接动手”。
你需要让整个项目团队，包括上至老板、直到程序员，也包括外部的客户，都认同、理解并遵守一个基本原则，那就是程序员不直接接受任何非PM的需求，不接收任何非经过评审的需求——所有未经过评审的需求，只可讨论，不可执行，减少（避免）张嘴就来的非必要、非紧急、非合理的无效变更。
明确并管理需求变更审批环节、审批人员、审批事项、审批流程。
作为产品经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级。
当然，你可以适当根据需求的范围大小，决定评审的范围，甚至可以决定需要告知的对象，这没有标准，需求灵活把握。
这里其实是有一个例外，那就是技术本身驱动的变更，比如有更好的实现方案可以带来性能的提升，这个情况，需要根据整体项目状况，结合技术本身的能力判断。
第三板斧：保持持续跟踪
俗话说“好记性不如烂笔头”。
任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。一定要专人负责需求的梳理，跟踪和进度的反馈。
完整的需求变更记录文档将有助于你了解整个项目情况，包括执行的需求，被拒绝的需求，你需要一个“需求池”统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。
今天被拒绝的需求，不等于将来也会拒绝，今天已经执行的需求，也不代表未来依然可行。
控制节奏
你确定了规则，梳理好了边界，甚至也形成了流程。
下一步，你得控制好整个产品的推进节奏，合理的控制和调节需求、变更的优先级，以及资源的投放力度，什么事情该投入多少资源，什么时候该做什么事情，什么是关键路径，什么是关键角色，你必须门儿清。
你得想方设法让你的项目，在你所能控制的范围内进行，一旦超过边界，你可能需要启动后备资源予以干预，而且是在苗头开始之际。
你所有的干预手段，预防机制，都是为了确保项目按照一定的规则和秩序推进，也只有基于可控的节奏，你才能确保整个过程的质量，以及最终交付的质量。当过程不可控的时候，往往结果会很糟糕。
最后，一定要深刻的理解，需求是不断的演进和变化的，合理的规避不合理的变更方为上策。
有些时候，无论你怎样控制，由于市场的压力，总会碰到各种“无理”要求，如何看待这样的问题，就不是简单的控制问题了，这就需要更高的层面去权衡利弊，如果确实不值得，也只能放弃。
这是一个简单的图例，来说明项目中对需求的控制过程，符合上述的基本规则。
你可以结合实际的项目结合，把需求的评审，变更机制，根据项目组织结构绘制一个完整的变更流程，包括需求的评审范围，决策机制，文档的追踪存档等环节。
不要害怕和拒绝变更。
产品经理作为引路人，就是尽可能的让不确定性的因素，变为确定的，可被执行的流程、方案。
—— END ——
