不得不修改的“軟件產品需求變更”如何來提前準備應對？

上篇文章小編解釋了軟件產品需求變更的緣由和要素，接下來分享一下有關應對需求變更的常見的3種方法及應對場景如下：

提高代碼的可複用性、可擴展性

在向產品添加相似功能或修改原始相似功能時，將可能在某些產品中使用的各種控件和功能模塊添加到高度可重用的代碼中很有用。可擴展性則是各種接口、數據庫以及底層結構不要寫死，儘量用可擴展的方式寫。例如，現在有五個類別。不要寫五個，而要寫n個類別（目前是五個）。這是常識，但是有些程序員仍然會比較隨意，對編寫代碼沒有遠見。其他代碼功能，如果有利於減少產品變更和優化成本，也應引起更多關注。

根據產品計劃充分準備

有多種方法可以實現每個功能。如何選擇不僅是當前的成本，而且要注意未來產品的總體規劃。目前可以完成功能A，有1、2和3個選項，而選項1成本最低。但是在將來，如果您想完成A，B，C和D的許多功能，則選項3更有利於最大程度地降低總體成本。然後選擇選項3並提前計劃。與產品團隊進行更多的溝通，以瞭解未來產品的外觀，哪些功能是必需的以及哪些功能可用（主要是從長遠來看）。

合理預留修改時間

不要將研發時間視為完成時間。研發功能只是一部分，應該保留測試，糾正錯誤和處理意外情況的時間。在兩種情況下，應保留更多時間進行修整。一個是研發團隊不確定功能本身，它可能是一個全新的功能，它可能是一個更困難的功能，並且可能存在許多錯誤和功能執行不佳，那麼您需要保留更多時間。另一個是產品團隊對功能表示懷疑。例如，在提供需求時，可能需要調整此功能，或者如果對功能本身的信心不足，則應保留更多時間進行調整。