前幾天看到美國前國務卿鮑爾(Colin Powell)說的一句話：

領導就是解決問題。當屬下不再告訴你他們的問題，就是你不再領導他們的時候了！(Leadership is solving problems. The day soldiers stop bringing you their problems is the day you have stopped leading them.)

我不知道你感覺如何，但當我看到這句話，包括再度寫下來的當下，我是全身起雞皮疙瘩，就像第一次聽到蘇珊大嬸唱歌時一樣！而且，這句話讓我回想起一段往事：

場景回到2007年的紐約，當時我和幾位同事的工作之一，是維護一個專案管理資訊系統，姑且稱它系統A好了。系統A已經有多年的歷史，很多功能已經不能滿足需求，所以後來又開發出一個新系統B，用來取代系統A。這兩個系統的生命是有重疊的，也就是新系統(B)上線幾個月之後，確定資料轉換沒問題，使用者也都能適應，舊系統(A)才能順利除役。這樣的規劃，等於有幾個月的時間，我們必須同時維護兩個系統，但基於成本考量，也沒辦法增加人手(就算可以加人，等新人幾個月上手之後，Loading也差不多降下來了)，所以也只能靠大家加班或是盡量加快速度來度過這幾個月。

這段平行作業進行了幾個星期後，果然出現了延誤的狀況，於是我們的Team Lead便召開一個會議，試圖解決這個問題。

會議中，Team Lead和團隊成員對於時間的估計，產生了一些歧見。舉例來說，我們的維護工作有一項是"更新專案進度"，這項工作大致上是先取得其他單位的專案報告，找出其中和進度有關的資訊(通常是一些標準表格，但也有例外)，然後把資訊輸入系統，並執行一些計算的動作，確認無誤後才正式寫入系統之中。這看起來像是個標準流程，但實際上有很多干擾，可能是單位的專案報告遲交，抑或數據出現矛盾和錯誤，這些都得花時間溝通澄清。另外常發生的還有"插件"，客戶突然需要某項資料，我們就得停下手邊的維護工作，先滿足緊急的需求，可能過了一兩天才又回來繼續原來的工作。考量這些現象，團隊估計的數字是：每天約可以處理5個專案的更新。

不過Team Lead對這樣的效率不太滿意，他覺得系統A的維護工作大家都很熟悉了，每天能處理的專案數應該遠超過5個，為了證明他的論點，他決定用"科學的方法"來分析我們的工時，他將上述提到的工作，更進一步地拆解成好幾個"動作"，同時填上他認為合理的時間，例如：

這當中其實漏掉了不少事情，比方說，報告沒收到時的跟催，或是與其他單位間進行的資料確認，但這些事情Team Lead認為難以估計，只要將上述的時間加總後再乘上一個調整係數就好。

所以根據上面的計算，每個專案僅需30分鐘便可以完成，一天以8小時來計，團隊每天應該要完成16個專案，就算考量溝通耗時造成的折減，打個五折好了，也必須完成8個專案，而不是團隊預估的5個。

但團隊也要話要說，每天5個專案是基於過去一年來經驗值，雖然沒有精密的計算，但考量溝通和插件這類事件發生的頻率和過往經驗，每天更新5個專案是團隊每位成員都認可的預估。

最後，整個會議並沒有針對問題來討論如何改善，反倒是對時程預估的方法何者正確爭論不休，最後其實是不歡而散，不了了之。

好吧，故事說到這裡，不知道你有甚麼看法？以下僅是我個人主觀的意見：一個是時程估計的問題，一個是Team Lead的角色問題。

首先，這樣的時程計算有假設上的錯誤。因為團隊性質的工作(如軟體開發，共同創作等)，成員間的溝通其實佔據非常多的時間，根據人月神話這本書以及其引用的研究指出，一般軟體工程師真正用於寫程式的時間僅有50%上下，另外的50%除了思考，閱讀資訊，還有團隊的溝通與不同工作轉換的時間(比方說中途插件)，估計軟體人員的產能必須考量這些因素才行。而我們Team Lead的計算則類似於泰勒式的思維。泰勒(Frederick Winslow Taylor)被尊稱為科學管理之父，他研究工廠工人每個細微的動作，並量測每個動作花費的時間，並利用這些數據來進行效率方面的研究。

不過和軟體開發不同的是，工廠工人多數的工作是不需要溝通的，產能直接與工人個體的效率相關。但寫軟體必須整合不同人概念，必須大量溝通，和把煤炭鏟進熔爐畢竟是不同類型的工作。因此，有經驗者的主觀判斷，有時候反而更有參考的價值。

其次，這位Team Lead花了那麼多工夫，做了那麼多計算，只為了證明團隊的效率不彰，即使他辯贏了，也未必對事情有幫助。以我當時的立場，我很希望Team Lead這個角色可以帶領團隊，找出問題的癥結，看有沒有辦法提升效率，一起度過難關。或許他可以幫團隊開道，減少不必要的溝通，或是幫團隊建立起一個防護罩，避免太多"插件"干擾。

這件事情最後還是解決了，我們團隊自己討論出一個方式(沒邀請Team Lead，我承認這在職場倫理上是有瑕疵的，但當時客戶直接來找我們談，沒有透過他，這部分就不言而喻了)。我們跟客戶提議，將一組很耗時間維護卻沒甚麼人使用的資料取消掉，經過認可後，工作量降低，整個團隊逐漸回歸到正軌，但這位Team Lead在這件事情上等於被架空了，似乎呼應了包威爾說的那句話。

鮑爾的另一句名言：凌亂的真相好過圓滑的謊言

不管你是部長、課長、組長還是家長，我覺得這兩句話真是太對了，花工夫證明屬下是錯，還不如幫忙解決問題。