心得：當程式人「晉升」至管理階級
的確，很多程式工程師都很希望可以在未來的幾年後不要在碰到程式了
因此轉往管理職發展，也成了很多程式工程師的目標
不然市場上哪會有那麼多PMP或是什麼ITIL之類的認證
不外乎是想為自己跨進『神秘』的管理職做準備
文中提及的幾個問題點真的是很關鍵
以往大家都是自己玩自己的，自己的時程可以搞定就好了
誰還去管其他人的工作，除非有整合與協調的地方（這部分有時也會成為成員們互推責任或是撕破臉的部分原因）
主管當然有責任把整個完整的工作項目列舉出來
進而去規劃時間表
在規劃時間表時，『過度樂觀的時程』也很容易發生在有技術能力的主管身上
當然是以自己可以處理的經驗值去進行評估，但是往另外一方面想，如果成員有本事跟你做的一樣快或是更快時
那為什麼是你被『晉升』而不是他呢？
另外如果可以的話
盡量幫成員把工作單純化
自己當程式工程師時，不也是極度厭煩工作被打斷嗎
本文開提的第一句話，已經把整篇文的重點講出來了
軟體團隊的管理者，最核心的工作就是瞭解團隊成員，關心他們的工作動態甚至是情緒
瞭解團隊成員不僅僅是有助於規劃專案時程，更對團隊成員的定位可以有更確切的認知
有時候某些程式工程師說不定更適合去擔任系統工程師也說不定，只是他們進入這家公司時，是以應徵程式工程師進來罷了
工作動態的部分
也真的有很多永遠都只有辦法完成90％的員工
為什麼是90％呢？
因為真的做不出來，但是主管又三不五時盯進度，沒把完成比率拱起來，很難說服主管
所以只好一步一步慢慢有計畫的推高數字，但是真正的進度極有可能是停頓的
有時候我也想過，就讓成員自己定時程吧
結果有幾個
一是明明很簡單的事就給我編個好幾天（好吧！這也許和自己過度樂觀時程有關吧！）
不然就是說的頭頭是道，但是檢核時就是做不到，明明是自己規劃的時程，就是不斷的找藉口達不到。
第二種人真的該好好考慮員工的適用性了
當程式人「晉升」至管理階級
文/iThome (記者) 2008-10-01
身為軟體團隊管理者，最核心的工作，便是了解團隊成員，關心他們的工作動態甚至是情緒。
從程式人成為管理階級，似乎是許多程式人對職場生涯的重要規畫。許多人認為程式人這一行是「吃青春飯」，只適合年輕體力充沛的人。一旦逐漸年老力衰，不堪長期加班的勞累，兼之以對新技術玩意的掌握，不如新進的長江後浪，所以在過了程式人的「黃金時期」之前，許多程式人都會預先規畫好，朝管理性工作轉換。
優秀的程式人，不等於優秀的管理者
當然，這樣的想法是有待商榷的，許多優秀的程式人，將程式設計當做是一生的志業，即使年紀逐漸老邁，卻也始終寶刀未老，甚至越發光芒、越顯價值。但不可否認的，有許多程式人相當期待能由工程的職務轉換至管理職務，從單純的程式設計工作內容，轉移到以管理技術團隊為主的工作。
除了自我職場生涯規畫的原因之外，有許多在程式設計領域表現出眾的程式人，也很容易被「拔擢」進入管理的工作領域中，成了帶領技術團隊的領導者。
不論是因為想要擠身管理階級，以更符合社會普遍對工作型態轉變的期待，或者是因為想要避去心中視為「苦力」的程式設計工作，而進到技術管理的工作領域，還是單純因為程式設計表現優秀，因而被授以管理大任的程式人，面對他們的工作，多半都有一段水土不服、無法適應的時間。
甚至有些優秀的程式人，在管理工作上，始終無法表現得如他們在程式設計方面般卓越，可能連一般水平都不到。
即使你具備程式設計的背景，是一名優秀的程式人，管理的也是程式設計的開發團隊，但管理和單純的開發工作，模式截然不同。倘若無法跳出純程式人的思考及角色模式，便不容易克服可能遭遇到的管理問題。
當程式人轉型為管理者，工作焦點應由個人改為團隊
單純扮演一名程式人和管理（或說帶領著）一群程式人之間，最大的差別在於，當你身為一名程式人時，任務極為單純，便是在給定的時程內，妥善地完成指派的工作，所以可以十分專注解決自己所遭遇到的問題。
而當你的工作是要帶領一群程式人，以分工合作的方式完成開發專案時，你的焦點不應該放在個人，而是整個團隊上，而這樣子的心態轉變，正是許多程式人在轉型至管理工作時，所不容易克服的。
或許你有過這樣子的經驗。初次被賦予一個領導開發團隊的工作，面對被給定的開發目標，你試著將工作逐一展開為WBS（Work Breakdown Structure），然後將團隊成員名字填進去，針對WBS中的每一項工作，自己估算期限。接著，你召開專案啟動會議，把成員們召集起來，並且公布你依據專案期限及目標所規畫的WBS，也讓成員們知道被指派的工作。你或許還指派了若干件工作在自己身上，因為你的程式人背景，讓你深信自己在專案管理的餘暇，也能為專案貢獻一些心力（或許是因為你認為專案管理占用不了太多的時間）。
你手上拿著WBS心想，接下來專案便會依照預期，每個成員也會像當初的自己一樣，把期限當作是最重要的事情，逐一完成每個工作項目，最後專案便能如期完成並交付，這實在是理想極了。
隨著日子一天一天過去，你或許忙於自己的開發項目，而疏於了解其他成員的情況。但漸漸的，在一些固定的查核點上，你開始發現某些工作項目未能如預期完成，負責這些工作項目的成員總是告訴你，已經完成了90%，再多給他一些時間，一定能夠完成。
但這些工作項目，有些像是無法抵達終點一樣，始終未能完成。延遲的工作項目越累積越多，但你始終相信，人力定可回天，憑著程式人的熱血以及可以無止盡燃燒的肝，之後的工作時程一定可以壓縮。
你或許開始在心中質疑延遲的成員們不夠認真，因為同樣的工作項目，倘若是自己來執行，根本不需要這麼多的時間。你或許還開始將其他成員未能及時完成的項目攬在自己身上，以便讓其他成員撥出時間，完成其他該繼續完成的項目。壓在身上的工作也越來越多，使得你更沒有心力顧及其他成員的情況。當越來越多的工作發生延遲的情況，為了讓專案仍然如期完成，你或許認為這專案其實不需要那麼多的測試時間，因此決定加以壓縮。
當管理者苦幹技術工作，團隊成員誰來關心？
在專案中由於你也如火如荼地埋首於持續加諸身上的工作，更是越來越不可能分身關心其他成員遭遇到的瓶頸，更甭提為他們尋求適當的解決方案。陷於膠著的成員越來越多，專案延遲的情況越來越嚴重，堆在你身上的工作也越來越多。
最後，專案過了期限仍未能交付，同時也因為壓縮了測試時間，也使得軟體品質未能達到一定的水準，專案便在如此不甚成功的氣氛下漸漸收尾。團隊在這樣的模式下，將持續一個又一個失敗的專案。
於是這類管理者開始養成斥責團隊成員的習慣，你心裡想，如果這些傢伙都能像我看齊，多在技術層次上提升，像我一樣為專案全心全意地付出，這些專案那有不成功的道理？
團隊成員既無法從你身上學習到任何東西，更因為你不友善的態度開始疏遠，不願意和你打交道，對於開發過程所下達的指令，也越來越有陽奉陰違的傾向，最後會發現，你完全管理不了這個團隊。
上述的情境，便是從程式人轉職成為開發團隊的領導者時，時常會遭遇到的種種問題。或許事情沒那麼糟，所有不好的情形未必都發生了，但是總會有幾項問題發生在我們的管理經驗中。
管理者最核心的工作，是引導團隊成員
帶領一個開發團隊，最重要的基礎便是「人」 。軟體產業是一個以「人」為主的產業。人的管理是軟體開發管理的根本。做為一個軟體團隊的管理者，最核心的工作，便是了解你的團隊成員，關心他們的工作動態甚至是情緒，並且與他們愉快地一起生活及工作。
你需要了解每個成員的專長及技能取向，以便在安排工作時，將工作安排給適當的成員，以達到最佳的效率及品質。每個人都是獨一無二的，而不是WBS中可以任意交換的Man-Day或Man-Hour。
主管即使精於程式設計，也不應該在開發專案中，將程式設計相關的工作指派給自己，因為你還有更重要的工作要做，也就是關注整個專案的狀態和每個成員的情況。
或許你是整個團隊中技術能力最強的一位，強大的技術能力，讓你可以做為每位團隊成員的後盾，察覺他們正深陷於某個技術泥淖中，而為他們發掘問題，並且提供解決方案。
在這個過程裡頭，無形中將你的技術傳播出來，並且擴散到整個團隊中，漸漸地便能夠提升團隊的整體戰力。同時，你會因此而贏得團隊成員的尊敬，這能持續建立在團隊中的權威，而且那是來自於真正的尊敬，這樣會使得團隊成員更願意相信你所規畫的工作、時程，設定的步調與節奏。
時程的規畫，應該和下屬討論並取得共識
身為技術高手的你，或許會養成對時程過度樂觀的習慣，你能達成自己所設定的期限，不意謂著其他成員也能做到。任何時程的規畫，都應該和下屬討論並取得共識才行。
更不應該的是過度低估測試所需的時間，甚至壓縮測試的時程。開發專案並不是只有程式設計一環。
技術能力出眾的程式人轉換至團隊的管理工作，這項特質絕對是一大正面的助益。但過去的背景，有時也會形成不易跨越的障礙，因而影響到管理的工作。
留言列表