范围蠕变

范围蔓延是指项目预期交付内容逐渐不受控制地扩大，这种扩大是通过一系列零散的小额新增项目实现的，而这些新增项目从未根据进度、预算或目标进行评估。每次新增项目单独来看似乎都合理，正因如此，这种累积效应才难以察觉，直到最初的承诺无法实现为止。

区分“蔓延式开发”和“合理调整”至关重要，但两者之间的界限却常常模糊不清。如果证据表明最初的计划是错误的，那么改变方向就是经过深思熟虑的决定，并且充分考虑了其成本，而这正是迭代开发旨在实现的。“蔓延式开发”则恰恰相反，它缺乏这种决策：工作量的增加没有经过任何人的评估，因此权衡取舍从未被明确提出，其后果最终表现为错过截止日期，而不是一种选择。

这种机制通常是社会性的而非程序性的。利益相关者在评审过程中提出一个小的改进建议，开发人员在工作中注意到一个相关的改进，规范中的歧义被宽容地解决，而每次改进都微不足道，不足以引发正式变更请求的麻烦。许多此类改进累积起来的影响相当显著，而且由于没有对单个改进进行跟踪，因此无法将超支归因于任何具体原因。

模糊的需求是最可靠的结构性原因。如果“完成”的定义含糊不清，工作量就会不断扩大以适应任何新出现的解释，而实施过程中解决的每一个歧义往往都会导致工作量增加。明确的验收标准和对范围外内容的明确说明可以消除大部分这种不确定性，而且列出排除项比列出包含项要有效得多。

镀金层是内部生成的变体，经常被忽视，因为它源于交付团队而非利益相关者。开发人员和设计师会添加超出预期的功能、可配置性和鲁棒性，理由听起来合情合理，认为最终会需要这些功能。但实际上往往并非如此，而这些额外的复杂性最终会永久地体现在维护成本中。

解决之道并非僵化，僵化反而会适得其反，导致做出明知错误的事情。有效的办法是建立一种轻量级的机制，使新增内容清晰可见，成本明确：任何新增内容都会被记录、评估其影响，然后要么被接受并相应移除或延期，要么被拒绝。关键在于，必须由有权做出权衡的人来做出决定，而不是让团队默默承受。

固定范围、固定日期、固定资源的承诺是项目规模膨胀最具破坏性的结构性条件，因为没有有效的释放机制，压力最终会转嫁到质量上。当这三者都真正固定时，唯一剩下的变量就是工作完成的质量，而由此产生的偷工减料最终会以缺陷和返工的形式显现出来。只有将范围作为灵活的维度，才能保证其他承诺的落实。

由于控制权取决于拥有权力和拒绝新增事项意愿的人，因此问题通常是治理问题，而非项目管理问题。实际上，这种机制是在内部建立的。 产品开发 除了交付流程之外，决定哪些事项优先于哪些事项的优先级排序原则，也依赖于通过以下方式维护的证据： 产品研究，并在 产品工作室 参与方面，明确规定哪些内容超出范围通常是在工作开始之前达成一致，而不是在工作进行中再进行协商。