2008年10月2日 星期四

當程式人「晉升」至管理階級

轉貼自iThome online一文

身為軟體團隊管理者,最核心的工作,便是了解團隊成員,關心他們的工作動態甚至是情緒。

從程式人成為管理階級,似乎是許多程式人對職場生涯的重要規畫。許多人認為程式人這一行是「吃青春飯」,只適合年輕體力充沛的人。一旦逐漸年老力衰,不堪長期加班的勞累,兼之以對新技術玩意的掌握,不如新進的長江後浪,所以在過了程式人的「黃金時期」之前,許多程式人都會預先規畫好,朝管理性工作轉換。

優秀的程式人,不等於優秀的管理者
當然,這樣的想法是有待商榷的,許多優秀的程式人,將程式設計當做是一生的志業,即使年紀逐漸老邁,卻也始終寶刀未老,甚至越發光芒、越顯價值。但不可否認的,有許多程式人相當期待能由工程的職務轉換至管理職務,從單純的程式設計工作內容,轉移到以管理技術團隊為主的工作。

除了自我職場生涯規畫的原因之外,有許多在程式設計領域表現出眾的程式人,也很容易被「拔擢」進入管理的工作領域中,成了帶領技術團隊的領導者。

不論是因為想要擠身管理階級,以更符合社會普遍對工作型態轉變的期待,或者是因為想要避去心中視為「苦力」的程式設計工作,而進到技術管理的工作領域,還是單純因為程式設計表現優秀,因而被授以管理大任的程式人,面對他們的工作,多半都有一段水土不服、無法適應的時間。

甚至有些優秀的程式人,在管理工作上,始終無法表現得如他們在程式設計方面般卓越,可能連一般水平都不到。

即使你具備程式設計的背景,是一名優秀的程式人,管理的也是程式設計的開發團隊,但管理和單純的開發工作,模式截然不同。倘若無法跳出純程式人的思考及角色模式,便不容易克服可能遭遇到的管理問題。

當程式人轉型為管理者,工作焦點應由個人改為團隊
單純扮演一名程式人和管理(或說帶領著)一群程式人之間,最大的差別在於,當你身為一名程式人時,任務極為單純,便是在給定的時程內,妥善地完成指派的工作,所以可以十分專注解決自己所遭遇到的問題。

而當你的工作是要帶領一群程式人,以分工合作的方式完成開發專案時,你的焦點不應該放在個人,而是整個團隊上,而這樣子的心態轉變,正是許多程式人在轉型至管理工作時,所不容易克服的。

或許你有過這樣子的經驗。初次被賦予一個領導開發團隊的工作,面對被給定的開發目標,你試著將工作逐一展開為WBS(Work Breakdown Structure),然後將團隊成員名字填進去,針對WBS中的每一項工作,自己估算期限。接著,你召開專案啟動會議,把成員們召集起來,並且公布你依據專案期限及目標所規畫的WBS,也讓成員們知道被指派的工作。你或許還指派了若干件工作在自己身上,因為你的程式人背景,讓你深信自己在專案管理的餘暇,也能為專案貢獻一些心力(或許是因為你認為專案管理占用不了太多的時間)。

你手上拿著WBS心想,接下來專案便會依照預期,每個成員也會像當初的自己一樣,把期限當作是最重要的事情,逐一完成每個工作項目,最後專案便能如期完成並交付,這實在是理想極了。

隨著日子一天一天過去,你或許忙於自己的開發項目,而疏於了解其他成員的情況。但漸漸的,在一些固定的查核點上,你開始發現某些工作項目未能如預期完成,負責這些工作項目的成員總是告訴你,已經完成了90%,再多給他一些時間,一定能夠完成。

但這些工作項目,有些像是無法抵達終點一樣,始終未能完成。延遲的工作項目越累積越多,但你始終相信,人力定可回天,憑著程式人的熱血以及可以無止盡燃燒的肝,之後的工作時程一定可以壓縮。

你或許開始在心中質疑延遲的成員們不夠認真,因為同樣的工作項目,倘若是自己來執行,根本不需要這麼多的時間。你或許還開始將其他成員未能及時完成的項目攬在自己身上,以便讓其他成員撥出時間,完成其他該繼續完成的項目。壓在身上的工作也越來越多,使得你更沒有心力顧及其他成員的情況。當越來越多的工作發生延遲的情況,為了讓專案仍然如期完成,你或許認為這專案其實不需要那麼多的測試時間,因此決定加以壓縮。

當管理者苦幹技術工作,團隊成員誰來關心?
在專案中由於你也如火如荼地埋首於持續加諸身上的工作,更是越來越不可能分身關心其他成員遭遇到的瓶頸,更甭提為他們尋求適當的解決方案。陷於膠著的成員越來越多,專案延遲的情況越來越嚴重,堆在你身上的工作也越來越多。

最後,專案過了期限仍未能交付,同時也因為壓縮了測試時間,也使得軟體品質未能達到一定的水準,專案便在如此不甚成功的氣氛下漸漸收尾。團隊在這樣的模式下,將持續一個又一個失敗的專案。

於是這類管理者開始養成斥責團隊成員的習慣,你心裡想,如果這些傢伙都能像我看齊,多在技術層次上提升,像我一樣為專案全心全意地付出,這些專案那有不成功的道理?

團隊成員既無法從你身上學習到任何東西,更因為你不友善的態度開始疏遠,不願意和你打交道,對於開發過程所下達的指令,也越來越有陽奉陰違的傾向,最後會發現,你完全管理不了這個團隊。

上述的情境,便是從程式人轉職成為開發團隊的領導者時,時常會遭遇到的種種問題。或許事情沒那麼糟,所有不好的情形未必都發生了,但是總會有幾項問題發生在我們的管理經驗中。

管理者最核心的工作,是引導團隊成員
帶領一個開發團隊,最重要的基礎便是「人」 。軟體產業是一個以「人」為主的產業。人的管理是軟體開發管理的根本。做為一個軟體團隊的管理者,最核心的工作,便是了解你的團隊成員,關心他們的工作動態甚至是情緒,並且與他們愉快地一起生活及工作。

你需要了解每個成員的專長及技能取向,以便在安排工作時,將工作安排給適當的成員,以達到最佳的效率及品質。每個人都是獨一無二的,而不是WBS中可以任意交換的Man-Day或Man-Hour。

主管即使精於程式設計,也不應該在開發專案中,將程式設計相關的工作指派給自己,因為你還有更重要的工作要做,也就是關注整個專案的狀態和每個成員的情況。

或許你是整個團隊中技術能力最強的一位,強大的技術能力,讓你可以做為每位團隊成員的後盾,察覺他們正深陷於某個技術泥淖中,而為他們發掘問題,並且提供解決方案。

在這個過程裡頭,無形中將你的技術傳播出來,並且擴散到整個團隊中,漸漸地便能夠提升團隊的整體戰力。同時,你會因此而贏得團隊成員的尊敬,這能持續建立在團隊中的權威,而且那是來自於真正的尊敬,這樣會使得團隊成員更願意相信你所規畫的工作、時程,設定的步調與節奏。

時程的規畫,應該和下屬討論並取得共識
身為技術高手的你,或許會養成對時程過度樂觀的習慣,你能達成自己所設定的期限,不意謂著其他成員也能做到。任何時程的規畫,都應該和下屬討論並取得共識才行。

更不應該的是過度低估測試所需的時間,甚至壓縮測試的時程。開發專案並不是只有程式設計一環。

技術能力出眾的程式人轉換至團隊的管理工作,這項特質絕對是一大正面的助益。但過去的背景,有時也會形成不易跨越的障礙,因而影響到管理的工作。

作者簡介:
王建興
清華大學資訊工程系的博士研究生,研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人,專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同,從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。

沒有留言: