在需求管理中，新增的需求還容易處理，但如果是在原有的基礎上進行優化迭代，情況就會比較麻煩：需要兼顧舊需求，又要理清新功能，這種情況，如何處理？

在眾多的產品需求中，大概分為兩種，一種是從無到有的，行話叫從0到1；另一種是迭代優化的。

從無到有的需求，需求邏輯肯定是要從頭開始梳理，但是迭代優化的需求，就要在已有產品的基礎上，來進行需求的增刪改，這就要求在做迭代優化的需求時，既要理清新需求，又要兼顧舊需求，一旦哪里銜接的不好，可能就會產生問題。

以下是本次復盤的迭代需求。

一、需求背景

平臺有一個審批單，是之前的產品經理做好的已有功能，可以進行兩種模型的更新申請，咱們暫且稱其為模型A和模型B。

現在根據業務的要求，需要將模型C的更新申請，也加入到這個審批單中，一個看似很簡單的需求就這樣誕生了。

二、遇到的問題

在這個需求中，所謂的問題，其實也不叫問題，主要是在寫方案的時候，對于一些關聯模塊和一些歷史需求考慮的不到位。

在我們的平臺中，模型申請更新之后，會自動觸發模型的上線流程，而上線流程會先后同步到平臺的多處位置。但是對于后端開發來說，前端所謂的同步是需要在后端先通過代碼實現的，所以在方案中，哪里需要同步更改，就得說明清楚，不然后端在開發時，就會出現遺漏的情況。

好在第一版方案出來后，我們內部對齊了下，及時做了補充，避免了需求開發的二次返工。

另外還存在歷史需求改動的問題，因為是在原有功能上做優化迭代，不可避免的對于原有功能的一些邏輯做了調整，但是因為之前的功能太過常用，一些細節的地方被忽視了。比如在之前的注意點文案中，說明了該申請單只支持模型A和B的更新申請，在模型C加入進來之后，這部分文案并沒有同步更新，雖然對于整體流程沒有影響，但如果恰好有人看到了之前的文案，可能就會產生疑問，進而產生相應的咨詢溝通成本。

三、如何避免

可以發現，上面提到的兩種問題，其實都是細節的疏漏，要想解決細節的問題，那必然是需要細心才行。

產品經理做產品需求，其實就是在解決問題，要解決問題，首先要了解現狀，了解背景，了解問題點。

不管是從無到有的需求，還是迭代優化的需求，深入了解業務和系統現有邏輯至關重要，否則就會出現頭痛醫頭，腳痛醫腳，遺漏業務場景的情況，而且可能會造成場景或不同系統模塊間的沖突，解決了一個問題，卻出現了兩個新的問題。