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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容