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

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

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

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

一、需求背景

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

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

二、遇到的問(wèn)題

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

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

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

另外還存在歷史需求改動(dòng)的問(wèn)題，因?yàn)槭窃谠泄δ苌献鰞?yōu)化迭代，不可避免的對(duì)于原有功能的一些邏輯做了調(diào)整，但是因?yàn)橹暗墓δ芴^(guò)常用，一些細(xì)節(jié)的地方被忽視了。比如在之前的注意點(diǎn)文案中，說(shuō)明了該申請(qǐng)單只支持模型A和B的更新申請(qǐng)，在模型C加入進(jìn)來(lái)之后，這部分文案并沒(méi)有同步更新，雖然對(duì)于整體流程沒(méi)有影響，但如果恰好有人看到了之前的文案，可能就會(huì)產(chǎn)生疑問(wèn)，進(jìn)而產(chǎn)生相應(yīng)的咨詢溝通成本。

三、如何避免

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

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

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