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

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

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

以下是本次復(fù)盤的迭代需求。

一、需求背景

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

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

二、遇到的問題

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

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

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

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

三、如何避免

可以發(fā)現(xiàn)，上面提到的兩種問題，其實都是細節(jié)的疏漏，要想解決細節(jié)的問題，那必然是需要細心才行。

產(chǎn)品經(jīng)理做產(chǎn)品需求，其實就是在解決問題，要解決問題，首先要了解現(xiàn)狀，了解背景，了解問題點。

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