「這個報表頁面點進去整個空白，孝宇，這個bug目前狀況處理的怎樣。」
早會一開始，客服夥伴先照例報告昨天的 bug 追蹤狀況。這種時候大家通常只是靜靜聽著，等待指派的負責人回報處理方式。
「應該是欄位格式問題，我昨天有補一段 callback，現在功能應該沒問題了。」孝宇回報bug處理進度與方法。
話才剛講完，副總便插話進來：「是哪支檔案？ACC（主責）是誰？」
孝宇停了一下：「痾... 是 `ReportParser.ts`這隻檔案，ACC是Ken。」
副總點點頭，沒再追問，像什麼都沒發生一樣轉頭繼續進行會議流程。
對沒參與專案細節的人來說，這段對話看似平常，但團隊裡的工程師都知道——副總那句「是哪支檔案？」其實從來不是單純想了解技術細節。
他不需要打開什麼表格，也不會當場說些什麼，但大家心裡都明白，他在默默記著：這個檔案的ACC是誰，誰的名字跟這段出問題的功能綁在一起。
一段短短的回答、一個名字，可能就成了他衡量一個人工作表現的依據。那不是什麼明講的 KPI，但它確實存在——藏在他不動聲色的關注裡。
Bug 是誰修的、是誰動了誰的檔案、這段錯誤「應該」是誰要管，副總從來不說破，卻會在你領到績效獎金和年終的時候就知道了。
ACC 主責管理
副總對「工程師程式碼是否寫得好」有一套自豪的管理哲學。他設計出 ACC（主責）制度，將專案內的檔案“盡量”依據功能模組分配給特定工程師，再搭配 SonarQube 報表，根據 bug 數、重複率等指標來「量化」每個人寫程式的表現。
這樣的設計可以在 Excel 得到漂亮的報表裡，誰負責了哪些檔案這些檔案的程式品質如何，在他最愛的Excel裡面一目瞭然，但忽略了一個本質問題：軟體開發是高度協作的行為，並不合適以單檔責任制度去管理。
功能常常會跨越多個檔案、甚至多個模組。產品的維護與迭代也經過了多個人的邏輯。Bug 的產生通常是系統性的錯誤，而非單一檔案或模組所造成的結果。在這種情況下，用「這是誰主責的檔案」來判斷誰該負責，只會讓真正該處理的問題被模糊掉。而且找出是誰出錯「找戰犯」這種行為只會讓團隊的士氣下降。
造成什麼樣的問題
這種制度雖然看似量化了每個工程師寫程式的程度指標，但也會帶來很多問題。甚至會讓整個團隊文化變糟，引響士氣
- 檔案分配的是否公平？
因為不是每個檔案都會經常在修改或是比較有多的bug，有些模組的檔案本來使用率就比較低，各個檔案的複雜度也不一定一樣。這樣分配一定會有不公平的現象。
- Bug出現的時候要找主責還是...？
通常bug出現應該是會找比較熟悉模組或是最近修改檔案的人處理，但必較熟悉該模組的人不一定就是ACC負責人，這樣到底要找ACC主責還是找比較熟悉的工程師呢？
- 後端程式主責分配
後端的程式碼通常會有一個檔案包含很多不一樣的服務功能，程式碼行數可能會多達數千行。加上專案已經很舊了，這樣要怎麼分配主責？
有沒有更好的做法？
如果真心希望提升團隊的技術能力與合作，管理的目標不應該是一昧的只看SonarQube上面跑出來的數據指標。只會看報表數據但不管實際情況，這就是管理階層常常陷入的迷思。
假設管理者的目的真的是想知道團隊的表現好不好，那其實有很多更務實、更能看出「工程實力」的方式，而不是把責任硬將每個人分配到檔案上面、或是用 SonarQube 的報表去當績效分數。
以下是比較好的管理方法：
1. 用功能模組或業務邏輯來分工，而不是單檔責任
模組的邏輯往往比單檔案更具意義。與其把每一支檔案應歸給人，不如根據系統架構與業務邏輯分配 domain owner，讓工程師能深入理解整體設計，並對模組品質負責。
2. 關心在「解決問題的過程」，而不是哪一支檔案有問題
「是哪支檔案出問題？ACC是誰啊？」，這種找戰犯的行為對於產品維護迭代完全沒有幫助。更重要的是看團隊遇到 bug 或技術問題時，是怎麼討論、怎麼找解法、怎麼把系統恢復正常的。 這些過程才真正反映一個工程師的實力與態度。
3. 使用工具輔助討論，而不是主導評價
SonarQube 是個好工具，但它的指標應用來輔助大家發現問題、改善產品品質，不應該拿來評分評量每個人的產出的品質。畢竟程式檔案並不一定從頭都是這個人寫出來的。如果以這樣算在這個人身上是不是太不公平。
4. 建立公開透明的評分機制，而不是看報表打分數
看報表產出的指標，就真的可以代表這個員工的寫程式的功力好壞嗎？更何況你確定你設計的報表真的代表這個工程師嗎？加上各項評分指標並未公開，這樣和黑箱作業有什麼不一樣？
