產品經理該怎麼發bug report

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格式:

項目 敘述 測試人 發現日期 bug修正負責人 修正日期 備註

筆者將這個表格修正一下,增加兩個欄位。

項目 bug歸類 敘述 測試人 發現日期 bug修正負責人 修正日期 root cause 備註

大家很明顯可以看到,這兩個表格最大的差異點在於增加了「bug歸類」和「root cause」兩個欄位。「bug歸類」是產品經理寫,而「root cause」是歸研發人員撰寫。

而「bug歸類」的分類法,可以依照產品經理自己的定義,可以分成如:

  • 當機
  • 成功
  • 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嚕。

留言