產品經理該不該對Bug負責？

從1945年的那個小飛蛾出現開始，計算機工作從業者，就沒有人喜歡Bug這個單詞。

但我們似乎每天都能聽到幾聲「這裡有一個Bug！」。每一次產品開發，每一次版本迭代的過程，也是新一代Bug繁衍的過程。

Bug的出現無法避免，想到Bug就想到開發工程師更是自然不過的。無論如何，開發工程師親手寫下一字一行的代碼，是他們創造了產品，也寫出了Bug。沒有完美的程序，開發寫出的Bug，開發會來坦然修復。

但，並不是所有的鍋都得程序員來背！

假設這樣一個場景，請大家千萬要對號入座

一個功能需要與服務端數據交換，但產品的功能邏輯里只考慮了常規的網路狀況，結果用戶在瞬時的弱網路環境下使用導致程序崩潰……

當Bug出現後，第一個跳出來喊的，就是每天不知道在幹嘛的運營同學，「怎麼又出Bug了，一秒鐘損失一百萬用戶！」心裡也會埋怨「這些開發怎麼總是有Bug，我們都測了一次又一次了。」

然後產品經理來主持大局：「那個XXX，你是不是這個地方調用錯了？」

態度，態度很重要，這個產品經理竟然假裝這個Bug和自己一點責任沒有？這可是對需求和用戶使用場景考慮不周全引起的問題。

按照往常：低調的開發工程師就會定位Bug，解決問題了。可是，這一次，我們的開發同學在經歷了每月4次的產品經理甩鍋後，終於爆發了。

本來可以10分鐘解決的Bug，兩個人用來吵了一天架。

一些涉及UI規範的問題，也不該由開發同學承擔責任

「產品需求里允許用自定義文字大、中、小三種規格，但在實際設計過程中UI設計師只給出了一套文字設計樣式，然後由程序自動實現放大、縮小字體。然後測試在驗證這個case的時候報了一個bug：在大號字體下，文字超出顯示區域，導致……

其實，這些問題，產品經理如果能夠給出更好的需求描述，Bug本是可以避免。當然，一個團隊不是所有的責任對錯都能分的一清二楚，要凝聚在一起，最重要的是解決問題。

與其將重點放在「這是誰的責任」？還不如一起齊心協力，快速解決問題，才能讓我們的產品跑的更快。

所以，對於同一個項目組的每一位同學，想要更快的解決一個Bug，團隊協作最重要。