Mr PM專欄--產品經理(Product Manager)實戰筆記

bug report，這是產品經理在做完User Accepet Test（簡稱UAT）後的產物，就是根據產品經理手上的Test Case，一樣一樣測試，然後把測到的問題整理成一份報告（格式或許是Excel檔），然後給研發部門參考，也可以當作產品經理與研發單位之間的Tracking List。

看起來很簡單的事情，不就是按照Test Case上的操作步驟，一個一個做，然後把結果不正確的找出來，就這樣而已。雖然僅僅只是如此，但是加上一些辦公室政治與人性在其中的話，那事情就會變得「不簡單」了。

在產品經理發的bug report上，bug項目太多的話，這對研發這項產品的小組，是為讓他們在部門中很「黑」的。因為常常bug list項目的多寡，都會變成部門間的交戰工具，行銷單位的經理內心可能想著：「研發單位之前都藐視我們，或是一直說XX規格做不到，甚至批評起我們的business model，態度非常差。現在bug report上bug項目這麼多，該是好好轟殺這些這些人的時候了」。

但俗話說，冤冤相報何時了，這樣雙方處在緊張的環境當中，合作起來當然也是效果打折扣。若是能夠「以德服人」，讓研發單位好像欠了產品經理一個「人情」，這樣的做法才是高招，未來PM做起事情來也才更方便。

要讓PM能寫出「以德服人」的bug report，最根本的關鍵就是，就是在上頭的老闆通常不會細細的看每一個bug是什麼，老闆只會看到一大篇的bug list，就會覺得系統好像根本不能用，進而推論研發人員沒有認真研發。以下是會造成老闆誤會的bug list格式：

• 當機
• 成功
• UI需要調整
• 與規格不同
• ...其他

然後「root cause」的意思是說，從研發人員角度看，有時候很多個根據UAT測出來的bug，其實原因都是同一個，而「root cause」就是用來填寫這個原因的欄位。

產品經理多寫「bug歸類」這個欄位有什麼好處呢？就是讓老闆看到這bug report後知道，在這麼多的bug上，不是每件事情都一樣嚴重，而是有輕重的分別，例如：UI需要調整的bug嚴重度，就比當機輕微多了。而且可以根據這些分類，上頭老闆可以很快的了解現在系統的可用度，而不會因為看到一大篇bug list，就覺得系統一無是處。但那為什麼不用「嚴重、普通、輕微」的分類呢？這是一種在報告上預防辦公室角力的方法，不要到時候老闆因為bug被歸在「輕微」的分類，就用經費不足或時間不足的理由，把它搓湯圓搓掉了。產品經理把bug分輕重，是為了解決辦公室政治，但對消費者而言，是每一個bug其實都一樣重要，一個bug沒解，產品的完整性就低，其user experience就差，造就失敗的產品。

那研發小組為何要寫「root cause」呢？一方面是逼迫研發單位不要因為趕進度，對於bug就見招拆招，頭痛醫頭，而能去真正的尋找根本原因。二方面也是讓研發小組對自己小老闆也有個交代，讓他們可以根據「root cause」解釋說：「雖然有上百個bug，可是真正的root cause只有5個，所以雖然PM列了幾百個bug，可是實際上只有5個」。這樣一來，研發小組成員績效也不會因為這份bug list而變差，甚至有可能還會被嘉許呢！

簡單的說，產品經理發的bug report，要能同時考量到對方的績效指標，也要同時考慮產品目標的完成，這樣才會是一個兼顧辦公室政治與人性的bug report嚕。