1: 跟后端開發(fā)多次評審

前一次評審,我說新建發(fā)貨單,默認是已發(fā)貨狀態(tài),開發(fā)不同意,要加備貨中狀態(tài). 再次評審時,開發(fā)說備貨中狀態(tài),會導(dǎo)致判斷其他訂單狀態(tài)更復(fù)雜,但是又擔心物流狀態(tài)不匹配. 我們明確告知他物流狀態(tài)是獨立的,且只是參考.然后果斷去掉了備貨中狀態(tài).

評審中開發(fā)不記得重新拆單時的一個需求:如果已存在相同供應(yīng)商的訂單則合并,否則新建訂單.可能上次評審時沒有詳細說這塊,他也沒細看流程圖和原型圖.所以一次評審是不夠的.

2:跟前端開發(fā)評審

開發(fā)建議去掉訂單合并功能,以前做的類似功能,坑很多.鑒于他經(jīng)驗豐富有資歷,且時間緊迫.就采納了.

開發(fā)建議先去掉單獨商品的取消功能,延用以前的整單取消功能,時間緊迫,而且實際操作時,可能不需要單獨取消商品,后期優(yōu)化也可以.

開發(fā)贊同在一個頁面里顯示所有未拆單商品和已拆單商品,一目了然,所有操作一個頁面搞定.愉快的通過了.

我一直以為自動拆單是支付完成時,系統(tǒng)就拆單完成.但開發(fā)說是批量跑job把狀態(tài)變?yōu)橐淹瓿?并不能調(diào)起自動拆單接口,或者是4s店后臺支付成功,無法和我們的后臺打通. 靈機一動,提議一個圖標用于調(diào)起自動拆單,一個圖標用于查看及調(diào)整拆單方案.考慮到兩個圖標累贅,就用空心的田字圖標標識自動拆單,前端判定已點擊過自動拆單,則變?yōu)閷嵭牡奶镒謭D標,用來標識拆單方案調(diào)整.只顯示一個圖標,通過顏色變化表明功能關(guān)聯(lián). 這樣操作是否會引起歧義,等系統(tǒng)上線后再看操作方反饋.

跟開發(fā)表明:需求方認為不需要自動拆單,可能會是偽需求.如果需求方要經(jīng)常取消訂單再重新拆單,反而增加工作量,畫蛇添足. 不過開發(fā)主管從系統(tǒng)改造的角度,堅持要改.以前的業(yè)務(wù)小伙說更改的概率應(yīng)該不超10%,并且我們的默認供應(yīng)商會加上地域限制,且供應(yīng)商數(shù)量也會增多,人工分配出錯率會增高.所以還是做上這個功能.明白前應(yīng)后果,不做偽需求.

3:跟供應(yīng)鏈溝通

由于供應(yīng)鏈要求展示本品牌,方便特殊品牌更改配送地址,考慮到新增功能可以要做相應(yīng)調(diào)整,去問供應(yīng)鏈是否需要發(fā)貨單的配送地址可編輯.并且說到發(fā)貨單的建立時,由于實際操作的人變更,需求方認為沒有必要.還好原來操作的人在,確認有不少場景是分成多次發(fā)貨的.新功能沒有白做.

而單獨取消商品的場景,他們覺得概率很低. 正好這次不做,實際操作中,如果情況有變,或者痛點明顯,再加也不遲.

4:跟測試溝通

測試小伙認真的總結(jié)了幾個問題,一一答復(fù).但有個地方,總是不明白對方的意思.爭論幾個回合,原來他不清楚拆單方案的頁面,入口還是田字格.他以為是個列表頁,展示所有方案.所以,對于這種特殊入口的情況,要寫個操作手冊,防止其他使用的人不理解邏輯.

對于測試的小伙伴,評審需求時要把每一個操作的流轉(zhuǎn),給他們演示清楚.所以和開發(fā)測試一起評審?fù)戤吅?最好把更新的流程,再一起捋一遍.防止沒聽明白,但又不好意思共同的小伙伴,按照自己意思去做,實現(xiàn)的功能和需求南轅北轍,重新返工排期,就浪費資源啦.

總結(jié):

需求變更是難免的,但要確保參與的各方,都了解變更的內(nèi)容.對整體流程和功能達成共識.

在資源有限的情況下,砍掉性價比不高的功能.

明確需求的前因后果,考慮需求的影響面,盡力優(yōu)化流程,不做無用功.也讓參與的人明白做的事情,意義和價值是什么,更有動力做好.