在業界中或多或少都會常聽到以下類似內容

• 當有 Bug 發生的時候，跑來指責 RD 為什麼功能沒修好，一直有問題勒？...
• 當有 Bug 發生的時候，跑來究責 PM 為什麼產品會變成這樣勒？…
• 當有 Bug 發生的時候，跑來究責 QA 為什麼這個東西沒測到勒？…

若有公司有出現這類的聲音，請去制止他們的行為吧

不妨思考一下

• 難道 Bug 的產生是只有 RD 弄出來的？
• 難道 Bug 的產生是只有 PM 弄出來的？
• 難道 Bug 的產生是只有 QA 弄出來的？

開發流程大多都是會經歷 軟體開發生命週期(Software Development Life-Cycle, SDLC)

這些流程步驟中會有一推人參與討論及實作，但為什麼出事情後，要找一個替死鬼去背鍋才甘心？

所以真的要究責的話，難道我們要一個一個抓出來鞭屍嗎XDD

我的觀點

究責沒意義，即使真的有戰犯了，劈頭罵一頓了

然後...Bug 就會自動好了？類似的 Bug 就不會再出現了？

甚至這種究責文化，只會讓大家更畏懼面對問題，可能會呈現出：「我很早之前就發現問題了，但不敢說...」

當主管問：「這問題你提早發現了，但為什麼不提早說勒？？」

我：

我相信這種結果應該都不是大家想要的吧！XDD

但當問題出現後，到底該怎麼解決比較適當呢？

當一個開發流程的周期結束時，我們都是需要一個復盤會議，也可以稱為 Retrospective meeting

會議內容我們需有以下

1. 哪些開發作法是好的，應該要繼續維持下去。
   e.g. 單元測試做的很足夠、有導入持續整合、有持續做 pair programming 等
2. 有哪些與開發流程有關的地方沒有做好需要改善的。
   e.g. 測試硬體設備不夠、開發初期需求文件沒確認仔細、開發時程評估錯誤、開發環境出現異常導致時程delay …
3. 擬定改善計畫（action plan）。
   根據上方的第 2 點的議題延伸去思考解決的方式
4. 清楚的目標，讓團隊擁有共識。
5. 需要有個強而有力的會議主持人，能夠明確 掌控會議節奏及目標，通常這角色通常是 專案經理 或 專案負責人。

心態上也需要調整

1. 對事不對人，就事論事
2. 秉持著開放的態度
3. 虛心接受/虛心求教
4. 團隊間互相信任
5. 讓復盤會議當作是日常

部分參考來源

• 团队高效复盘：让今天的峰值成为明天的常量

看到上方參考來源文章中有很好的一句話，希望共勉之。

如果失敗能夠讓你找到原因和措施，那這樣的失敗可以包容。
如果成功卻不知道為什麼成功，那這個成功不可複制也就沒有意義。