當專案一再出現相同錯誤時

本篇文章是投稿至 ZDNet 的文章，已由 ZDNet 以〈領導力 決定專案成敗〉與〈團隊關係 左右專案發展〉兩篇文章刊出。文章原稿未經 ZDNet 編輯，加上同人在文章刊出後修改原稿，其內容與刊登的文章有些差異。

繼「新官上任三把火」之後，馬政府團隊又在國慶大典發生意外狀況。位置安排出問題、加上安檢嚴格，引發部分參加大典的民眾不滿。例如資深藝人和僑胞發生搶位置狀況，還有一對位置被佔走的僑胞夫婦，居然還被工作人員趕出場外，真是又委屈又生氣。

看到這則新聞，筆者關心的並不是主辦單位碰到這些意外狀況該怎麼辦，而是好奇為什麼座位安排的問題會重覆發生？其實像座位安排並不是什麼困難的問題，不需要動用複雜的技術，只要用簡單的 Excel 試算表就不會有太大的問題。

如此看來，座位重覆的問題不太可能是技術的問題，筆者看到相同的錯誤一再發生，我會懷疑問題不是出在技術上，而是因為管理的關係，使得團隊一再出現相同樣的行為模式造成錯誤。

可能是因為領導者的領導能力不足，使得團隊成員的能力處處受限而無法施展。如果真是如此，那麼與其討論技術細節，還不如討論該如何領導讓團隊充分發揮能力。因為，就算今天我們知道如何可以解決座位安排出現錯誤的問題，領導能力不足，明天團隊還是很有可能在別的地方出現錯誤，造成其它的意外狀況發生。

筆者相信不管是那一種專案，管理上的領導能力不足都會造成相同的錯誤一再發生。就像筆者在軟體專案中所觀察到的情況一樣，專案經理的領導能力不足，使得團隊成員把精力浪費在沒有意義的事情上，以致於對專案目標的達成並無太大的助益。

當然我們並不能否認，團隊成員的能力出現了問題，或是他們不夠盡力，也可能會出現同樣的現象。不過，根據筆者多年軟體專案開發的經驗顯示，團隊成員能力不足或是其心態有問題的情況並不多見，多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時，專案經理應該先思考是不是自己的領導能力出了問題。

依法，或是依人？

筆者從觀察發現，很多團隊領導者認為，只要讓團隊遵循良好的制度、方法，就可以提昇團隊的工作效率與成員素質。因而在團隊制度化與標準化作業流程的導入上，付出相當大的心力，並要求團隊成員用「專業」的方法來解決問題。

表面上，上述提到的標準化與制度化的「專業」看起來似乎不錯，可以讓重複、瑣碎或不重要的工作予以簡化或剔除以增進工作的效率。但就如同筆者在〈新官上任三把火〉這篇文章中所提到的，制度化除了會讓工作更加艱難、人們不願冒險以獲取高利潤之外，更嚴重的還會讓團隊成員依賴制度化而使得思考僵化，降低了運用思考創意解決問題的可能性。

為什麼會這樣呢？如同筆者一再所強調的，專案本身具有臨時性與特殊性的特質，必須視專案實際環境來調整開發方法與流程，也就是我們通常找不到「放諸四海皆準」的開發方法來一體適用所有的專案，用來事先難以預料的各種問題。

其實「依法不依人」並不是不可行，而是受限於專案現實環境與限制，根本不允許團隊規劃出適用於各種專案情況的最佳開發方法，就算團隊真能規劃出這樣的方法，專案可能會更需要能力更強的團隊來執行這樣的方法。而且，用組織制度來取代成員的思考與創造力，那更是促成團隊「自廢武功」的領導作為，而最後只會把事情弄得更加難以收拾。

必要多樣性法則

因此，「制度是死的，人是活的」專案的問題通常很複雜，團隊領導者不應該用僵化的制度來限制團隊成員的思考與創意，而是應該將重點放在人身上，而方法、制度、與規範只是站在支援與輔助的角色，而不能用來限制團隊成員的行為，如此團隊成員的思考與創意才能透過流程方法的幫助而獲得到加成的效果。

如果團隊領導者想要做到依人，讓團隊成員充分發揮專長，那麼他必須能夠做到充分授權；讓他們感到自己是團隊的一份子，才會願意主動提出建言，以作為團隊領導者決策的參考。不過實際上，這對團隊領導者而言，這卻是個艱鉅的任務。

因為對於複雜專案而言，團隊通常會具有多樣性的特質，要讓背景、專長、以及文化有顯著差異的成員採取一致的步調，這對專案經理來說其實是相當大的挑戰。但如果團隊領導者沒辦法整合各種不同的意見，將會引發團隊衝突而衝擊專案績效。

正如同《專案領導》這本書中提到的觀念，James P. Lewis提到用「必要多樣性法則」來解釋專案經理需要具備足夠的彈性與靈活度才能掌控團隊。所謂的「必要多樣性法則」是指在任何人類或機械系統中，彈性最大的份子會控制整個系統。換句話說，領導者對團隊所做的行為，必須比整體行為的多樣性還要更靈活、更有彈性，否則他將難以掌控團隊。

但實際上，領導者很難具備足夠的靈活度與彈性來掌控團隊的行為，因為每個人都會受限於根深柢固的行為模式而難以改變。所以，最好的做法就是降低團隊的多樣性，這可藉由制定規則與法令來規範團隊成員的行為而達到目的。

不過，對於不認同團隊規範的成員而言，再多的規則也是英雄無用武之地；所謂「上有政策，下有對策」他們必然會想盡辦法來規避規範。因此，James 認為降低團隊多樣性應該要制定完善的專案計劃，找出團隊成員的共同目標，然後必須考量團隊成員的個人因素，並且邀請負責執行計劃的人參與計劃的制定，才能訂出大家都能認同的專案計劃。

團隊領導者的力量

不過，雖然專案計劃是專案管理的「根本大法」，其中的願景與目標可以讓團隊的多樣性自然而然地降低，以減輕領導專案的困難度。然而，如果團隊領導者卻無法有效地影響團隊成員為專案努力貢獻心力，仍然還是很難有效地帶領團隊達到專案目標。

尤其是像軟體專案這種充滿不確定性的複雜專案而言，常會面臨企業環境變化的衝擊，加上問題領域與各種資訊技術領域整合常會產生新問題，當「計劃總是趕不上變化」時，團隊領導者除了專案計劃的「法」之外，還必須懂得如何讓團隊成員心甘情願地為專案付出心力的領導「術」，這樣才能勝任專案領導的任務。

換句話說，團隊領導者必須擁有影響團隊成員改變的力量，但如何才能得到這樣的力量呢？或許有些人會認為團隊領導者的力量來自於專案開發組織賦予權力與資源，但實際上，權力或資源並不見得能夠賦予足以領導團隊的力量。

筆者的一位老師曾經說過：「強將手下無弱兵，但強將手底下，也不會有強將」有能力的人並不懼怕領導者的權威，他不會因為恐懼而聽從領導者的指揮；至於能力不足的專案成員，雖然他會依賴或屈從領導者的指令行事，但唯唯諾諾聽命行事的結果，很難能夠期待他們能夠發揮創造力與獨立思考的能力。

關於領導者的力量，溫伯格在《領導的技術》中提到「力量是一種關係」的觀點，他認為力量奠基於團隊領導者與團隊成員之間的關係，權力、技術或是專業是否能為團隊領導者產生力量，完全視團隊成員認為這些事物對他們是否重要而定。

由此可知，所謂專案的範疇、時間、成本、品質、風險等硬技術，不見得能夠為團隊領導者產生力量，如果團隊領導者想要提昇領導能力，應該增進與團隊成員的關係。所以他應該在溝通、協調、衝突管理等軟技術上多下功夫，才能讓自己的領導能力有所提昇。

筆者常在實際的專案開發的工作中，看到一些在過去表現不凡的團隊領導者，卻在另一個組織高層予以托負重任的專案中失敗了。就像有一位專案領導者，曾經在某一個甲專案中為公司立下大功，深受客戶好評並得到公司的獎勵。但他卻在一個公司傾全力挹注資源的乙專案中失敗了，使得陣前換將讓別人來接收他的爛攤子。

很多人會覺得很奇怪，為什麼這位專案領導者不能接續過去在其它專案的優異表現，在新的專案中，領導團隊邁向成功呢？問題就出在許多專案領導者都以為過去的成功模式可以確保專案成功，但卻忽略了他們熟悉的成功模式不見得會滿足新專案的成功條件。

組織所賦予的權力或資源，或是領導者過去所知的經驗、專業、或是技術不見得會為領導者產生足以影響團隊的力量，除非團隊成員認同這些東西對他們的重要性。

如果專案經理不去關心團隊成員、也就不會瞭解他們需要什麼，自然也就難以激勵屬下貢獻所長，以達成專案目標。相信實際從事軟體開發工作的人都能理解，工程師不求名、不求利，只求爽。想要讓他們戮力求取專案成功，考驗著專案經理的領導能力。

有一位專案計劃主持人曾經沾沾自喜地告訴我，他認為某個專案能夠成功，是因為他鼓勵大家犧牲假期加班的結果。但其它瞭解專案狀況的多數團隊成員都知道，專案能夠成功是因為另外一位專案經理以柔軟身段，進行溝通與協調的結果。他並不會要求團隊成員依規定辦事，而是理解並接納團隊成員，才能激勵大家共同面對難關而解決問題。

因此，力量的決定關鍵在領導者掌握與團隊成員的關係的緊密性，而非技術或專業能力、權力的大小或掌握資源的多寡。換句話說，領導者要具備柔軟的身段與協調能力才能把團隊帶到專案成功的境地。

於是我們可以說，領導者要有效的領導團隊，必須先贏得團隊成員信任，才會讓他們願意為專案的共同目標而努力。再加上適時適地的激勵團隊成員，以激發團隊的熱情，以及增進團隊成員榮辱與共的參與感。讓每一個團隊成員都能為專案成功而努力，同時也讓他們的能力，能夠從做中學的過程中得到啟發與成長。