你有哪些策略应对不断的需求变更？

                                                不管是互联网的产品，还是传统IT的甲方项目，需求不定是常事，变是唯一的不变。频繁的需求变更，对团队无疑是巨大的消耗和打击，作为PM，是否有好的途径和措施处理需求变更？如何让团队能够相对轻松的应对变更？


需求变更总是带来危机
先梳理一个基本的概念：一个产品是由一个或多个项目组成，而一个项目可以是一个版本，也可以是一个模块功能。也就是，为了降低耦合度和管理的难度，一个项目不应当出现多个产品成果的局面，这种“项目”应该通过项目组或项目群的机制来协调控制。
产品强调的是成果，比如产品的一个版本，项目强调的是对过程的控制，按质按量如期交付。

需求的变更发生在任意的一个项目过程，它针对的是一个过程的影响，进而给整个产品带来重大甚至致命性的影响，轻则延期发布，重则分崩离析。
作为产品经理，要理解的第二个概念是：项目的金三角（范围S、进度T、成本C），当然也可以说是项目的四要素：范围、进度、成本和质量。

S、T、C三者之间存在强烈的制衡关系，当你需要扩大/变更范围（也就是需求边界）的时候，一定会给进度和资源的投入带来影响，变更的范围越大变更的频率越高，则对进度和资源的影响越大，也就是你不要奢望“又想马儿跑,又不给马儿吃草”。由于S、T、C之间的制约关系，产品的质量必然随着需求的变更带来影响，而且往往是负向的影响，最坏的局面可能是产品质量急剧下滑直到演变为质量事故，而团队的士气也会随着频繁的变更而低落甚至崩溃。
变更通常意味着当前的项目路径摇摆不定和失去控制，人可以适应变化，但对未知的世界会感到恐惧，简单的说就是“不知道你的需求什么时候是个头”，当团队失去盼头的时候，就会像推翻了潘多拉魔盒一般。
管理需求变更的目的不是为了要避免变更，而是有序控制变更，减少和降低需求变更对产品开发的影响，包括成本、进度和质量的影响。
尽早明确游戏规则
项目一旦开工，往往都是开工没有回头箭，硬着头皮都要往死里整的节奏，特别是甲方的项目。在IT领域，最难搞的就只有甲方的项目了，而且它有先天的特性————付费方往往都是大爷。
所以需求都变动那是家常便饭，没有变更往往不正常，基于此，作为PM，首先要做都第一件事情就是要明确规则，启动项目之前首先要搞清楚边界，梳理好规范，什么是必须要做的，什么是可以变更的，通过什么机制，流程来实施变更等等。产品经理（或者是项目经理）的一个重要职责就是确保团队始终朝着确定的方向前进。

需求管理就是制定项目的交通规则
什么时候梳理规则
答案是开工之前，或者是研发写码之前。
任何项目都有一个特色，那就是项目之前群情激昂，至于过程和结果，有的怨声载道，有的劫后余生，万象丛生都很正常，越大的项目故事往往越多。在事情还没正式开始时，往往什么话都好谈，制定规则也相对容易，所以这个良机千万不可错过，必须在确保所有干系人头脑清醒，态度温和的动工之前，把未来可能预知的风险尽量评估，并形成有力的项目环境，以及良好的决策沟通机制。否则，你面临诸多不可调和的矛盾，在所难免。
作为产品经理，尽可能的丑话讲在前头，为未来的荆棘之路清理掉一些沙子石头。
哪些基本原则需要遵守
（1）重视需求变更
作为PM，首先你要能深刻的理解变更将给你以及你的团队带来巨大的影响，你需要在战略上保持清晰的头脑，你只有在有序、可控的情况下，才能确保项目的按质按量的交付，通常你都不可能在频繁的接受需要变更的情况保证项目的质量和进度，以及资源投入（这句话带有极强的绝对性）。
你还需要让你的团队，你的客户都深刻的理解需求变更的代价，任何在项目之初的轻视都会埋下隐患。
（2）统一需求入口
为什么需要产品经理，产品经理的使命是什么呢？其中至少有一个极强的因素，那就是控制需求入口，搞清楚要做什么，该做什么，以及能做什么。
所以，你需要牢牢的控制需求的入口——需求的接收渠道和管理平台，它决定整个项目的边界范围，为此，你应该有足够的心里准备，你需要面对N多方的压力和“撕逼”，甚至，为了项目交付的这一终极目标，你需要有不惜得罪人的思想准备。越是大项目，越是牵涉多方的项目，风险和协调都会是指数级的放大。
当一个项目，失去统一的需求入口，当一个产品经理失去对入口的控制，意味着项目的失控。
（3）评审后再动手
“不要着急做”，“不要任何人接到需求就开始动手”。
你需要让整个项目团队，包括上至老板、直到程序员，也包括外部的客户，都认同、理解并遵守一个基本原则，那就是程序员不直接接受任何非PM的需求，不接收任何非经过评审的需求——所有未经过评审的需求，只可讨论，不可执行。
作为产品经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级。当然，你可以适当根据需求的范围大小，决定评审的范围，甚至可以决定需要告知的对象，这没有标准，需求灵活把握。
这里其实是有一个例外，那就是技术本身驱动的变更，比如有更好的实现方案可以带来性能的提升，这个情况，需要根据整体项目状况，结合技术本身的能力判断。
（4）保持持续跟踪
俗话说“好记性不如烂笔头”。任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。
完整的需求变更记录文档将有助于你了解整个项目情况，包括执行的需求，被拒绝的需求，你需要一个“需求池”统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。
今天被拒绝的需求，不等于将来也会拒绝，今天已经执行的需求，也不代表未来依然可行。
需求变更过程示例

这是一个简单的图例，来说明项目中对需求的控制过程，符合上述的基本规则。
你可以结合实际的项目结合，把需求的评审，变更机制，根据项目组织结构绘制一个完整的变更流程，包括需求的评审范围，决策机制，文档的追踪存档等环节。
节奏，一定要控制节奏
你确定了规则，梳理好了边界，甚至也形成了流程。
下一步，你得控制好整个产品的推进节奏，合理的控制和调节需求、变更的优先级，以及资源的投放力度，什么事情该投入多少资源，什么时候该做什么事情，什么是关键路径，什么是关键角色，你必须门儿清。你得想方设法让你的项目，在你所能控制的范围内进行，一旦超过边界，你可能需要启动后备资源予以干预，而且是在苗头开始之际。
你所有的干预手段，预防机制，都是为了确保项目按照一定的规则和秩序推进，也只有基于可控的节奏，你才能确保整个过程的质量，以及最终交付的质量。当过程不可控的时候，往往结果会很糟糕。
最后，一定要深刻的理解，需求是不断的演进和变化的，合理的规避不合理的变更方为上策。
不是你的团队害怕和拒绝变更，而是对不可预知的状态的担忧，或者质疑。产品经理作为引路人，就是尽可能的让不确定性的因素，变为确定的，可被执行的流程、方案。
【注：本文排除一种可能性——“产品上线在即却发现不符合用户/客户的基本需求”，这应该归属于产品的方向性错误，严格来说已经超过变更的范畴。】