需求實(shí)戰淺析:了解現狀,才能解決問(wèn)題

0 評論 1222 瀏覽 2 收藏 5 分鐘

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

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

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

以下是本次復盤(pán)的迭代需求。

一、需求背景

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

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

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

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

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

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

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

三、如何避免

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

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

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

本文由 @向上的小霍 原創(chuàng )發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉載。

題圖來(lái)自Unsplash,基于CC0協(xié)議。

該文觀(guān)點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

更多精彩內容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒(méi)評論,等你發(fā)揮!