凌亂的真相 vs. 圓滑的謊言

凌亂的真相 vs. 圓滑的謊言

前幾天看到美國前國務卿鮑爾(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個,為了證明他的論點,他決定用"科學的方法"來分析我們的工時,他將上述提到的工作,更進一步地拆解成好幾個"動作",同時填上他認為合理的時間,例如:

a.閱讀專案報告 5分鐘
b.將錯誤記錄下來 5分鐘
c.進入程式介面 2分鐘
d.輸入進度資料 5分鐘
e.核對資料 8分鐘
f.認列資料於系統中 5分鐘
小計 30分鐘/專案

這當中其實漏掉了不少事情,比方說,報告沒收到時的跟催,或是與其他單位間進行的資料確認,但這些事情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在這件事情上等於被架空了,似乎呼應了包威爾說的那句話。

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

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

覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
姚詩豪 Bryan Yao

成大土木所與美國西北大學專案管理雙碩士、識博公司共同創辦人、普錸資訊資深副總、國際專案管理師(PMP)、甲骨文與微軟認證顧問。曾任紐約市環保署顧問、MWH Global, Inc.專案控制經理,參與國內外多項大型專案並擔任百大企業之諮詢顧問。擅長以詼諧的筆觸以及理性的思維來探討生活中的大小事。文章常轉載於《商周》、《天下》、《經理人》等媒體。與張國洋合著《三年後你的工作還在嗎?》以及《沒了名片,你還剩下什麼?》。

Bryan G+ ICON

8 則讀友回應

  1. Frank Chou 2017-03-29 11:47:24 第 8 則

    It sounds so sad but entirely true.

  2. Anna 2017-03-28 20:24:43 第 7 則

    真是當頭棒喝的一篇文章,因為每當面對下屬的很多提問免不了會覺得很疲勞轟炸,覺得為什麼你們沒有自己的想法⋯⋯但換個思維來看,主管勝出的不就是佈局與解決問題的能力嗎?

  3. Lily. 2010-05-30 20:24:50 第 6 則

    真的寫得很好...給人很多反思的空間... 主管與其強行把自己的想法跟推斷加在部屬身上,還不如好好聽整個團隊遇到的問題,然後幫忙解決...當然很多時候主管的見解狠獨到,可是不同的高度看到的問題與其深度也不同,聆聽並接受ugly truth也許才能解決根本的問題! 謝謝分享! :)

  4. nobody. 2010-05-15 08:48:08 第 5 則

    謝謝分享

  5. 康康. 2010-05-05 22:46:26 第 4 則

    好文章