如何应对频繁的需求变更？
对于互联网的项目，需求变更是常事，变是唯一的不变。频繁的需求变更，对团队无疑是巨大的消耗和打击，作为项目经理，是否有好的途径和措施处理需求变更？如何让团队能够相对轻松的应对变更？
需求的变更发生在任意的一个项目过程，它针对的是一个过程的影响，进而给整个项目带来重大甚至致命性的影响，轻则延期发布，重则分崩离析。
作为项目经理，要理解一个概念：项目的铁三角（范围S、进度T、成本C），当然也可以说是项目的四要素：范围、进度、成本和质量。
S、T、C三者之间存在强烈的制衡关系，当你需要扩大/变更范围（也就是需求边界）的时候，一定会给进度和资源的投入带来影响，变更的范围越大变更的频率越高，则对进度和资源的影响越大，也就是你不要奢望“又想马儿跑,又不给马儿吃草”。由于S、T、C之间的制约关系，产品的质量必然随着需求的变更带来影响，而且往往是负向的影响，最坏的局面可能是产品质量急剧下滑直到演变为质量事故，而团队的士气也会随着频繁的变更而低落甚至崩溃。
变更通常意味着当前的项目路径摇摆不定和失去控制，人可以适应变化，但对未知的世界会感到恐惧，简单的说就是“不知道你的需求什么时候是个头”，当团队失去盼头的时候，就会像推翻了潘多拉魔盒一般。
管理需求变更的目的不是为了要避免变更，而是有序控制变更，减少和降低需求变更对项目的影响，包括成本、进度和质量的影响。
一般情况下，需求变动是常事，作为项目经理，首先要做的第一件事就是要明确规则，启动项目之前首先要搞清楚边界，梳理好规范，什么是必须要做的，什么是可以变更的，通过什么机制，流程来实施变更等等。项目经理的一个重要职责就是确保团队始终朝着确定的方向前进。
任何项目都有一个特色，那就是项目开始之前群情激昂，至于过程和结果，有的怨声载道，有的劫后余生，万象丛生都很正常，越大的项目故事往往越多。在事情还没正式开始时，往往什么话都好谈，制定规则也相对容易，所以这个良机千万不可错过，必须在确保所有干系人头脑清醒，态度温和的动工之前，把未来可能预知的风险尽量评估，并形成有力的项目环境，以及良好的决策沟通机制。否则，可能会面临诸多不可调和的矛盾。
作为项目经理，尽可能的丑话讲在前头，为未来的荆棘之路清理掉一些沙子石头。
（1）重视需求变更
作为项目经理，首先要能深刻的理解变更将给团队带来巨大的影响，需要在战略上保持清晰的头脑，只有在有序、可控的情况下，才能确保项目的按质按量的交付，通常都不可能在频繁的接受需要变更的情况保证项目的质量和进度，以及资源投入。
还需要让团队深刻的理解需求变更的代价，任何在项目之初的轻视都会埋下隐患。
（2）统一需求入口
另一点非常重要，就是控制需求入口，搞清楚要做什么，该做什么，以及能做什么。
所以，需要牢牢的控制需求的入口——需求的接收渠道和管理平台，它决定整个项目的边界范围，为此，应该有足够的心里准备，需要面对N多方的压力，甚至，为了项目交付的这一终极目标，需要有不惜得罪人的思想准备。越是大项目，越是牵涉多方的项目，风险和协调都会是指数级的放大。
当一个项目，失去统一的需求入口，当一个项目经理失去对入口的控制，意味着项目的失控。
（3）评审后再动手
“不要着急做”，“不要任何人接到需求就开始动手”。
需要让整个项目团队，理解并遵守一个基本原则，那就是所有未经过评审的需求，只可讨论，不可执行。
作为项目经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级。当然，可以适当根据需求的范围大小，决定评审的范围，甚至可以决定需要告知的对象，这没有标准，需求灵活把握。
这里其实是有一个例外，那就是技术本身驱动的变更，比如有更好的实现方案可以带来性能的提升，这个情况，需要根据整体项目状况，结合技术本身的能力判断。
（4）保持持续跟踪
俗话说“好记性不如烂笔头”。任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。
完整的需求变更记录将有助于了解整个项目情况，包括执行的需求，被拒绝的需求，需要一个“需求池”统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。
今天被拒绝的需求，不等于将来也会拒绝，今天已经执行的需求，也不代表未来依然可行。