追蹤工項→追出細節→追求品質

上週參加資深軟體人員的一個交流會議，在使用Redmine的時候，他們提出了一個很有趣的問題：是否有什麼方法，可以減少Redmine的信件轟炸呢？

這應該是上次那篇《為什麼不看Redmine寄給你的信？》的症候群吧。自從我找到在Redmine中怎麼使用「mention」的功能之後，我就再把這件事講述了一遍。

可提問者很貪心的繼續問了：用mention很好，可是這得開發者願意mention我，我才收得到，這樣我怕漏掉重要的訊息；可是使用Watcher功能的話，我又不想什麼風吹草動都要收到信，像是改個狀態還是改個時程的，我希望開發者真的有寫什麼”重要的”再通知我…

「哈哈，Redmine原生沒有這個功能啦，你想要的話得自己寫一個。」我雖然當場是這麼簡單回答他了，但這背後的心態我實在是覺得有需要好好思考一下。

其實軟體專案的變動性及開發細節真的很多，不管是身為專案負責人或是技術總監，雖然你也許沒辦法，也不應該做到”細微管理(Micromanagement)”，管到開發者該怎麼寫code。但對於開發者更動issue的任何一個欄位，基本上沒有什麼訊息是不重要的。我當場補充給提問者的一個實務經驗是：

時程，狀態，重要性，實作版本，分類，以至於到完成度，這些欄位我想不出有哪一項可以算是「不重要」的？哪一個項目”偷偷”的更動(你不知道的話)後，不會影響時程或產品品質的？也許開發者自己手賤在玩弄這個系統的時候，你確實會收到很多信，但一來信件的內容並沒有那麼難判斷，二來我實在也沒看到，有什麼更有效的解法(除非像處理垃圾信那樣，導入機器學習)？

若是開發者真的寫了什麼筆記(note)你還不想看，那我只能說你可以開始考慮廢棄這個系統不用了。可是為什麼身為負責人的你會不想看呢？我懂，工程師和你的角度不同，而且沒有在寫部落格的工程師，真的很難把自己在做的事情，用人話好好講清楚。

在這個自媒體當道的時代，這便是身為負責人的你一個重要的任務：請他們”講中文”，好好把自己在做的事情，寫到讓你能明白。連你都無法理解，可以想見你的老闆一定會更難理解。

會中有人提問了另一個有趣的問題：怎麼解決工程師不受控，不討論，自幹不負責的問題呢？雖然”自幹不負責”通常不是工程師故意的，但他沒有空，沒有時間可以負責，卻是實務上負責人手上最燙手的那顆xx(?)。

問題的原文是這樣的。A工程師憑著自己的直覺或需求，不使用SDK官方的實作和介面，而是根據專案規格自幹了一個。結果，現在換B工程師接手，而且要移到新專案去。高耦合的設計再加上單槍匹馬的實作品質，就足夠讓B工程師，讓新專案完全陷流沙當中，動彈不得，進退兩難。提問者覺得，若是一開始工程師會找團隊成員說明或討論他實作的方向，就有機會來得及攔截他那”宏偉”的想法；若是他做完之後大家有辦法做一次Code Review，或許能讓他做的東西品質更有保障。最後一句則是覺得，若是他有記得，或是有空維持這個工作流，這個問題就真的可以算是有解了(是不是有點”蛋蛋”的悲傷…？)。

聽完這個問題後，我才意識到一個意外的收獲。在使用Redmine追蹤每一個工項的過程中，我們這邊還真是從來沒有，也不可能會發生這種事情。我給提問者的建議是這樣的：

我知道大家很忙，時間很少，Code Review很貴。所以即便是我們自己，也不見得每次都有Code Review。若三項只能挑一項做，一定要在源頭嚴加把關，因為這裡成本最高。

這裡雖然講了兩個問題，但背後其實都指向同一個事實。懂技術的技術總監，你親自「監工」瞭解整個細節，跟看別人的code是差不多辛苦的；而不懂技術的專案負責人，你那些看不懂的細節，當然得找一個信得過的人來幫你看，然後再請他翻譯給你聽，當然也很辛苦。

所以這「同一個事實」就是，沒有什麼方法可以幫你決定跳過哪些東西不看。大家用了工項追蹤系統，卻又都不想瞭解細節，這不是前後矛盾嗎？

追蹤工項，就是在追出細節，才有品質可言，對吧？