特征渐变，也被称为范围或需求蠕变，是指项目范围之外的不可预见的添加和更改请求。它通常是由于不充分的需求收集，糟糕的初始计划，以及不清楚的变更实现协议，以及其他原因而发生的。在本文中，我将根据自己的经验讨论8个技巧和建议，以帮助您在自己的项目中最小化和管理特性蔓延的影响。
1.接受功能渐变会发生的事实。
这是正确的。在这里，您可能认为这篇文章是关于如何防止特性蔓延的。
恰恰相反，我觉得这是一个自然的一部分任何基于项目的工作。承认这种可能性可以让你在它最终抬起它丑陋的代码修改、破坏设计的头时做好准备。预见到计划中不可预见的变化会迫使您更有适应性，并促进解决方案的开发，使其能够灵活地适应客户不断变化的需求。
2.投入足够的时间来收集需求。
这很简单，也是相当常识，但我们都因匆忙完成项目的计划阶段而感到内疚。也许是因为时间和预算的限制，或者是因为我们急于向客户展示具体的结果，或者是因为我们确信项目一旦开始就已经是囊中之物(不会被竞争)。
在这一步上的疏忽最终会导致痛苦，并且会以无法预期的特性需求的形式出现，因为我们没有建立起客户的实际需求。花点时间调查相关人员，观察并跟踪员工，看看他们可能会如何使用您正在开发的系统，并对组织拥有的技术专长做出准确的估计。一盎司的预防抵得上几千行代码的修改。
3.伸出援手可能会让你失去手臂。
如果你不断地向改变妥协，你将来可能会得到更多的改变。试着设定什么是合适的，什么是不合适的修改边界，这不仅可以防止不必要的更改请求，还可以为项目提供严格的质量控制指导方针。
当您决定遵从无范围的需求时，请确保您表明您正在做一些超出范围的事情，并且这可能会导致延迟和额外的财务需求。这可能会让他们重新考虑所要求的功能的价值，或者至少在时间和预算上给予你延期。
4.当要求更改时，要做魔鬼的代言人。
由于您在所需解决方案方面的知识和专业知识，您被雇用并分配到该项目中。如果客户要求使用基于flash的导航菜单，那么作为专家，您有义务说服他们，您开发的基于css的菜单是更好的解决方案。
不要害怕反驳不明智的功能要求;提供合理的理由会让他们确信你知道自己的“本事”，他们可能会允许你按照原计划继续进行。
5.以任务为导向，而不是以愿景为导向。
弄清楚它是什么，完全你是在为他们开发。不要承诺一个宏大的，令人兴奋的，但模糊的/雄心勃勃的最终结果。
不要给出泛泛的概括，比如“我将开发一个搜索引擎优化的网站”，而是试着概述你将提供的可交付成果，比如:“我将使用图像替换技术的子标题，创建和实现Sitemap.xml，提交网站到主要的搜索引擎，并使用相关的关键词优化页面标题。”这使项目不那么模糊，并防止额外的任务，例如开发一个链接交换程序来增加页面排名结果，这显然不是您职责的一部分。
6.抛弃“顾客永远是对的”的心态。
你，往往是一个更有资格判断事物应该如何发展的人。你工作不是为了最后得到一大笔小费。
你的工作(很可能)是按固定费率收费或约定的补偿。你所需要担心的是你的声誉和产生一个优秀的解决方案。雇主可能讨厌你的一切，但如果你提供了一个惊人的利润产生的产品，你会被重新雇用，做更多的工作。
最后，更多的是关于利润和可交付成果，而不是你的雇主有多喜欢你“合理的个性”(因为他们最喜欢的就是因为你开发的解决方案而赚一大笔钱或减少他们的开销)。所以，不要仅仅因为你想讨雇主欢心就向毫无根据的要求和不合理的时间表让步。不要有压力去做一些工作描述之外的事情，或者你觉得会导致不太理想的最终产品的事情。
7.之前的研究。
减少立即适应项目范围变更的诱惑，无论看起来多么简单。如果你认为预算和时间表可以处理计划中的修改，在提交之前彻底研究更改实际需要什么。
例如，在我参与的一个CMS开发项目中，有人问我是否可以将系统从我们的服务器迁移到客户端。这不是项目范围的一部分，因为最初的计划是也为系统提供托管。我同意了，因为一个数据库导出/导入和文件迁移最多需要一个小时的工作。
我没有考虑到我们的服务器设置(IIS 6.0/Windows，客户端是Apache/Linux)和服务器设置是不同的。我只想说，这比预期的时间要长，任务仍未完成。
8.要意识到功能蔓延是双向的。
客户和雇主不是(纯粹的)邪恶。他们无意给我们的工作添麻烦。
通常情况下，我们想要取悦他人，想要证明自己的价值，以及我们的完美主义心态，都是部分(如果不是全部的话)应该受到责备的原因。如果功能蔓延发生了，那只是因为我们允许它发生。我希望本文能够提供一些关于如何管理功能渐变的建议。
这里的建议是基于我自己的错误，即允许范围蔓延影响我的项目。我希望通过阅读本文，您能够更好地减轻超出范围的特性对您的时间线和预算的影响。
我想问的是:功能蠕变是否应该成为任何项目的一部分，或者是否应该完全阻止它?这些建议是理想但不现实的吗?在什么意义上?
分享你的想法!
