給新手團隊領導者的建議

讓優秀的開發者成為帶領其他開發者的團隊領導者，似乎是一般開發團隊常見的情況。我們挑選一個開發團隊的領導者，基本條件多半就含括了技術能力要夠好，甚至是最好。這種挑選的方式究竟好不好，實在是見人見智。

有一個著名的「彼得原理（Peter Principle）」，是從大量的組織中觀察的現象，這個現象是什麼呢？就是，在組織中，一個工作人員會因為在現有的職務上表現的夠好，因而被擢升到更上一層級的職務上，直到他晉升到能力無法勝任的職位為止。這麼一來，最後的結果，就是組織裡充滿著為數不少無法勝任其工作的人。

而從開發團隊中優秀的開發者挑選一個能力出眾的開發者，來帶領其他的開發者，時常在這「彼得原理」的第一關或是第二關就卡關了。既然是能力出眾的開發者，為什麼這麼容易在組織層級裡往上升時，就遇到了不能勝任的情況呢？我覺得，與其說是不能勝任，不如說是「水土不服」。

當我們從開發團隊中的開發者，選擇一位來帶領其他的開發者進行開發，通常是因為他的「技術性質」工作做的好。但是，一旦要帶領其他開發者進行開發，所涉及的工作類型，就不只「技術性質」的工作，而關係到「管理性質」的工作。而所謂的「管理性質」的工作，並不是像一些人腦海中那樣由上對下「管理」的刻版印象，而是牽扯到比較多溝通和協調的工作。

而一般開發者轉換角色到團隊領導者會卡關的主要原因，便是在於忽略了這些管理性質的工作，因為他還是習慣單兵作戰的模式。我自己也經歷過類似的問題，這一次，分享一些自己的經驗，供初轉換角色的開發者們參考。

意識帶領團隊開發與自己開發的差異

首先你應該要認清楚的是，一個技術卓越的開發者，就像是個武藝高強的武林高手，但是開發團隊的開發工作，像是行軍打仗，此刻你不再是戰場上在第一線衝鋒陷陣的士兵，而是領兵作戰的將領。同時，你關注的範圍，應該要從你的個人變成了整個團隊了。

通常，成為將領之路的水土不服第一步，就是將焦點放在自己的技術工作上。在有些團隊裡，即使是開發團隊的領導者也必須負責一些開發上的工作，甚至是像編寫程式碼之類的工作，因為團隊的規模不大，也很扁平，所以大家都必須負擔一些編寫程式碼的工作，即使是團隊的領導者也不例外。因此，除了技術性質的工作之外，還得再負擔一些管理性質的工作。但是，因為他本身就是團隊中技術能力比較好的，所以，往往也就負責一些特別重要、關鍵的部份。

大多數的人都是這樣的，當自己身陷在自己負責的工作時，往往就比較不會顧及別人的情況，尤其當時程緊迫的時候。當團隊領導者對於開發團隊整個的開發情況，處於見樹（自己）不見林（整個團隊）時，就沒有辦法充份處理好管理的工作。

須接受將工作分派出去的做法

由技術能力較好者來擔任這個工作的情況，常常也造成，團隊的領導者捨不得將工作分派出去，因為會有一個將工作攬在自己身上的慣性。常常他們心理上會是這麼想的：「如果我親自來做這個工作的話，就可以做得更好（或是更快）了」。所以，會有許多的工作集中在他們的身上，最後使得他們往往成為團隊開發時的瓶頸所在。整體的開發進度幾乎都被單一個人的進度所主控著，這個人延遲了，整個開發進度就延遲了。這種情況，搭配「見樹不見林」一起發生，就會更加惡化，因為他自己身陷苦海時，也就更顧不得其他人的情況了。

所以說，其實要先克服的，就是這種非自己不可的心理狀態。有一件工作，如果自己覺得可以做到 90 分，就必須接受團隊中其他人來做，即使他只能做到 70 分。只有這樣，你才可以讓更多人一起參與，發揮相加的力量。畢竟一個人再怎麼厲害，能支配的時間還是有限，能發揮的產能也是有限，這種工作模式，才可以隨著規模提升，而讓生產力也隨著提升。

留多一點心力掌握團隊的狀況

接著，如果可以的話，盡量讓自己扮演輔助性的技術角色，而不要負責太吃重的技術工作，否則，很容易讓自己在自顧不暇的情況下，忽略了應該要看到整個團隊的情況。

那麼，在不負責吃重的技術性角色時，團隊的領導者應該做些那些工作？他應該負責主要的溝通協調工作，像是溝通、協調、確認每個成員之間相接的介面，確認每個人都知道確切知道自己的產出應該是什麼，以及確認每個人都明確知道每個工作應該被完成的時間。

他也應該觀察每個人的開發情況，察看是否有人遇到了障礙，是否需要他介入協助排除。他也應該基於自己的經驗，提醒每個成員的工作是否有什麼需要特別留意的陷阱，可以提前知道如何避免踩中地雷，或是如何進行可以把工作做得更有效率。

有些團隊領導者把工作交付出去之後，就不再聞問，直到期限到了之後，才去詢問結果。如果在這個過程中，執行者遇到了困難，使得進度停滯不前，或是實作上走錯了方向，都沒有辦法在中間有人協助他提前解決，或是修正他的方向，就只有等他發生延遲時，或是實作被驗證出了問題時，才知道出錯。

所以說，站在一個制高點上去觀察、了解每個成員的情況很重要。舉例來說，我知道有些團隊領導者，會去查看 Git（目前普遍使用的版本控制系統）上成員的 commit 內容。透過閱讀這些commit的內容，他就可以知道每個成員的進度，因為commit的項目可以反映出進度。每完成一個項目就會有一個commit項目；每修正一個問題，也會有一個commt項目。透過這種方式，就可以即時的了解每個成員的進展，不需要等待定期的進度會議才能夠知道。另一方面，透過版本控制系統，還可以知道每個成員做了什麼更動，可以知道他的實作方式好或不好，甚至也可以知道他的程式碼符不符合規範、……等等。

所以說，開發團隊的管理，有一項主要的工作，就是持續監看成員情況，並且協助他們修正的過程。而這也是時常被忽略的。之所以技術領導者需要負擔一些技術性的工作，就是希望他們把心力放在管理性的工作上，因為這樣才能照料到更多的人，此時，他才是「將」而不再只是「兵」。

使開發成員能大展長才，並避免其人的短處影響工作進行

最後一個建議就是，大多數的人都有優點，也有缺點，應該要試著知道每個成員的優點和缺點，盡量讓他發揮優點而避開他的缺點，或是進行輔助，使得他的缺點不至於產生太多負面效應。

舉例來說，有些人很自律，可以自動自發推展工作進度。但是有些人卻需要被 push ，才能夠有效率地完成工作，但這樣的人並非技能上有問題，只是需要一些輔助。身為團隊領導者，有時現實的情況是，你沒辦法太隨意選擇一群各方面特質都很好的人，因為每個人都有優點、有缺點，所以，你需要了解每個人的特質，才能夠妥善讓每個人發揮。

對新手的團隊領導者來說，從技術性為主要的工作性質，轉換成需要涉及管理工作的性質，往往是一大挑戰，而其中難適應的其實是心態和習慣的建立而已。本文在此提供一些建議供大家參考。