問題出現(xiàn)了并不可怕，只要我們追本溯源，找到問題根源所在，科學(xué)的解決問題，合理的制定流程，就能離成功更近一步。

線上事故，這應(yīng)該是產(chǎn)品經(jīng)理最怕的事情。很不巧，我的產(chǎn)品這幾天正好遇到了線上事故，在處理完問題之后，我對(duì)事故進(jìn)行了復(fù)盤，警以為戒，希望各位輕拍。

“小凡，你看微博有用戶反饋xx問題?！?/p>

每次聽到運(yùn)營妹子的聲音都會(huì)有種心驚肉跳的感覺，因?yàn)檫@悅耳的聲音背后往往意味著用戶吐槽，意味著線上bug。這不，昨天剛發(fā)布的版本出現(xiàn)了問題，用戶怒了。

問題是什么

我負(fù)責(zé)一款以內(nèi)容為核心的工具型應(yīng)用，在我們最新發(fā)布的版本中，我們對(duì)內(nèi)容展示頁面進(jìn)行了優(yōu)化，索引詞會(huì)高亮顯示以幫助用戶更好地查看、理解內(nèi)容。

但是上線后用戶反饋索引詞的順序有問題，全部提至了句首，導(dǎo)致句子全部錯(cuò)誤，無法正常閱讀。

問題在哪里

程序設(shè)計(jì)錯(cuò)誤

程序猿在做索引詞高亮處理時(shí)，程序邏輯設(shè)計(jì)不當(dāng)，雖然對(duì)索引詞加了高亮，但是處理高亮詞是將整個(gè)句子視作一個(gè)詞條進(jìn)行處理，提取索引詞后進(jìn)行高亮處理，將高亮詞放回時(shí)，替換其到index=0的位置，導(dǎo)致索引詞顯示在句首。

功能測(cè)試遺漏

測(cè)試同學(xué)在做模塊化測(cè)試、全功能測(cè)試時(shí)，并未測(cè)試到該細(xì)節(jié)，導(dǎo)致該bug發(fā)布上線，當(dāng)用戶反饋后才補(bǔ)充了內(nèi)容測(cè)試相關(guān)case。

存在問題的原因

新代碼設(shè)計(jì)不合理

舊的邏輯是按照空格進(jìn)行字符串的分割，將句子拆分為一個(gè)個(gè)詞，再去判斷是否有索引詞，如有則提取出來做高亮，而我們本次處理的內(nèi)容由于語種特性并沒有空格。

程序猿并未考慮新需求的不同之處，依舊使用統(tǒng)一的處理方式，導(dǎo)致新的語種內(nèi)容在呈現(xiàn)上出現(xiàn)異常。

正常處理邏輯應(yīng)該是不按空格進(jìn)行拆分，直接判斷例句中是否包含所查索引詞，如有并作高亮顯示。

提測(cè)單未寫明修改點(diǎn)

按規(guī)范每輪單元測(cè)試，需將新功能、修改點(diǎn)、可能涉及的影響都寫明，讓測(cè)試同學(xué)知曉以便進(jìn)行全面測(cè)試。但在開發(fā)同學(xué)看來本功能較小，并未在單元提測(cè)中單獨(dú)標(biāo)明。

測(cè)試未覆蓋內(nèi)容版塊

測(cè)試針對(duì)新功能、UI和測(cè)試用例進(jìn)行了測(cè)試，但是未考慮到本應(yīng)用是重內(nèi)容的應(yīng)用，缺乏對(duì)內(nèi)容的測(cè)試。

我們能做什么

安撫用戶

定位問題之后，運(yùn)營同學(xué)第一時(shí)間與微博用戶聯(lián)系，先表達(dá)歉意，再標(biāo)明程序猿正在修復(fù)中，請(qǐng)用戶耐心等待；同時(shí)發(fā)布正式通知，告知用戶問題已經(jīng)開始修復(fù)，我們將盡快發(fā)布新版本以解決問題。

緊急修復(fù)

在運(yùn)營同學(xué)發(fā)布通知的同時(shí)，程序員立即著手修復(fù)該bug，并針對(duì)此前忽略的內(nèi)容問題進(jìn)行復(fù)查，自測(cè)通過后移交測(cè)試人員。測(cè)試通過后，請(qǐng)教研同學(xué)配合進(jìn)行內(nèi)容測(cè)試，確保內(nèi)容相關(guān)展示無誤。

盡快發(fā)版

蘋果應(yīng)用商店的正常審核流程是3至7天不等（必須吐槽），但是緊急bug刻不容緩，不能走此正常流程。面對(duì)極其重視用戶體驗(yàn)的蘋果，加速審核申請(qǐng)往往能幫你在數(shù)小時(shí)候?qū)徍送ㄟ^。

必須讓蘋果知道你是非常重視用戶體驗(yàn)的，而你的app現(xiàn)在出現(xiàn)了非常嚴(yán)重的bug，為了用戶的體驗(yàn)?zāi)惚仨毩⒖贪l(fā)布一個(gè)版本，這樣加速審核通過的概率會(huì)很高。審核通過后，立即發(fā)布上架讓用戶更新，這時(shí)候用戶更新說明也是至關(guān)重要的，值得用心去寫。

我們應(yīng)該做什么

上面幾個(gè)步驟重在解決已發(fā)生的問題，而在我看來更重要的是知道如何規(guī)避未來的問題。這就涉及修改流程了，我們是這么做的：

1.兩端開發(fā)人員系統(tǒng)梳理代碼邏輯，差異點(diǎn)、疑問點(diǎn)及時(shí)進(jìn)行溝通、確認(rèn)；

2.版本正式開發(fā)前，增加技術(shù)拆分會(huì)，確認(rèn)開發(fā)思路和實(shí)現(xiàn)邏輯；

3.iOS開發(fā)人員加強(qiáng)代碼交叉review；

4.iOS開發(fā)人員加強(qiáng)自測(cè)，自測(cè)中加強(qiáng)與安卓端對(duì)照；

5.測(cè)試人員增補(bǔ)內(nèi)容測(cè)試用例，加強(qiáng)兩端對(duì)照測(cè)試；

6.嚴(yán)格執(zhí)行產(chǎn)品體驗(yàn)會(huì)，發(fā)版前組織教研、內(nèi)容、運(yùn)營等人員進(jìn)行產(chǎn)品體驗(yàn)。

寫在后面

這次事故出現(xiàn)后，我們團(tuán)隊(duì)迅速行動(dòng)，從bug定位到新版本發(fā)布上線，只用了不到24小時(shí)，我想這也是值得欣慰的一點(diǎn)吧。

愿各位同行的產(chǎn)品都不會(huì)出現(xiàn)事故！