需求变更是哪些因素导致的？做好需求变更管理的方法

(一)什么是需求变更

需求变更，即对项目或者软件开发需求的更变，是指在跟客户签订了项目或软件开发协议之后，在完成交付之前，客户提出的对项目或者软件的功能或非功能性的更改要求。
客观地说，“项目一旦启动，变更也就随之而来”，但是，需求的变更必然会影响到项目的开展或者软件的开发，需求变更对项目或者软件开发成败有重要影响，我们既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以控制需求变更才是最好的应对策略。当然，需求变更控制的目的不是控制变更的发生，而是对变更进行科学的管理，要确保变更有序地进行。
一般地说，为了确保需求变更符合双方的利益，可以采取如下措施来控制需求变更：
1.分级管理客户需求，重点客户重点管理；
2.项目开发生命周期全过程需求变更管理，确保整个项目顺利完成；
3.专人负责需求变更管理工作，确保工作同步进行； 

4.契约化管理需求变更。合作双方在签订协议之初，书面约定需求变更的提出方式、评价程序、修改要求、执行过程以及验收要求等。只有这样，才能确保需求变更按程序和要求有序进行。
5.需求变更必须提前沟通，双方要加强信息交换，防止搞突然袭击，更不能提出超越双方能力的需求变更。

（二）客户的需求变更的常见原因有哪些

1. 需求变更对项目的影响：当客户提出新需求的时候，需求人员应该分析这些需求对项目带来的风险，得出双方实现变更需求需要的成本，包括时间、人力、资源等等方面。变更都是有代价的，在评估代价对于项目的影响中，要让客户了解变更的后果。变更之后面临的最大问题就是项目延期，和客户一起做判断：“我可以做修改，但您能接受后果吗？”。这样会出现三种可能：客户接受延期，项目组按照客户要求进行修改；客户不接受延期，并愿意将变更取消或者延到下个合同处理；客户不接受延期，但要求在合同要求完成时间点完成，这种情况很有可能项目失败。（第三种情况是在软件项目中出现最多，并且最让项目经理头疼，但是由于这个情况的分析很复杂，推荐项目经理参阅林锐博士的《如何管理软件企业》第二版，书中有详细阐述。）2. 需求变更管理不能降低需求变更，但能够控制和管理需求变更，需求变更管理是对变更的需求进行科学的管理，并规范流程。需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增减、客户对功能的需求改变等。在软件项目中，变更可能来自客户方、供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因： 业务不熟悉，范围没有圈定就开始细化； 缺乏需求开发（需求调研、分析）能力； 流程不规范，缺乏需求变更管理流程，没有建立需求基线等； 没有区分好合同外的变更。项目经理必须面对这个现实：需求变更是不可避免的。项目经理应该做的，是如何针对可知的变更的来源进行预防，是如何在发生需求变更的情况下尽量减少其对项目的影响。

（三）你有哪些策略应对不断的需求变更

从零开始学运营，10年经验运营总监亲授，2天线下集训+1年在线学习，做个有竞争力的运营人。了解一下

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

需求变更总是带来危机

先梳理一个基本的概念：一个产品是由一个或多个项目组成，而一个项目可以是一个版本，也可以是一个模块功能。也就是，为了降低耦合度和管理的难度，一个项目不应当出现多个产品成果的局面，这种“项目”应该通过项目组或项目群的机制来协调控制。

产品强调的是成果，比如产品的一个版本，项目强调的是对过程的控制，按质按量如期交付。

需求的变更发生在任意的一个项目过程，它针对的是一个过程的影响，进而给整个产品带来重大甚至致命性的影响，轻则延期发布，重则分崩离析。

作为产品经理，要理解的第二个概念是：项目的金三角（范围S、进度T、成本C），当然也可以说是项目的四要素：范围、进度、成本和质量。

S、T、C三者之间存在强烈的制衡关系，当你需要扩大/变更范围（也就是需求边界）的时候，一定会给进度和资源的投入带来影响，变更的范围越大变更的频率越高，则对进度和资源的影响越大，也就是你不要奢望“又想马儿跑,又不给马儿吃草”。由于S、T、C之间的制约关系，产品的质量必然随着需求的变更带来影响，而且往往是负向的影响，最坏的局面可能是产品质量急剧下滑直到演变为质量事故，而团队的士气也会随着频繁的变更而低落甚至崩溃。

变更通常意味着当前的项目路径摇摆不定和失去控制，人可以适应变化，但对未知的世界会感到恐惧，简单的说就是“不知道你的需求什么时候是个头”，当团队失去盼头的时候，就会像推翻了潘多拉魔盒一般。

管理需求变更的目的不是为了要避免变更，而是有序控制变更，减少和降低需求变更对产品开发的影响，包括成本、进度和质量的影响。 

尽早明确游戏规则

项目一旦开工，往往都是开工没有回头箭，硬着头皮都要往死里整的节奏，特别是甲方的项目。在IT领域，最难搞的就只有甲方的项目了，而且它有先天的特性————付费方往往都是大爷。

所以需求都变动那是家常便饭，没有变更往往不正常，基于此，作为PM，首先要做都第一件事情就是要明确规则，启动项目之前首先要搞清楚边界，梳理好规范，什么是必须要做的，什么是可以变更的，通过什么机制，流程来实施变更等等。产品经理（或者是项目经理）的一个重要职责就是确保团队始终朝着确定的方向前进。

（四）需求管理就是制定项目的交通规则

什么时候梳理规则

答案是开工之前，或者是研发写码之前。

任何项目都有一个特色，那就是项目之前群情激昂，至于过程和结果，有的怨声载道，有的劫后余生，万象丛生都很正常，越大的项目故事往往越多。在事情还没正式开始时，往往什么话都好谈，制定规则也相对容易，所以这个良机千万不可错过，必须在确保所有干系人头脑清醒，态度温和的动工之前，把未来可能预知的风险尽量评估，并形成有力的项目环境，以及良好的决策沟通机制。否则，你面临诸多不可调和的矛盾，在所难免。

作为产品经理，尽可能的丑话讲在前头，为未来的荆棘之路清理掉一些沙子石头。

哪些基本原则需要遵守

（1）重视需求变更

作为PM，首先你要能深刻的理解变更将给你以及你的团队带来巨大的影响，你需要在战略上保持清晰的头脑，你只有在有序、可控的情况下，才能确保项目的按质按量的交付，通常你都不可能在频繁的接受需要变更的情况保证项目的质量和进度，以及资源投入（这句话带有极强的绝对性）。

你还需要让你的团队，你的客户都深刻的理解需求变更的代价，任何在项目之初的轻视都会埋下隐患。

（2）统一需求入口

为什么需要产品经理，产品经理的使命是什么呢？其中至少有一个极强的因素，那就是控制需求入口，搞清楚要做什么，该做什么，以及能做什么。

所以，你需要牢牢的控制需求的入口——需求的接收渠道和管理平台，它决定整个项目的边界范围，为此，你应该有足够的心里准备，你需要面对N多方的压力和“撕逼”，甚至，为了项目交付的这一终极目标，你需要有不惜得罪人的思想准备。越是大项目，越是牵涉多方的项目，风险和协调都会是指数级的放大。

当一个项目，失去统一的需求入口，当一个产品经理失去对入口的控制，意味着项目的失控。

（3）评审后再动手

“不要着急做”，“不要任何人接到需求就开始动手”。

你需要让整个项目团队，包括上至老板、直到程序员，也包括外部的客户，都认同、理解并遵守一个基本原则，那就是程序员不直接接受任何非PM的需求，不接收任何非经过评审的需求——所有未经过评审的需求，只可讨论，不可执行。
作为产品经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级。当然，你可以适当根据需求的范围大小，决定评审的范围，甚至可以决定需要告知的对象，这没有标准，需求灵活把握。

这里其实是有一个例外，那就是技术本身驱动的变更，比如有更好的实现方案可以带来性能的提升，这个情况，需要根据整体项目状况，结合技术本身的能力判断。

（4）保持持续跟踪

俗话说“好记性不如烂笔头”。任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。

完整的需求变更记录文档将有助于你了解整个项目情况，包括执行的需求，被拒绝的需求，你需要一个“需求池”统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。

今天被拒绝的需求，不等于将来也会拒绝，今天已经执行的需求，也不代表未来依然可行。

需求变更过程示例
这是一个简单的图例，来说明项目中对需求的控制过程，符合上述的基本规则。

你可以结合实际的项目结合，把需求的评审，变更机制，根据项目组织结构绘制一个完整的变更流程，包括需求的评审范围，决策机制，文档的追踪存档等环节。

节奏，一定要控制节奏
你确定了规则，梳理好了边界，甚至也形成了流程。 

下一步，你得控制好整个产品的推进节奏，合理的控制和调节需求、变更的优先级，以及资源的投放力度，什么事情该投入多少资源，什么时候该做什么事情，什么是关键路径，什么是关键角色，你必须门儿清。你得想方设法让你的项目，在你所能控制的范围内进行，一旦超过边界，你可能需要启动后备资源予以干预，而且是在苗头开始之际。

你所有的干预手段，预防机制，都是为了确保项目按照一定的规则和秩序推进，也只有基于可控的节奏，你才能确保整个过程的质量，以及最终交付的质量。当过程不可控的时候，往往结果会很糟糕。

最后，一定要深刻的理解，需求是不断的演进和变化的，合理的规避不合理的变更方为上策。

不是你的团队害怕和拒绝变更，而是对不可预知的状态的担忧，或者质疑。产品经理作为引路人，就是尽可能的让不确定性的因素，变为确定的，可被执行的流程、方案。

（五）如何做好需求变更管理

项目是以客户的需求为中心，而不是为技术而迁就需求。 本章包括以下内容： 一. 让客户畅所欲言，罗列出所有的需求 二. 透过现象分析潜在的需求 三. 利用自然的语言描述项目模型 四. 利用示意图和图表将用户的需求表现出来。 五. 什么人要看需求分析报告？ 六. 建立需求变更日志，制作新版本的需求分析报告。 七. 本阶段重点工作角色 八. 总结

一：让客户畅所欲言，罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。 很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！

二：透过现象分析潜在的需求 很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。 比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。

笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。

三：利用自然的语言描述项目模型 在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。