不得不修改的“软件产品需求变更”如何来提前准备应对？

上篇文章小编解释了软件产品需求变更的缘由和要素，接下来分享一下有关应对需求变更的常见的3种方法及应对场景如下：

提高代码的可复用性、可扩展性

在向产品添加相似功能或修改原始相似功能时，将可能在某些产品中使用的各种控件和功能模块添加到高度可重用的代码中很有用。可扩展性则是各种接口、数据库以及底层结构不要写死，尽量用可扩展的方式写。例如，现在有五个类别。不要写五个，而要写n个类别（目前是五个）。这是常识，但是有些程序员仍然会比较随意，对编写代码没有远见。其他代码功能，如果有利于减少产品变更和优化成本，也应引起更多关注。

根据产品计划充分准备

有多种方法可以实现每个功能。如何选择不仅是当前的成本，而且要注意未来产品的总体规划。目前可以完成功能A，有1、2和3个选项，而选项1成本最低。但是在将来，如果您想完成A，B，C和D的许多功能，则选项3更有利于最大程度地降低总体成本。然后选择选项3并提前计划。与产品团队进行更多的沟通，以了解未来产品的外观，哪些功能是必需的以及哪些功能可用（主要是从长远来看）。

合理预留修改时间

不要将研发时间视为完成时间。研发功能只是一部分，应该保留测试，纠正错误和处理意外情况的时间。在两种情况下，应保留更多时间进行修整。一个是研发团队不确定功能本身，它可能是一个全新的功能，它可能是一个更困难的功能，并且可能存在许多错误和功能执行不佳，那么您需要保留更多时间。另一个是产品团队对功能表示怀疑。例如，在提供需求时，可能需要调整此功能，或者如果对功能本身的信心不足，则应保留更多时间进行调整。