編輯導語：作為一名產品經理，在產品上線之前對Bug的測試是至關重要的，輕則影響某一環(huán)節(jié)，嚴重的將造成不可逆的流失。因此，產品經理應該如何減少上線后的Bug？作者總結了幾個方法以及如何復盤歸檔，分享給你。

一、bug帶來的影響

• 某游戲因人物屬性設置出現bug，導致外掛橫行，戰(zhàn)力體系崩潰，最終核心用戶流失；
• 某電商平臺的優(yōu)惠券功能出現bug，一夜之間造成千萬元級別的損失；
• 某超大體量的APP最新版本被設置成了3天后過期，但實際上應用市場上已無可更新的版本，差點造成3天后數千萬用戶無法使用該APP；
• …

版本上線時，我們最擔心的一件事情就是出現重大bug，特別對于已擁有大量活躍用戶的產品來說，一旦新版本出現嚴重的問題，可能造成難以挽回的損失。

出現問題后，公司對事故的起因進行調查和追責時，無論因誰而起，我們身為產品的負責人都會難辭其咎，成為主要的責任人或之一，我們將之調侃為背鍋。

如果只是偶爾背一次還好，大部分人能夠頂得住壓力，但如果總是容易出現各種問題，這個時候可能就需要我們反思根本問題出現在哪，其中是否有我們自身的原因？我們在工作中有什么方法可以有效降低bug發(fā)生的概率？

剛進入職場的時候，我們應該都經歷過背鍋這個過程，只是有的人領悟能力強，很快就會找到方法，早早跨過這道坎，而有的人經常做背鍋俠，要經歷一兩年才能找到解決的方法。

慘就慘在，我就屬于后面那種，有1年多的時間里，我經常會遇到版本上線后出現的各類問題，不過，幸運的是我從過去的工作中，總結出了幾點方法，之后就很少出現上線后出現重大的bug，職場之路也更加順利，這里想把方法記錄一下同時也分享出來，幫助更多的人找到這扇門的鑰匙。

二、bug的避免方法

常見的bug大概可以分為3種類型：需求設計的缺陷、功能缺陷、性能缺陷，我們分別來尋找應對方法：

1. 需求設計的缺陷

如果因為我們對需求的調研不充分、理解不深，又或者是設計功能的時候思考不全面，從而導致做出來的邏輯出現漏洞，上線后出現問題，那么這類缺陷的直接責任人就是產品經理。

出現了此情況，說明產品經理沒有做好最基本的本職工作，給團隊其他成員帶來了額外的工作量，這種情況是我們最應該避免和反思的。

產品經理每增加一個功能，都意味著需要投入相應的開發(fā)、測試人員進去。如果功能開發(fā)完成后發(fā)現需求存在缺陷，再回過頭來修改，那么至少需要1個開發(fā)去返工。

這對于項目的資源是一種損耗，同時也會引來團隊其他成員的不滿，這種不滿進而會導致其他人對產品經理信任度的降低，當產品經理失去了團隊成員的信任時，往后的工作將會舉步維艱。

如何避免？

（1）提高需求設計的質量

高質量的需求輸出物是規(guī)避bug的基本保障，做到這點需要有2個要素：

一方面，我們要具備設計出所需功能的能力，這個可以通過競品調研或大量的項目經驗，去積累產品設計的案例庫，體驗的多了，做到這一點就不會有太大問題。

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

不過實際工作中經常因為項目的時間有限，很難花大量的時間在原型和文檔上面，這種情況下，可以把主要的時間花在核心功能邏輯的思考和描述上面，核心的部分思考越全面、描述越細致越那么需求的質量就會越高。

（2）重視需求調研和確認

前面提到了需求設計的質量，還有比這更為重要的，就是需求的調研和確認。若這一步沒做好，則可能造成后面的努力都付之一炬，因為所走的方向錯了，最終做出來的功能就會無法滿足用戶需求，最終造成需求設計上的重大缺陷。

因此，前期需要進行充分的調研，明白用戶真實的需求是什么。對于B端的需求來說，通常能夠接觸到需求方，那么做需求的過程中有不確定的點，可以及時與其進行確認，并邀請其參與到需求評審中來，確認能滿足需求后再進入開發(fā)階段。

2. 功能缺陷

還有一類最常見的bug，是開發(fā)過程中，因為技術人員自身的原因而產生了bug，我們在這里定義為“功能缺陷”。

這類問題出現后有的產品人會說，這不是產品經理導致的，與我沒關系，既然是開發(fā)造成的問題就由開發(fā)人員去承擔。我見到過很多產品人都在工作中有上面這種觀念，我個人不是很認同這種思維。

的確，這個觀念聽起來很合理，誰引起的就由誰去承擔，但，在問題出現之前我們真的已經盡好自己的職責了嗎？

要知道，雪崩發(fā)生之后沒有一片雪花是無辜的，我們是一個團隊，項目上線后出現了技術bug，會有主要責任人，但通常不是某一個人的責任，而是多個人共同造成的結果，如果密切協(xié)作，這類bug大多數情況下都能避免。

如何避免？
除了測試人員要盡到自己的崗位職責外，我們產品其實也能起到很大的作用，只需把控好一個關鍵節(jié)點——就是上線前做好測試環(huán)境的驗收。

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

3. 性能缺陷

這類bug是最難察覺的，通常情況下測試人員不會特意去測試性能，因為大多數產品的功能并不需要太高的性能，但對于使用頻率高或有實時性要求的功能來說，就必須要考慮性能了。

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

如何避免？
產品經理在設計功能時，需要根據實際的業(yè)務場景去判斷這個功能對性能的要求是否高，假如出現高并發(fā)、高延遲后對產品的影響有多大。

如果判斷出該功能對性能有要求，且性能缺陷對產品的使用會產生很大的影響，那么就需要在需求文檔中將性能需求寫進去，注明對響應的實時性、功能的并發(fā)量有什么要求。

三、bug的復盤歸檔

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

萬一還是出現了嚴重的bug，怎么辦呢？

每次出現問題后，我們都應該對bug進行復盤：分析bug出現的原因→將問題進行歸類→給出解決方案→進行存檔

歸類后有助于我們舉一反三，未來做其他類似的功能時，就能避免類似的問題再次發(fā)生了。

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

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

存檔的作用在于防遺忘和自查，每次記錄bug時，如果發(fā)現這類bug已經出現過1次了，那么這個時候就能引起反思，以保障下次不會再出這類問題。

四、結語

bug不僅會給產品本身造成影響，也會帶來額外的工作量給我們增添煩惱，比解決問題更重要的是能夠預測出問題的發(fā)生，并提前進行規(guī)避，希望通過以上的幾點方法能讓我們都成為一名“bug終結者”。

如果每次從自己手上的做出來的功能都很少出現問題，那么leader其實會覺察到這是一個靠譜的人，特別在產品初期，將有助于我們實現職場的進階。

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

題圖來自unsplash，基于CC0協(xié)議