產(chǎn)品經(jīng)理應(yīng)該如何減少上線(xiàn)后的BUG?

1 評(píng)論 6621 瀏覽 15 收藏 12 分鐘

編輯導(dǎo)語(yǔ):作為一名產(chǎn)品經(jīng)理,在產(chǎn)品上線(xiàn)之前對(duì)Bug的測(cè)試是至關(guān)重要的,輕則影響某一環(huán)節(jié),嚴(yán)重的將造成不可逆的流失。因此,產(chǎn)品經(jīng)理應(yīng)該如何減少上線(xiàn)后的Bug?作者總結(jié)了幾個(gè)方法以及如何復(fù)盤(pán)歸檔,分享給你。

一、bug帶來(lái)的影響

  • 某游戲因人物屬性設(shè)置出現(xiàn)bug,導(dǎo)致外掛橫行,戰(zhàn)力體系崩潰,最終核心用戶(hù)流失;
  • 某電商平臺(tái)的優(yōu)惠券功能出現(xiàn)bug,一夜之間造成千萬(wàn)元級(jí)別的損失;
  • 某超大體量的APP最新版本被設(shè)置成了3天后過(guò)期,但實(shí)際上應(yīng)用市場(chǎng)上已無(wú)可更新的版本,差點(diǎn)造成3天后數(shù)千萬(wàn)用戶(hù)無(wú)法使用該APP;

版本上線(xiàn)時(shí),我們最擔(dān)心的一件事情就是出現(xiàn)重大bug,特別對(duì)于已擁有大量活躍用戶(hù)的產(chǎn)品來(lái)說(shuō),一旦新版本出現(xiàn)嚴(yán)重的問(wèn)題,可能造成難以挽回的損失。

出現(xiàn)問(wèn)題后,公司對(duì)事故的起因進(jìn)行調(diào)查和追責(zé)時(shí),無(wú)論因誰(shuí)而起,我們身為產(chǎn)品的負(fù)責(zé)人都會(huì)難辭其咎,成為主要的責(zé)任人或之一,我們將之調(diào)侃為背鍋。

如果只是偶爾背一次還好,大部分人能夠頂?shù)米毫?,但如果總是容易出現(xiàn)各種問(wèn)題,這個(gè)時(shí)候可能就需要我們反思根本問(wèn)題出現(xiàn)在哪,其中是否有我們自身的原因?我們?cè)诠ぷ髦杏惺裁捶椒梢杂行Ы档蚥ug發(fā)生的概率?

剛進(jìn)入職場(chǎng)的時(shí)候,我們應(yīng)該都經(jīng)歷過(guò)背鍋這個(gè)過(guò)程,只是有的人領(lǐng)悟能力強(qiáng),很快就會(huì)找到方法,早早跨過(guò)這道坎,而有的人經(jīng)常做背鍋俠,要經(jīng)歷一兩年才能找到解決的方法。

慘就慘在,我就屬于后面那種,有1年多的時(shí)間里,我經(jīng)常會(huì)遇到版本上線(xiàn)后出現(xiàn)的各類(lèi)問(wèn)題,不過(guò),幸運(yùn)的是我從過(guò)去的工作中,總結(jié)出了幾點(diǎn)方法,之后就很少出現(xiàn)上線(xiàn)后出現(xiàn)重大的bug,職場(chǎng)之路也更加順利,這里想把方法記錄一下同時(shí)也分享出來(lái),幫助更多的人找到這扇門(mén)的鑰匙。

二、bug的避免方法

常見(jiàn)的bug大概可以分為3種類(lèi)型:需求設(shè)計(jì)的缺陷、功能缺陷、性能缺陷,我們分別來(lái)尋找應(yīng)對(duì)方法:

1. 需求設(shè)計(jì)的缺陷

如果因?yàn)槲覀儗?duì)需求的調(diào)研不充分、理解不深,又或者是設(shè)計(jì)功能的時(shí)候思考不全面,從而導(dǎo)致做出來(lái)的邏輯出現(xiàn)漏洞,上線(xiàn)后出現(xiàn)問(wèn)題,那么這類(lèi)缺陷的直接責(zé)任人就是產(chǎn)品經(jīng)理。

出現(xiàn)了此情況,說(shuō)明產(chǎn)品經(jīng)理沒(méi)有做好最基本的本職工作,給團(tuán)隊(duì)其他成員帶來(lái)了額外的工作量,這種情況是我們最應(yīng)該避免和反思的。

產(chǎn)品經(jīng)理每增加一個(gè)功能,都意味著需要投入相應(yīng)的開(kāi)發(fā)、測(cè)試人員進(jìn)去。如果功能開(kāi)發(fā)完成后發(fā)現(xiàn)需求存在缺陷,再回過(guò)頭來(lái)修改,那么至少需要1個(gè)開(kāi)發(fā)去返工。

這對(duì)于項(xiàng)目的資源是一種損耗,同時(shí)也會(huì)引來(lái)團(tuán)隊(duì)其他成員的不滿(mǎn),這種不滿(mǎn)進(jìn)而會(huì)導(dǎo)致其他人對(duì)產(chǎn)品經(jīng)理信任度的降低,當(dāng)產(chǎn)品經(jīng)理失去了團(tuán)隊(duì)成員的信任時(shí),往后的工作將會(huì)舉步維艱。

如何避免?

(1)提高需求設(shè)計(jì)的質(zhì)量

高質(zhì)量的需求輸出物是規(guī)避bug的基本保障,做到這點(diǎn)需要有2個(gè)要素:

一方面,我們要具備設(shè)計(jì)出所需功能的能力,這個(gè)可以通過(guò)競(jìng)品調(diào)研或大量的項(xiàng)目經(jīng)驗(yàn),去積累產(chǎn)品設(shè)計(jì)的案例庫(kù),體驗(yàn)的多了,做到這一點(diǎn)就不會(huì)有太大問(wèn)題。

另一方面,需要我們對(duì)功能的邏輯規(guī)則描述得足夠詳盡完整,理論上來(lái)說(shuō),流程圖、原型、需求文檔做得越細(xì)致,那么bug的數(shù)量就會(huì)越少。

不過(guò)實(shí)際工作中經(jīng)常因?yàn)轫?xiàng)目的時(shí)間有限,很難花大量的時(shí)間在原型和文檔上面,這種情況下,可以把主要的時(shí)間花在核心功能邏輯的思考和描述上面,核心的部分思考越全面、描述越細(xì)致越那么需求的質(zhì)量就會(huì)越高。

(2)重視需求調(diào)研和確認(rèn)

前面提到了需求設(shè)計(jì)的質(zhì)量,還有比這更為重要的,就是需求的調(diào)研和確認(rèn)。若這一步?jīng)]做好,則可能造成后面的努力都付之一炬,因?yàn)樗叩姆较蝈e(cuò)了,最終做出來(lái)的功能就會(huì)無(wú)法滿(mǎn)足用戶(hù)需求,最終造成需求設(shè)計(jì)上的重大缺陷。

因此,前期需要進(jìn)行充分的調(diào)研,明白用戶(hù)真實(shí)的需求是什么。對(duì)于B端的需求來(lái)說(shuō),通常能夠接觸到需求方,那么做需求的過(guò)程中有不確定的點(diǎn),可以及時(shí)與其進(jìn)行確認(rèn),并邀請(qǐng)其參與到需求評(píng)審中來(lái),確認(rèn)能滿(mǎn)足需求后再進(jìn)入開(kāi)發(fā)階段。

2. 功能缺陷

還有一類(lèi)最常見(jiàn)的bug,是開(kāi)發(fā)過(guò)程中,因?yàn)榧夹g(shù)人員自身的原因而產(chǎn)生了bug,我們?cè)谶@里定義為“功能缺陷”。

這類(lèi)問(wèn)題出現(xiàn)后有的產(chǎn)品人會(huì)說(shuō),這不是產(chǎn)品經(jīng)理導(dǎo)致的,與我沒(méi)關(guān)系,既然是開(kāi)發(fā)造成的問(wèn)題就由開(kāi)發(fā)人員去承擔(dān)。我見(jiàn)到過(guò)很多產(chǎn)品人都在工作中有上面這種觀念,我個(gè)人不是很認(rèn)同這種思維。

的確,這個(gè)觀念聽(tīng)起來(lái)很合理,誰(shuí)引起的就由誰(shuí)去承擔(dān),但,在問(wèn)題出現(xiàn)之前我們真的已經(jīng)盡好自己的職責(zé)了嗎?

要知道,雪崩發(fā)生之后沒(méi)有一片雪花是無(wú)辜的,我們是一個(gè)團(tuán)隊(duì),項(xiàng)目上線(xiàn)后出現(xiàn)了技術(shù)bug,會(huì)有主要責(zé)任人,但通常不是某一個(gè)人的責(zé)任,而是多個(gè)人共同造成的結(jié)果,如果密切協(xié)作,這類(lèi)bug大多數(shù)情況下都能避免。

如何避免?
除了測(cè)試人員要盡到自己的崗位職責(zé)外,我們產(chǎn)品其實(shí)也能起到很大的作用,只需把控好一個(gè)關(guān)鍵節(jié)點(diǎn)——就是上線(xiàn)前做好測(cè)試環(huán)境的驗(yàn)收。

產(chǎn)品經(jīng)理進(jìn)行上線(xiàn)前的驗(yàn)收,能夠分別從實(shí)際業(yè)務(wù)使用場(chǎng)景和功能實(shí)現(xiàn)邏輯的角度去測(cè)試,如果時(shí)間允許,可以使用測(cè)試用例去細(xì)致地測(cè),例如功能與產(chǎn)品需求不相符、功能有漏洞這類(lèi)問(wèn)題,很多都能及時(shí)發(fā)現(xiàn),并提前解決。

3. 性能缺陷

這類(lèi)bug是最難察覺(jué)的,通常情況下測(cè)試人員不會(huì)特意去測(cè)試性能,因?yàn)榇蠖鄶?shù)產(chǎn)品的功能并不需要太高的性能,但對(duì)于使用頻率高或有實(shí)時(shí)性要求的功能來(lái)說(shuō),就必須要考慮性能了。

例如大體量電商平臺(tái)的下單流程,短信、郵件平臺(tái)的發(fā)送流程,這類(lèi)存在高并發(fā)業(yè)務(wù)的產(chǎn)品功能,都需要考慮性能,一旦性能未達(dá)到要求,就會(huì)直接影響這些產(chǎn)品的營(yíng)收,有時(shí)會(huì)是致命的缺陷。

如何避免?
產(chǎn)品經(jīng)理在設(shè)計(jì)功能時(shí),需要根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景去判斷這個(gè)功能對(duì)性能的要求是否高,假如出現(xiàn)高并發(fā)、高延遲后對(duì)產(chǎn)品的影響有多大。

如果判斷出該功能對(duì)性能有要求,且性能缺陷對(duì)產(chǎn)品的使用會(huì)產(chǎn)生很大的影響,那么就需要在需求文檔中將性能需求寫(xiě)進(jìn)去,注明對(duì)響應(yīng)的實(shí)時(shí)性、功能的并發(fā)量有什么要求。

三、bug的復(fù)盤(pán)歸檔

前面列舉了常見(jiàn)的3類(lèi)bug,并給出了規(guī)避的方法,這些可以讓缺陷變得可控,降低bug發(fā)生的概率,但是并不能保證上線(xiàn)后就一定不會(huì)再出現(xiàn)bug了,因?yàn)楝F(xiàn)實(shí)情況并不總是理想化的,實(shí)際的工作中存在太多的變量。

萬(wàn)一還是出現(xiàn)了嚴(yán)重的bug,怎么辦呢?

每次出現(xiàn)問(wèn)題后,我們都應(yīng)該對(duì)bug進(jìn)行復(fù)盤(pán):分析bug出現(xiàn)的原因→將問(wèn)題進(jìn)行歸類(lèi)→給出解決方案→進(jìn)行存檔

歸類(lèi)后有助于我們舉一反三,未來(lái)做其他類(lèi)似的功能時(shí),就能避免類(lèi)似的問(wèn)題再次發(fā)生了。

例如做電商的訂單支付時(shí),出現(xiàn)訂單重復(fù)支付的情況,原因是服務(wù)器因網(wǎng)絡(luò)延遲沒(méi)有及時(shí)收到第一筆支付成功的回調(diào)結(jié)果,然后通過(guò)限制x秒內(nèi)不能再次發(fā)起支付、系統(tǒng)每3分鐘查1次支付結(jié)果、自動(dòng)退款邏輯這3個(gè)方法解決了這個(gè)問(wèn)題。

那么在以后做任何涉及到支付的功能時(shí),其實(shí)都可以參考上面這3種規(guī)避的方法了,這就是bug歸類(lèi)的作用。

存檔的作用在于防遺忘和自查,每次記錄bug時(shí),如果發(fā)現(xiàn)這類(lèi)bug已經(jīng)出現(xiàn)過(guò)1次了,那么這個(gè)時(shí)候就能引起反思,以保障下次不會(huì)再出這類(lèi)問(wèn)題。

四、結(jié)語(yǔ)

bug不僅會(huì)給產(chǎn)品本身造成影響,也會(huì)帶來(lái)額外的工作量給我們?cè)鎏頍溃冉鉀Q問(wèn)題更重要的是能夠預(yù)測(cè)出問(wèn)題的發(fā)生,并提前進(jìn)行規(guī)避,希望通過(guò)以上的幾點(diǎn)方法能讓我們都成為一名“bug終結(jié)者”。

如果每次從自己手上的做出來(lái)的功能都很少出現(xiàn)問(wèn)題,那么leader其實(shí)會(huì)覺(jué)察到這是一個(gè)靠譜的人,特別在產(chǎn)品初期,將有助于我們實(shí)現(xiàn)職場(chǎng)的進(jìn)階。

 

本文由 @汪仔9090 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來(lái)自u(píng)nsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 標(biāo)準(zhǔn)的軟件研發(fā)流程中,每一步都在幫助產(chǎn)品經(jīng)理發(fā)現(xiàn)問(wèn)題、解決問(wèn)題。
    常規(guī)流程:需求分析(產(chǎn)品自我檢查)——產(chǎn)品需求評(píng)審(開(kāi)發(fā)、測(cè)試角度發(fā)現(xiàn)產(chǎn)品方案問(wèn)題)——測(cè)試案例評(píng)審(測(cè)試角度覆蓋整體案例,包括新功能測(cè)試,回歸測(cè)試,間接影響功能測(cè)試)——開(kāi)發(fā)編碼(實(shí)際編碼過(guò)程中,極有可能出現(xiàn)在實(shí)現(xiàn)需求時(shí),發(fā)現(xiàn)產(chǎn)品經(jīng)理的需求存在需求遺漏或不嚴(yán)謹(jǐn),需要與產(chǎn)品溝通后,讓產(chǎn)品經(jīng)理發(fā)起需求變更流程。)——測(cè)試(大量問(wèn)題在此處發(fā)現(xiàn)并修復(fù))——代碼評(píng)審(技術(shù)角度發(fā)現(xiàn)代碼邏輯BUG)——產(chǎn)品經(jīng)理驗(yàn)收(上線(xiàn)前驗(yàn)收極其重要)——測(cè)試回歸(主流程功能回歸,確保主流程無(wú)問(wèn)題)——發(fā)布——產(chǎn)品生產(chǎn)驗(yàn)證(發(fā)布后盡量覆蓋驗(yàn)證場(chǎng)景,確保及時(shí)發(fā)現(xiàn)問(wèn)題,能夠協(xié)調(diào)修復(fù)或者暫緩對(duì)外)——業(yè)務(wù)生產(chǎn)驗(yàn)證(業(yè)務(wù)產(chǎn)品運(yùn)營(yíng)就需求內(nèi)容進(jìn)行生產(chǎn)驗(yàn)證)
    每一步都是為了避免生產(chǎn)帶BUG上線(xiàn)。如果功能較大,發(fā)布后可進(jìn)行灰度,灰度能夠保證驗(yàn)證場(chǎng)景更加全面。最終無(wú)問(wèn)題后全部對(duì)外。如果中途出現(xiàn)需求變更,也應(yīng)該按照變更流程實(shí)施,確保變更內(nèi)容通過(guò)需求評(píng)審、案例評(píng)審。

    綜上:減少上線(xiàn)后有BUG不是產(chǎn)品經(jīng)理一個(gè)人的責(zé)任,而是整個(gè)鏈路上,所有角色功能努力的結(jié)果。因此,如果上線(xiàn)上發(fā)布后出現(xiàn)BUG,那每個(gè)人都有責(zé)任。要用集體、整體的眼光來(lái)看待這個(gè)問(wèn)題。只有大家通力合作,才能避免BUG到線(xiàn)上。

    來(lái)自江蘇 回復(fù)