產(chǎn)品經(jīng)理系列(8):需求上線失敗怎么辦?
編輯導語:很多做產(chǎn)品的同學,在需求上線時,本應該皆大歡喜,卻突然出了岔子,需求上線失敗了該怎么辦?作者分享了需求上線失敗的原因以及應對的方法,我們一起來看戲吧。
相信很多做產(chǎn)品的同學都會遇到需求上線的情況,但并非每次上線都能發(fā)送成功郵件,感謝相關(guān)參與同學,大家皆大歡喜,然后開啟另一輪產(chǎn)品迭代。
那遇到上線失敗時該怎么辦呢?筆者根據(jù)自己過往經(jīng)驗總結(jié)如下辦法,供大家相互交流討論:
一、分析為什么會上線失?。?/h2>
上線失敗的原因其實有很多,歸結(jié)起來主要是如下幾個角色的原因?qū)е拢?/p>
1. 產(chǎn)品經(jīng)理的原因
- 產(chǎn)品在設計之初考慮不夠周全,臨上線才知道還有某個需求沒設計,導致流程無法閉環(huán),此時研發(fā)和測試完全來不及開發(fā)和測試,比如履約過程中缺貨標記之后,沒有缺貨訂單的處理邏輯;
- 產(chǎn)品設計本身存在缺陷,在測試驗證的過程中,發(fā)現(xiàn)按照新版本的產(chǎn)品需求,與該需求之前的邏輯或者別的需求存在邏輯沖突,是一個此對彼錯的情況,比如數(shù)據(jù)需求中相同數(shù)據(jù)指標,不同統(tǒng)計口徑,將會導致用戶對數(shù)據(jù)的信任度缺失而棄用產(chǎn)品。
2、研發(fā)同學的原因
研發(fā)代碼bug,俗話說,沒有寫過bug的開發(fā)不是好開發(fā),而產(chǎn)生bug的原因有很多:
- 對產(chǎn)品需求的理解存在偏差,比如產(chǎn)品需求本意是希望做到賬號維度的數(shù)據(jù)權(quán)限區(qū)分,而開發(fā)同學理解成了角色維度的權(quán)限區(qū)分;
- 粗心了,多寫了一個標點符號或者用錯標點符號,雖然這個錯誤很低級,一般是新手研發(fā)容易犯這種錯誤;
- 方法錯誤,對實現(xiàn)某種邏輯的方法存在問題,導致實現(xiàn)效果與預期存在偏差;
- ……
測試環(huán)境的服務與預發(fā)布環(huán)境或生產(chǎn)環(huán)境有差異,導致測試環(huán)境正常,而生產(chǎn)環(huán)境出現(xiàn)錯誤,測試環(huán)境與生產(chǎn)環(huán)境的配置不同,這個問題在絕大多數(shù)的公司都存在,基于成本考慮,測試環(huán)境的流量相對于生產(chǎn)環(huán)境沒那么大,所以基本上是測試環(huán)境的服務配置低于生產(chǎn)環(huán)境,而不同的服務配置可能導致代碼的運行效果不同。
代碼分支合錯,這個問題雖然不常見,但是在我無數(shù)次上線失敗的經(jīng)歷中,還真有不少研發(fā)同學犯這個錯誤,其實對于做過開發(fā)或者熟悉開發(fā)代碼合并流程的同學應該知道,代碼分支的命名基本都是英文的,而相近版本的命名更相近,在不注意的情況下,是很容易合并錯誤的。
3. 測試同學原因
- 測試驗證不夠周全,僅驗證了需求本身,沒有回歸驗證全鏈路產(chǎn)品,導致局部功能正常,但是完整的數(shù)據(jù)流存在問題,比如會員卡狀態(tài)禁用,只保障了卡狀態(tài)的禁用功能正常,但是對于會員卡狀態(tài)的狀態(tài)廣播未做測試,導致POS業(yè)務沒有收到狀態(tài)變更,引起POS仍能刷卡消費,而實際系統(tǒng)已經(jīng)無法積分和消費,產(chǎn)生錯誤;
- 測試分工出現(xiàn)遺漏,臨上線才知道某個需求無人來測。這個錯誤很少發(fā)生,但是對于大型復雜系統(tǒng)來說,其實容易出現(xiàn)這個分工偏差。
二、分析能否挽回失???
這個其實就需要具體問題具體分析了,對于某些研發(fā)原因,比如代碼分支合錯,部分小bug之類的,其實是可以當天修復當天上線的,但對于方法錯誤等比較復雜的錯誤,其實很難短時間解決。
那么怎么決定能否挽回呢?建議拉著相關(guān)產(chǎn)品、研發(fā)、測試同學一起,就相關(guān)問題進行討論,主要討論三點:
- 問題產(chǎn)生的原因是什么?
- 問題的修復方案是什么?
- 修復方案的責任人和時間需要多久?
最后形成結(jié)論,該問題是否需要當晚進行修復。
三、上線失敗怎么處理?
如果經(jīng)過產(chǎn)品、研發(fā)、測試同學的原因分析,綜合評估發(fā)現(xiàn)不能當天修復上線,那就需要做好以下兩件事:
1. 后續(xù)處理方案和計劃
針對不同的原因,輸出不同的解決方案,并對解決方案制定相關(guān)責任人和時間節(jié)點,建議溝通的內(nèi)容形成既要,可以群通知,也可以郵件周知,主要包括:
【背景】:上線失敗的原因說明;
【方案】:失敗原因的處理方案;
【計劃】:處理方案的時間節(jié)點
【責任人】:處理方案的相關(guān)責任人及分工;
2. 周知相關(guān)方
主要包括業(yè)務方、相關(guān)領(lǐng)導。這里有兩個點需要注意一下:
- 親自電話與需求提出方溝通對齊,告知對方補救的方案和時間計劃;
- 郵件周知相關(guān)方:郵件的內(nèi)容建議與相關(guān)產(chǎn)品、研發(fā)和測試溝通對齊話術(shù),避免存在理解偏差,造成不必要的團隊不和諧。之前我遇到一起就是沒有與研發(fā)和測試溝通對齊話術(shù),而是直接生硬地說了失敗的原因和計劃,其實本身是沒錯的,只是對于問題的責任方可能不太好,可以潤色一下話術(shù),盡量強調(diào)改進方案和計劃,弱化問題的責任方。
四、案例參考
各位業(yè)務同學、領(lǐng)導:
非常抱歉周知你xxx需求因xxx原因上線失敗,針對該原因,我們同產(chǎn)品、研發(fā)、測試及業(yè)務同學溝通商討出xxx方案,該方案計劃xxx時間點完成上線,責任人分別是產(chǎn)品-xx,研發(fā)-xx,測試-xx,請各位周知,若時間點存在改動,我會提前周知大家,謝謝。
xxx產(chǎn)品部
2021年8月2日
作者:iJob,如果你對商業(yè)、產(chǎn)品感興趣,歡迎交流溝通,微信公眾號:商業(yè)案例研究
本文由 @企榮之路 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于CC0協(xié)議。
- 目前還沒評論,等你發(fā)揮!