Intuit公司前執行長比爾．坎貝爾曾經為了達成目標，當員工不達理想標準時便會情緒失控罵人，讓員工不敢問問題也讓工作環境備感壓在職涯之初是個減數者，指揮人們做東做西，後來他努力改變自己，成為乘數者，提出讓別人思考的困難問題。

記者／鄧天心

編按：本書《影響力領導》作者莉茲．韋斯曼Liz Wiseman在書中提到了兩種領導人物，一種是「乘數者」為工作環境帶來正向循環，另一種是「減數者」讓底下的員工備感壓力甚至底下人員處於高流動的狀態。Intuit公司前執行長比爾．坎貝爾曾經為了達成目標，當員工不達理想標準時便會情緒失控罵人，讓員工不敢問問題也讓工作環境備感壓力，當他面對到人員高流失的問題後，才自從他反省自己的管理風格後，成功留住人才，也博得共同創辦人的肯定。

（本文選自 時報出版 的《影響力領導》部分內容，完整內容詳見此

Intuit公司前執行長比爾．坎貝爾，30多年前是在一所長春藤大學擔任美式足球教練。身為教練，他聰明、積極、強硬。當他被招募到這家消費科技公司後，他的運作方式大致相同。

他年輕時在柯達（Kodak）公司擔任行銷主管，若看到銷售負責人的事業計畫寫得不好，他會接手改寫。而在當年蘋果電腦公司講究細節的約翰．史庫利（John Scully）手下做事時，比爾變成終極微管理者，他埋頭於事業的所有細節，指導每項決策與行動。

他說：「我把每個人都逼瘋了。我才是真正的減數者。相信我，我做出所有決定，逼迫每個人。我真的很壞。」

比爾回想起一次最差勁的時候。在一場重要員工會議上，他的管理團隊成員問了一個簡單問題。比爾對這個搞不清楚狀況的主管很惱火，轉身對著他發飆（夾雜許多髒話）：「那是我聽過最愚蠢的問題。」房間裡一片死寂。比爾繼續進行會議，不再被其他惱人問題打斷。接下來幾週，他注意到大家都不再問他問題。他粉碎了團隊的好奇心。

在蘋果子公司克拉麗斯（Claris）擔任執行長時，他持續強硬地領導。一名親近的女同事來找他坦白說：「比爾，我們來這裡是因為我們喜歡在上一家公司為你做事，但是你故態復萌，你操控每個人，做出所有決策。」

比爾明白她說得沒錯。這不是唯一接近叛變的時刻，創立另一家公司的兩個月後，他的一名管理團隊成員來找他說：「我是代表整個團隊來這裡。如果你不讓我們做事，我們就會後悔來這裡。我們不想離開，但我們必須要能做我們的工作。」以球賽來說，比爾明白他總是在第四次進攻、只剩一碼之際指手畫腳。他危害他的公司，損及這個具備優異成員的團隊，而他不願意失去他們。

兩名大膽同事的勸告正是比爾所需要的一劑自我意識。他明白他需要修正路線，而他做到了。他首先增加聆聽，減少說話，開始欣賞同事的所知所學。當他領悟到他對管理團隊造成的貶損效應，便開始注意組織裡的其他減數者，向他們提出勸告。

他尤其記得有一個人總想證明自己是屋子裡最聰明的人，比爾跟他坐下來詳談：「我不在乎你本人有多聰明。要是你再這樣下去，你會讓組織崩塌。你很棒，可是你不能像這樣在這裡工作。」

久而久之，比爾成為了更優秀的領袖。這是一項穩定的轉變，出於他想要保全他的團隊以及實現他招募的人才價值而自然發生。等到比爾成為Intuit公司的執行長，領導該公司在2000年突破十億美元營收大關，他已挖掘出自己內在的乘數者。

即便比爾已自執行長職位退休，他仍是Intuit公司董事會成員，亦花時間指導初階的新創公司。他擔任導師角色─曾親身經歷，犯過錯誤並從錯誤中學習的領導人。

他與創投合夥人密切合作，確保各自的角色分明：創投合夥人投入資源，比爾培養人才。他輔助執行長與主要領導人培養必備技能，讓公司能夠拓展市場潛力。

比爾做了什麼來培育執行長？他主要是打造他們成為乘數者。他教授他自己所學到的：「只要是學得會的東西，就能夠教給別人。」他協助天資聰穎（通常年輕）的執行長學習善用組織裡的才智。他教導的執行長後來建立了一些最知名的科技公司：Amazon、Netscape、PayPal、Google等等。

2010年，比爾協助一名執行長將他的主管會議由乏味的職能報告會議，轉變成重要業務議題的嚴格辯論。以前，這些會議遵循可預期的格式：桌邊的每個人進行報告，讓同事知道進度以及他們職能內的議題。

比爾參加了許多場這類會議，看到優異的腦力未被充分利用，他表示：「這些主管會議並不會有成果，你需要讓人們投入你最重要的議題。」比爾要求這名執行長準備五項公司關鍵議題。執行長再預先將議題清單寄給團隊，要求每個人徹底思考每個議題，準備好數據及意見。

這名執行長於下次開會時，便要求管理團隊摘下職務頭銜，以公司人員自居。然後他提出第一個議題：我們應該留在服務領域，抑或讓給合作夥伴？一名高階主管指出他們應該留在這個領域的理由，另一人持相反立場。每個團隊成員輪流表述自己的觀點，執行長細心聆聽，做出決定，接著列出後續影響與行動。一名團隊成員站出來說：「我理解了，我會著手進行。」執行長接著進行下一個議題，展開下一場辯論。

比爾回想起他擔任一些矽谷明星執行長教練的經驗：「我可以幫助他們透過不同角度看事情。我將他們趕出舒適圈，對他們提出艱難問題。」比爾在職涯之初是個減數者，指揮人們做東做西，後來他努力改變自己，成為乘數者，提出讓別人思考的困難問題。不過，他的領導旅程並未結束於此。坎貝爾不只是個乘數者；他成為乘數者的乘數者，培養出能夠汲取與倍增才能的其他強大領導人。比爾在漫長抗癌後，病逝於2016年4月，生前可謂做出巨大影響。他在矽谷最大的傳承，是一些重量級高階主管的背後導師。

Intuit的共同創辦人史考特．庫克（Scott Cook）表示，沒有坎貝爾，該公司不會有今日的成就。「我無法想到有其他人對矽谷領導人與文化造成如此重要深遠的影響，」庫克說，「他將我們變得更好了。」

（本文選自 時報出版 的《影響力領導》部分內容，完整內容詳見此

這篇文章 「逼迫每個人 我真的很壞」Intuit前執行長自白：不再高壓管理 才留得住人才 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

乘數型領導人打造一個強烈的環境，讓卓越的想法與工作得以茁壯。暴君則是營造一個緊張的環境，壓迫人們的想法與能力。

記者／鄧天心

編按：觀察你的公司是壓迫的領導人，還是強力的領導人能最能為公司帶來績效？本書《影響力領導》作者莉茲．韋斯曼Liz Wiseman提到公司最常見了兩種主管，暴君型主管為工作環境帶來壓力，相對於另外一種解放者主管，卻製造了讓員工自主向上努力的環境。

（本文選自 時報出版 的《影響力領導》部分內容，完整內容詳見此

乘數型領導人打造一個強烈的環境，讓卓越的想法與工作得以茁壯。暴君則是營造一個緊張的環境，壓迫人們的想法與能力。

珍娜．希利是一家大型電信公司負責戶外作業的資深副總，即便身高僅161公分，她有一種俯視部屬的姿態。珍娜是嚴肅的領導人，也是經驗老練的聰明經理人，但她是一名不折不扣的暴君。

她的同僚告訴我們：「她製造一種歇斯底里的環境。她在四周製造恐懼，恫嚇與霸凌別人，直到得償所願。她的主要領導方式是：『你還能再為我做些什麼？』」她底下的一名主管表示：「她有點像是電影《穿著Prada的惡魔》裡那位無情的米蘭達。」我秒懂。

珍娜不但是惡霸，還是隨機發作型，根本無從預測什麼會導致她發作，誰會是下一個受害者。有個人回想道：「你覺得自己會是下個倒楣蛋。在她身邊，我倍感壓力，惴惴不安，如履薄冰。」她的同事開玩笑說：「應該要設立一個珍娜的風暴預警系統，大家想要知道何時該抱頭鼠竄、尋找掩護。」

珍娜在丹佛舉行的季度管理會議正是這種時刻。珍娜召集跨職能團隊，檢討美國市場的業務狀態。這是典型的業務檢討，每個職能小組輪流簡報其「業務狀態」。前面幾場簡報之後，資訊科技團隊的主管丹尼爾開始他的簡報，向其他主管展示戶外服務人員是如何使用他的團隊為他們打造的IT工具。

他接著問道：「就這些數據來看，我不確定服務團隊是否善用了現有的工具？」根據珍娜接下來的反應，你會以為他說的是她的團隊又笨又懶。她突然發飆：「你在胡說八道些什麼？」然後當著大家的面訓斥他，爭吵越來越激烈，令人不安地持續了十分鐘。等到有人終於開口說中場休息時間已經到了，大家立刻奪門而出，但丹尼爾留了下來，試圖對抗珍娜，堅持他的立場。大家都離開以後，他們吵到不可開交，大吼大叫。

會議室裡火氣沖天，外頭走廊則是冷若冰霜。每個人都暗自為丹尼爾挺身力抗霸凌加油，但接著要進行簡報的人則害怕到僵硬，你可以感受到那股緊繃感。早已做完簡報的幸運兒祝倒楣的同事好運；還沒做簡報的人開始慌亂地修改，刪除任何可能進一步惹惱暴怒領導人的爭議性內容。他們撐過了會議，但實際上沒什麼實質內容，也沒有達到任何成果。

珍娜的組織雖有小小的進展，但一直未能達成營收與服務品質的目標。最後，她不知分寸，霸凌他們的一家協力廠商，結果立刻被逐出組織。珍娜到了另一家公司擔任營運長，撐了兩週就遭到貶職，六個月後，她便被掃地出門了。

人們對珍娜這種領導人退避三舍，這類暴君封鎖了才智的流動，極少得到人們的最大努力。他們所到之處，都發現人們沒有發揮自己真正的實力。難怪他們訴諸恫嚇，心想這可以讓他們得到想要的─卓越的想法與工作成果。可是，恫嚇與恐懼鮮少產生卓越的成果。

我們來看另一名高階銷售與服務領導人。

羅伯．英斯林（Robert Enslin）是全球軟體巨擘思愛普（SAP）的全球客戶營運總裁。來自南非的他，說話帶著平靜的自信。羅伯備受推崇，被讚許為一名公正且穩定的銷售領導人，他能壯大組織、締造成果。

羅伯與工作上的所有人都像是同輩般打成一片，他底下的領導者如此形容他：「他很擅長讓你解除武裝。他是個普通人，和我們一樣。即使你的職等比他低了三級，他仍會想要知道你的想法。」因此，人們在他身邊更為透明，他們不覺得一定要跟他講他想聽的話。平易近人的態度令羅伯四周的人感到安心，那種安全感讓他得以一帆風順地經營這個大型的銷售組織。

數年前，羅伯受命接管思愛普的日本分公司，以解決一些特定的銷售業績問題。當他與新的日本領導團隊舉行第一次預測會議，他看出預測流程一塌糊塗。羅伯沒有扮演獨裁者、批評他們的失敗、指示他的解決方案，而是自我克制、開始學習。他協助他們理解現有流程的限制與新流程的優點，然後他借取他們對日本商業的知識，詢問他們：「我們如何更上一層樓？」他創造空間讓團隊嘗試新方法，自行解決問題。他陪著他們研究問題數月之久，直到他們可以執行正確預測業績的預測流程。

羅伯以平易近人與鎮定自若而聞名，但這些特質在他於二○○八年接掌北美的業務時受到考驗，因為全球經濟正在崩潰之中。由於支出遭到凍結，大型資本採購被擱置，各地的高階主管逐漸變得恐慌。當你走過思愛普鄰近費城的新鎮廣場（Newtown Square）辦公室大廳，你能夠感受到那股緊繃感。推開玻璃門走進高階主管會議室，氣氛甚至更加緊張。

在會議室裡，羅伯召集了他的新管理團隊，擘畫這種新經濟環境下的銷售策略。團隊的每個人都知道羅伯一直在約見高階主管，因此壓力沉重。他們來開會時已準備面對他們必須承擔的痛苦─畢竟，這是銷售部門。然而，即便是在這種混亂之中，羅伯仍然平靜穩定。他的團隊不禁猜想他是不是沒看到新聞，還是沒參加高層會議。會議一開始，他便道出經濟問題的嚴重性，但建議他們先不管這個。他要求團隊專注於他們可以控制的問題，接著他問說：「我們現在可以做些什麼來做出市場區隔？」他們以自己的專業及可控制的領域為主，著手提出價值主張，以幫助他們在動盪氛圍當中定位他們的解決方案。經過討論後，他問道：「我們如何協助人們使用我們的產品，好讓他們獲得最高的經濟價值？」團隊再度共同面對這個問題，並擬定了一項計畫。

他的團隊表示：「我們知道他必定承受來自更高層的壓力，可是他沒有製造焦慮給我們。他保持平靜，從不驚慌失措。他不會拿馬鞭驅策他的部屬。」另一位思愛普的高層表示：「在危機時刻，他提出更多問題─迫使你認真思索局勢的那種問題。你感受到他有看不見的手在導引決策。」

羅伯的冷靜不代表軟弱，他就像其他成功的銷售主管那樣強力且專注。差別在於他的焦點。他的高層同僚接著說：「他對問題強硬，但對人溫和。你相信他會挺你，因此當你不可避免地犯錯，他會先幫你解決，而不是鞭笞你。我們感受到同舟共濟，意思是壓力施加在整個大部門，而不是某個人承擔龐大壓力。」他的領導團隊成員表示：「羅伯不是將焦點放在他自己，而是你，以及讓你把工作做到最好。」

羅伯的穩重，加上開放式環境，為極可能陷入危機的組織提供了理智與安定。

暴君製造緊張的環境，充滿壓力與焦慮。反過來說，像羅伯那樣的解放者會製造強烈的環境，需要專心、勤勉與能量。在這種環境中，人們被鼓勵自主思考，並認為達成最佳工作成果是他們義不容辭的責任。

減數者製造充滿壓力的環境，因為他們不讓人們控制自己的表現。他們像個暴君，將他們的意願強加在組織之上，導致人們萎縮退卻。在暴君的陰影下，人們會避免自己太過突出。你可以想像在政治獨裁者的統治下，人們是如何生活的。暴君得到人們的縮減版想法，因為人們只會提出最安全的想法與平庸的工作成果。

暴君製造壓力導致人們退縮，解放者則創造空間讓人們挺身而出。暴君在立場之間搖擺，造成組織的動盪；解放者則建立穩定性，產生向前的動能。

（本文選自 時報出版 的《影響力領導》部分內容，完整內容詳見此

這篇文章 強力領導人不等於暴君！跟SAP全球客戶營運總裁學「團隊重整術」 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

本書《遠距團隊》作者曾與來自五十三個國家和世界各地組織的領導者合作，幫助有需要的企業內部打造溝通無礙合作無間的成功團隊，他發現新手主管或是空降主管，可能很難改變團隊原本的模式，因此他分享了主管們可以問問自己的問題，如何打造你想要的團隊文化，而不是安於現狀？即便是固執頑梗的團隊也能重新擁有向心力！

記者／鄧天心

編按：本書《遠距團隊》作者曾與來自五十三個國家和世界各地組織的領導者合作，幫助有需要的企業內部打造溝通無礙合作無間的成功團隊，他發現新手主管或是空降主管，可能很難改變團隊原本的模式，因此他分享了主管們可以問問自己的問題，如何打造你想要的團隊文化，而不是安於現狀？即便是固執頑梗的團隊也能重新擁有向心力！

（本文選自 時報出版 的《遠距團隊》部分內容，完整內容詳見此

愛麗絲的上一支團隊非常成功，每個人都對他們積極、充滿活力的文化以及大家共同努力實現團隊目標的方式讚不絕口。她被提拔到一個新的部門，新的任務充滿挑戰。她接手的團隊大多是資深員工，以固執己見、不與公司其他部門合作而聞名，但她並不知道之所以如此的原因。此外，他們的上一任經理離開時也很沮喪，因為團隊中的大多數人似乎不僅拒絕接受公司指定的目標，而且還總是無法達成。愛麗絲對她理想中的團隊有清晰的想法，但這似乎與她的現實情況天差地遠。

在上一章中，我們探討了如何設計一個團隊，並為從零開始打造理想團隊奠定了基礎。但是，我們大多數人都會遇到與愛麗絲類似的另一種情況，你可能會發現自己面對的是一個已經建立起來的團隊。就像一句老諺語所說的：「船已經在水裡了，你現在就得把它修好。」（You need to fix the boat while it’s in the water.）

從零開始打造你所設想的團隊，與重新設計和改變現有團隊運作方式之間的區別並非「沒錯，但是」，而是「沒錯，而且」。沒錯，無論團隊是否已經存在，所有用於打造團隊的設計要素都適用。而且，還有一些複雜的因素。例如，已經在進行工作的人員有自己的工作習慣，但現在正在改變中的工作時間和地點，可能會引發他們的抗拒。

雖然你會讓團隊參與這個過程，但在現階段，你可能正在試著理清自己的想法。這意味著我們需要在已經分享的流程中增加一個步驟，即新的第三步。現在的步驟是這樣的：

• 從整體方向開始思考—打造你的夢幻設計
• 實際應用設計時的考量
• 檢視你可能無法與團隊討論的情況和限制因素
• 一起決定最終的團隊設計

在構思完你的團隊之後，你需要審視目前的情況。團隊也許可以協助你進行部分分析工作，但作為領導者，有些工作仍可能需要由你來完成。在最終確定你的設計之前，請考慮以下事項：

• 目前的團隊成員有誰？
• 現有的團隊設計和架構是什麼樣的？
• 還有哪些其他的限制因素？
• 目前的情況和設計會對三個C（溝通、合作和團結）造成什麼影響？
• 目前的團隊成員有誰？

團隊已經完成了新設計方案的初稿，但有時候你會需要為角色指派人選。當團隊已經存在時，就會出現另一個問題：人選都是已經指定的。無論你考量的變動有多大，都必須檢視團隊中現有的成員。

• 表現最優秀的人是誰？
• 經驗最豐富的人是誰？
• 誰對正在討論的變動似乎更加投入？
• 誰是影響者和意見領袖？
• 最適合任何新角色或流程的可能是誰？

這就是實際情況。我們特意讓你在最初的步驟中排除這種思考過程，因為我們不希望你—不管是有意或無意地—圍繞著特定人物進行設計，例如位於愛達荷州博伊西（Boise）的鮑勃或倫敦的露易絲。當你開始為職位和工作描述加上名字時，可能會發現有人一定會準備抵制變動，同時另一職務的某人卻對新流程予以支持。找出可能的阻力或擁護者，會讓計畫的實施變得更容易。

員工不僅只是工作描述而已；他們是團隊運作的一部分。在理想情況下，他們是領導者和出色的隊友。有時，他們只是表現平平的普通人，對團隊沒有任何正面或負面的實際影響。他們也許會積極地推動工作，也可能成為阻礙。處理這些現實問題可能會影響你的設計，但不要基於個人情況對設計進行過度調整。相反地，請你認清自己可能需要提供額外的輔導，以幫助人們適應新的設計和新的方法，讓整個計畫能夠順利運作。

• 現有成員是否能讓我們實現我們的設計？
• 我們能否藉由輔導和培訓來實現目標，或者我們是否有需要用新技能或新資訊來填補的差距？
• 我們最有經驗的團隊成員，是否具備以設計建議的新方式來執行任務的知識與技能？
• 在波士頓（或邦加羅爾）的貝卡會接受改變還是引發衝突？
• 團隊成員對工作時間和地點的感受，會形成變更的助力還是阻礙？
• 較缺乏經驗的員工是否準備好以新的方式邁出步伐？
• 我們如何利用團隊中的佼佼者來塑造新的期望行為，並影響其他團隊成員？

領導者必須單獨或與一組顧問一起思考其中的許多問題，而不是用即時通訊或電子郵件與團隊分享。這是領導者的責任。認真思考這些問題，將有助於你為團隊改進如何接受並執行你的設計草稿的方式。

重要的是要認識到，你不應該試圖獨自實行設計。每個團隊都有能夠影響他人的成員，無論是出於職位、資歷、個性、關係或是表現，這些意見領袖／變革推動者對你的執行都很重要—尤其是當你與遠距團隊合作時。確保你協助這些意見領袖成為正面的影響者，而不是將團隊引導至負面或憤世嫉俗的態度。

領導者需要思考工作中的人際動力學。我們很容易就會想使用「團隊合作者」或是「不良影響者」等等的標籤，但請記得這些標籤不管是正面或負面，它們通常都帶有偏見，可能對解決問題並沒有幫助。

我們需要的是客觀的觀察。請忘記他們現在、看起來或過去是怎樣的員工；重要的是他們實際上做了什麼。記住，我們不可能準確地評估動機，因為我們的想法往往會被自己的感覺和態度所左右。真正重要的是行為—尤其是未來的行為。以下是一些我們討論到的例子：

• 人們會做哪些事？哪些行為會受到團隊成員的優先重視？以績效評估和社會氛圍來說，哪些行為會得到獎勵？
• 會議中有哪些已經發生或正在發生的事，會促使團隊滿足於敷衍了事的工作或選擇做出良好的決策？
• 領導者的哪些行為（無論正面與否）會影響團隊的其他成員？
• 組織中的其他人做了哪些事，因而對團隊作業形成了支持或阻礙？舉例來說，如果有人很早就接到交派的工作，但卻任由它在其他人的辦公桌上擱置的話，很顯然時間對每個人來說都不是優先事項。
• 你對這些問題的回答如何影響你希望實行的設計？

假使你的設計確立的是百分之八十五的工作可以有效透過遠端完成，但組織已經決定員工需要花百分之五十的時間在辦公室工作，你就會面臨不一致的情況。如果你的組織會以獎金或其他公開的表揚來獎勵個人努力，但你的設計著重的卻是團隊成功，你該如何從中協調這兩種方法呢？

根據你在組織結構中的位置，你可能有能力，也可能覺得自己沒有能力影響重大議題。舉個例子，假設你是巴黎或伊利諾州皮歐立亞（Peoria）的中階管理人員，你目前可能什麼都做不了，但不要放棄希望。儘管我們對你們大文化的了解並不深入，但如果你有耐心並持之以恆，仍然可以推動改變。事實上，你在團隊設計方面所付出的努力和工作品質，將對組織的其他成員產生強大的影響。可能沒有其他人像你一樣，對工作進行過如此廣泛的分析。當你提出自己的疑慮或要求例外處理時，你可能會對所獲得的回應感到驚訝。

改變始於微小之處，這些小小的勝利可以打造出可觀的成功。你和你的團隊有什麼理由，不快點開始滾動雪球呢？

如果你的設計遇到了障礙，要實事求是，但不要聽天由命。向上報告你團隊的工作，看看在現有原則和既定規範的範圍內，你還能有多大的自由度來實現你想要的設計。如果你無法獲得所需的變更或特許，也要以開放的方式告知你的團隊。

你的初步設計已經將溝通、合作和團結這三大支柱的目標納入考量了。從這三個層面來看，現有的設計是什麼樣子的？在思考現狀的過程中，你可能會發現其中的一到三個層面還有很大的差距。假設你希望在你的設計中建立強而有力的關係，但目前這種關係還很薄弱或根本不存在，那麼你就知道你在這方面還有努力的空間。如果你的會議—無論是面對面、虛擬會議或混合形式的會議—已經相對有效，那麼你就不需要在這部分花費太多精力。有意識地思考目前的狀態與未來的設計在這三個層面的差距，將有助於你決定團隊需要優先把最多的時間花在哪裡。

一旦考慮到目前的現實情況會對設計產生怎樣的影響之後，就需要將其納入最終設計中。即使你不得不因此對初稿進行調整、順延或徹底地修改，也要記住當初設想願景的工作仍然很重要，不要失去你和團隊的那幅景象。也許在直接達成最終願景之前，你只需要再踏出過渡的一步而已。不要忘記你的最終目標。

根據你在本章中所做的工作，向團隊提出你的分析和問題。你可能會驚訝於他們可能有多願意投入，你也可能會從他們那裡獲得一些珍貴的見解。繼續讓他們參與，是成功重新設計現有團隊的關鍵。

與新團隊一起為全新的工作實行新設計，是一項涉及變革的艱鉅任務；但為現有設計重新構思和在水中打造船隻，則需要更深層的變革管理和領導技能。你已經讓成員參與了未來的設計，但你也必須考慮目前的狀態。請記住，儘管現有的習慣、例行公事和角色很難更動，但它們還是可以改變的。

（本文選自 時報出版 的《遠距團隊》部分內容，完整內容詳見此

這篇文章 給苦手主管打造團隊心法：找到員工優勢 用「3C法則」重新設計團隊架構 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

「我們學了很多方法，但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話，儘管大家都能看見問題，也嘗試導入各種方法試圖解決；但很多時候別說進步，有時甚至還會走回頭路，筆者剛好透過這個主題整理團隊過往遇到的問題；不過解決方案是否有效、會不會衍生新的問題，就看之後的連載了?

文／林鼎淵

「我們學了很多方法，但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話，儘管大家都能看見問題，也嘗試導入各種方法試圖解決；但很多時候別說進步，有時甚至還會走回頭路，筆者剛好透過這個主題整理團隊過往遇到的問題；不過解決方案是否有效、會不會衍生新的問題，就看之後的連載了?

ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言

為了讓每個角色各司其職，在溝通需求時，都是由專案經理跟客戶溝通，得到結論後再跟開發人員說明。

儘管看起來很合理，但在實務上容易遇到以下問題：

1. 名詞定義：同一個名詞，大家的定義都不一樣；這導致 3 者在溝通上雞同鴨講，彼此以為對方懂了，但根本在說不一樣的東西。
2. 專案經理與開發人員都不具備專案的背景知識：如果碰上大型專案，在開發團隊沒有相關背景知識的狀態下，光是架構的設計就很容易出問題；又因為沒有相關背景，所以根本沒有共同語言。
3. 規格書不明確：開發人員按照規格書來開發，但如果規格書很模糊，工程師在開發時會浪費很多時間在額外的溝通。（最悲慘的狀況是工程師放棄溝通，選擇按照直覺來開發）

上面的問題，想嘗試透過以下方法解決：

1. 專案經理與開發人員以「英文」來溝通欄位：資料庫都是英文欄位，如果規格書上的欄位都以中文表達，就不能怪工程師在開發上直接選擇「感覺」意思最接近的欄位。
2. 由專案經理建立一套「中英文名詞定義對照表」：內部可以用英文律定欄位，但跟客戶溝通時，大多情況還是使用中文；所以需要建立一份對照表，避免彼此的誤解。
3. 需求規格參數明確：對客戶來說好像差不多，但對工程師來說，差一個欄位就好似差了一個宇宙。

二、Scrum 淪為形式

我們期待導入「Agile(敏捷)」開發後，可以提升團隊的生產力、向心力，但實際上會遇到以下問題：

1. 只在意自己要講什麼：跑 Scrum 的原意是希望大家瞭解彼此工作的進度，透過資訊透明讓專案更加順利；但很多時候我們只在意自己今天要講什麼，這種狀況在 Scrum Master 為固定人選時更為明顯。
2. 規格不明確導致需求時常變更：在 Sprint Plan 時，我們會先估點來計算每個人工作需要的時間；但在開發階段若發現規格有問題，專案經理就要再跟客戶溝通，這一來一往與程式調整的時間，將會完全破壞這個 Sprint 預計要完成的項目。
3. 安排額外的任務：如果臨時安排不在這個 Sprint 的任務給工程師，又沒有明確告知任務優先度，當這種狀況頻繁發生時，Scrum 就變成單純的個人報告，工作內容逐漸與 Sprint Plan 脫鉤。

上面的問題，想嘗試透過以下方法解決：

1. 讓每個人輪流當 Scrum Master：在這個位置上，就算不願意，你還是得知道每個人的進度、卡住的問題、要做的事。
2. 指派任務前，充分確認客戶需求：如果在商談時就定下明確的需求規格，那工程師就有開發的依據，發現邏輯問題時也能第一時間提出，不至於自由發揮到一半才發現問題。
3. 盡量不要讓突發狀況影響現在的 Sprint Plan：工程師也是人，臨時安排的工作勢必會影響到現在的專案，如果可以，突發的狀況盡量安排到下個 Sprint。

三、專案到最後時刻才發現一堆 Bug

我們花 20% 的時間完成 80% 的功能，卻在最後 20% 的功能上花了 80% 的時間。

如果問題發生不只一次，那肯定要想辦法解決；通常會有這樣的狀況是因為：

1. 架構規劃不良：專案啟動後，一開始大家都是摸著石頭過河，無法確定自己現在的方向是否正確；往往到後期，才發現當初的規劃有某些後遺症。
2. 前期進度按照時程走很安心：因為前期每個 Check point 都很準時，所以產生接下來也會繼續準時的心理預期。
3. 想要一次交卷：有時我們會想等作品完成到某個程度後再給客戶看，但…有時客戶看過後會發現許多與他們理念不合的設計。
4. 新舊系統功能不吻合：就算功能都是 Copy＆Paste，但程式底層的運作邏輯往往不同，部分欄位可能也存在誤會；你以為執行得很順利，殊不知早已偏離方向。

上面的問題，想嘗試透過以下方法解決：

1. 別管架構，先交出 MVP：我們規劃了太多功能，卻沒有一個 MVP，在一切都不明朗的狀態下，能規劃出好架構根本是靠運氣；與其在前期完成那麼多功能，還不如先交一個勉強能動的 MVP，以此向客戶確認是否符合需求。
2. 在一開始規劃時，就把容錯時程拉長：過往的經驗告訴我，意外通常在最後一刻才發生；因為在後期，我們才有辦法用整體的思維去看專案。（如果團隊有經驗非常豐富的架構師，那有機會規避這些問題，筆者目前還不具備這個實力）
3. 開發階段頻繁更新系統：讓客戶隨時體驗最新的功能，如果與預想不合也可以盡快作出調整；避免工程師要砍一堆程式，做無意義的重工。
4. 如果要改寫舊系統，就需要對方提供可以驗證的資訊：通常舊系統程式的參考價值不高，我們只能從操作流程來推估資料間的關聯性，但這些「都是靠想像」的，如果客戶沒有提供足夠的舊系統操作案例給工程師來驗證，就很可能開發出無法與舊系統銜接的系統。

四、Tech Lead 沒辦法發揮應有的作用

我們期待 Tech Lead 可以照顧到整個團隊的技術，但如果開發時程太趕，在 Tech Lead 也投入大量時間在開發時，會衍生以下問題：

1. Code Review 淪為形式：連自己的任務都快做不完了，Code Review 時頂多看一下 Coding Style，沒辦法從整體的架構去判斷他的演算法、邏輯是否合適。
2. 專案程式碼品質下降：因為 Code Review 不確實，很多功能只是為了解決當下的問題，這種時候很容易創造出一堆耦合性高的程式。
3. 沒辦法顧及所有人的進度：如果專案經理與 Tech Lead 配合不夠默契，那很容易發生 Tech Lead 埋頭開發，沒有從整體的視角來看專案的進度。

上面的問題，想嘗試透過以下方法解決：

1. 分配給 Tech Lead 的開發任務，不要超過他 60% 的工作時間：如果把 Tech Lead 當單純的 Developer 來使用，那團隊程式碼的品質就無法保證；為了避免日後要花更多的時間解決後遺症，建議多給 Tech Lead 一些靈活運用的時間。
2. 專案經理與 Tech Lead 訊息流暢：就算有專案管理系統輔助，但每個任務進度的細節、時程還是專案經理最清楚；如果能在發現進度 Delay 前期就做適當的調整與釐清，也許不會走到時程緊繃這一步。
3. 律定專案管理系統操作方式：開發人員 Commit 的內容也需要附註在 Ticket 上面（盡量白話），這樣更方便專案經理掌握實際進度；若該 Ticket 有相依性（後端完成後交付給前端），那開發人員也要將相關的 API doc 附在上面。

五、團隊失去成長動能

我們期待團隊裡的每個人都能夠隨著專案持續成長，但在管理出現問題時，團隊會慢慢轉變為 80/20 法則的模式，也就是 20% 的人完成了 80% 的任務，下面是筆者個人推估的原因：

1. 到 Deadline 時，總有人能幫忙解決問題：如果團隊成員發現沒做完的東西，在接近 Deadline 時就會有其他人來拯救，那很可能就會養成依賴性，喪失自己解決問題的能力。
2. 獎懲機制不夠透明：如果大家發現拼死拼活的結果跟躺平耍廢一樣，那我們為什麼不躺平？
3. 連坐制度：Deadline 就壓在那裡，你幫了，他無法成長；你不幫，專案就爆掉，自己也跟著倒霉，這種狀況到底要幫還是不幫？

上面的問題，想嘗試透過以下方法解決：

1. 幫忙時只給方向：可以提供一些關鍵字、網頁、參考資料、過去的程式碼，但不要直接解決問題。
2. 如果必須親自解決問題，先確認對方已經發揮所有潛能：儘管我們都希望給方向就能解決問題，但每個人的背景知識不同，如果給方向還是無法解決；在親自解決問題前，要先請對方說出自己過去所做出的研究，確保他已經盡力，任務難度真的超過了他的能力範圍。
3. 不影響健康的壓力：如果發現成員的能力有提升的空間，那或許可以提醒他，適度犧牲下班後與放假的時間持續鑽研是必須的，唯有做足功課，在上班時才能更快地趕上大家的腳步。
4. 律定獎懲機制：我們希望每個人都有想成長的自覺，但如果有必要，賞罰機制還是要存在的。

六、不是每個成員都按照流程走

我們秉持互信的原則來合作，就算有些人沒按照流程走，只要不出包，也可以睜一隻眼閉一隻眼；但如果這些行為產出的結果不符預期，甚至導致團隊損失，那勢必要做出改善。

這邊就以程式碼 Commit＆Push 舉例，原則上我們期待每位開發人員一天至少 Push 一版程式，且裡面 Commit 都有詳細紀錄更動的部分。

會有這個要求是因為專案是「協作」的，如果有人憋了一個禮拜才 Push 一大包，會衍生以下問題：

1. Tech Lead 很難 Code Review：因為內容太多、太雜，釐清功能所需的時間反而更多。
2. 如果架構有問題，改善成本太高：如果在 Code Review 時才發現程式的結構問題，那又需要浪費很多時間改寫。
3. 如果把所有更新的內容塞到一個 Commit 裡面，很難對應功能與程式：因為程式往往散落在多個檔案，如果 Commit 內容太多，就很難知道彼此的對應關係。
4. 萬一發生狀況，接手的人會崩潰：如果做完的功能沒有 Push 上去，接手的人等於要重寫。

上面的問題，想嘗試透過以下方法解決：

1. 向開發人員說明定時 Commit＆Push 的重要性：開發人員可能不知道自己這麼做會影響到其他人，需要講清楚問題嚴重性。
2. 如果任務太複雜，盡量做功能上的切分：有時被分配到的任務涉及面太廣，導致遲遲不敢 Push 上去；面對這種情況，可以依據開發的進度來 Commit＆Push，反正有 Git 這種程式碼版控系統，不會影響到主分支。

七、血淚小結

1. 問題是長期沒改善積累而成的，想解決肯定會遇到不少阻力。
2. 只有被攤在陽光下的問題，才有機會被解決。
3. 許多問題互為因果，如果不解決，問題會像病毒般不斷變種。
4. 每個人都在適應自己的角色，專案經理不知道需求規格怎麼寫才能讓開發人員理解，開發人員不清楚遇到問題時要如何解決，Tech Lead 不確定怎麼帶人才是最合適的。
5. 規則律定出來就要執行，如果沒有執行；那其他乖乖遵守規則的人，也遲早會學壞。

這篇文章 團隊在系統開發上遇到了哪些問題 — 工程師血淚史 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。