首頁>Club>
技術骨幹朝著管理人才前進的過程中,應該如何培養其管理職業能力呢?
4
回覆列表
  • 1 # 滕訓

    每個人的職業生涯中,總會遇到這個關口:有機會從技術崗位轉到管理崗位。

    在面對這個機會的時候,有的人猶豫,有的人毫不猶豫。

    只不過,不管我們繼續從事技術,成為技術專家;

    還是從事管理,開始新的征程,可能或多或少都需要了解一些管理的知識。

    有的人可能會反對:你說的不對,我就想專心做好技術,不願意做管理。

    但即便是這樣,你也會面對一個自我管理的問題。

    因為:無論你從事哪一行,你都不只是別人的員工,你還是自己職業生涯的員工。

    在這個方面,推薦斯蒂芬科維的經典圖書《高效能人士的七個習慣》,可以對整個自我管理體系進行一個認知。

    從技術走向管理,有幾個思維的坎兒需要及時轉換,簡單描述如下:

    1)在做技術時,我們只用考慮自己專業範圍內的事情就可以了;

    而管理,則需要從整體角度進行考慮,因為你的目標不一樣了,同時要考慮每個專業對整體目標的影響。

    2)在做技術時,我們遇到技術難題,會激發自己的熱情或者被激發,迎難而上,攻克難關。

    而管理,則需要你激勵下屬去完成工作範圍內的難題,而你要做的就是做好後勤,提供一切援助。

    3)在做技術時,碰到人的難題,有畏縮情緒,這個人惹不起咱躲得起。

    而管理,則需要轉變思維方式,主動去溝通。

    4)在做技術時,我考慮問題可以二元論,不是0就是1,非黑即白。

    而管理,沒有對錯,只是觀點不同和站的位置不同,可以存在中間地帶。

    不管是做技術還是做管理,我們都有自己的工作範圍。

    在這個前提下,如何進行工作彙報?如何分配工作呢?

    請示工作講方案;

    彙報工作說結果;

    佈置工作說標準;

    交接工作講道德;

    回憶工作說感受。

  • 2 # 人月聊IT

    最近一段時間,經常會接到一些諮詢,就是類似如何快速的從開發轉變為架構,或者說已經快到40歲了技術已經幹不動了,職業很迷茫,也不清楚如何能上升到管理渠道。

    對於IT行業的各類崗位,大家有個共識,就是一個吃青春飯的職業。那麼對於網際網路和軟體行業的開發人員,如何從開發轉為架構?或者說如何從技術走向管理?估計是大部分人關心的問題。

    就我自己來說在這個行業呆了快20年,從最早的軟體開發,到需求,架構,IT專案經理,大專案經理和產品總經理,再到現在的公司管理層。在這麼多年的工作和實踐中,自己也在不斷的學習和成長,而且在從技術到管理的整個發展路徑中,最大的感受就是兩點:

    軟體行業沒有純管理,更多是技術+管理轉變意識,時刻考慮如何培養和鍛鍊自己的綜合技能

    在本文的最後我給出了自己近20年的工作和學習成長路線,可以供大家借鑑和參考。在這裡我們從技術,管理,通用軟技能三個方面來談下如何從技術走向管理。

    技術能力積累是基本盤

    在IT行業很多人往往都有一個誤區,就是公司反正給了技術和管理多條職業發展路線。我自己技術能力提升不上去了,但是我綜合能力還不錯,那我就朝管理崗位發展。

    這種情況估計也有,但是個人理解還是少數,真正走向管理崗位的往往是技術骨幹,同時具備較強的綜合管理能力。你也可以把公司的發展路徑理解為:

    公司為技術骨幹人員準備了兩條職業發展路線和跑道。

    如果你不善溝通,對技術痴迷,那你安心做技術,並晉升為公司技術專家如果你善於溝通,也喜歡和人打交道,那麼你可以選擇晉升為管理崗位

    什麼意思呢?

    就是你要走向管理崗位,技術仍然是基本盤,而且我們也看到實際上走向管理崗位的時候往往伴隨著兩個方向的同時發展。

    其一是從一般開發到技術骨幹或架構,其二是從小團隊研發管理到公司級管理。你的技術可能不是你們公司頂級水平,但是往往也是你所在公司的骨幹級水平,同時具備了多年的技術實踐和技能的積累。

    為什麼技術能力如此重要?

    當你走向管理崗位後,我們清楚最重要的就是招人,用人,培養人。軟體行業屬於輕資產,而人就是最核心的資產。而對於技術類人員如何才能夠管理好?簡單來說就兩點。

    你要懂得技術人員的心理你要讓下面的人員信服你

    就以上兩點來說,你如果沒有較強的技術能力積累基本無法做到。技術團隊的管理絕對不是胡蘿蔔+大棒就能夠管理好的,也不是簡單的條條框框和小恩小惠,而是需要下面人員對你能力的認可。將管理力轉變為一種領導力。

    技術發展快速,你的知識是否過時?

    對於技術類管理者,在走向管理崗位後還會發現,技術發展太快,你原來的技術知識體系往往跟不上。而這個時候你可能並不會詳細去實踐和練習。

    在這個時候你才會發現原來大量的技術能力積累帶來的新好處,就是架構思維能力,對理論的抽象理解能力。簡單來說就是有些知識理論,你不用去實踐大概也能掌握基礎原理。而到了管理崗後,你對這種原理性知識的掌握就已經足夠了。

    新技術再層出不窮,你也會發現最基本的軟體框架,模式,架構思維並沒有變。

    管理能力-從個人自我管理開始

    經常看我文章的可能會看到,除了技術類文章,我也經常寫個人自我管理,知識管理,時間管理,自律和習慣培養等方面的文章。

    要明白從技術走向管理本身也有發展路徑。

    個人管理-》小團隊管理-》專案或大專案管理-》產品線管理-》公司級管理

    對於管理我們仍然要遵循這個路線循序漸進。

    德魯克有一本書叫《卓有成效的管理者》,這本書我是建議所有的技術人員閱讀。在這本書裡面作者給出了一個關鍵概念,即是:

    對於所有的知識工作者,他們都是管理者,並且首先要管理好自己。

    而一個技術人員要真正走向管理,同樣要意識到能否做好個人自我管理。個人自我管理包括的內容很多,包括了個人知識管理,GTD和個人時間管理,個人精力管理和習慣養成等。再簡單總結一下就是五個凡事,類似我們經常說的個人PDCA迴圈。

    凡事有計劃,凡事有執行,凡事有結果,凡事有記錄,凡事有改進。

    把個人管理做好後,我們再來看,還需要進一步補充的知識,其中會涉及到軟體工程和研發過程管理,專案管理和產品管理,人力資源管理幾個大的方面。

    軟體工程:類似CMMI,敏捷開發等基礎研發過程管理知識專案管理:比如我們常說的PMBOK專案管理知識體系,CMMI中也包括相關內容產品管理:比如類似IPD或PACE方法論,高效產品研發人力資源:常說的人力資源管理,比較重要的招聘,培訓,績效,職業發展等

    在這裡還得提一個關鍵點,就是我們常說的人力資源管理,大家一定要意識到人力資源管理實際並不是人力資源部門的事情,人力資源部門往往更多的是制定標準的規範流程,但是實際涉及到具體培訓,績效,職業發展等仍然還需要各個產品線,部門來完成。

    我上面談到的四個方面的管理能力,實際上你可以看到,基本仍然是圍繞專案實踐,產品研發實踐展開的,如果你沒有實踐,沒有深入一線往往這些管理能力是無法得到提升的。這些管理能力不是簡單的你坐在辦公室裡面聽別人彙報,發表點意見就能夠學會的。

    通用軟技能-無明顯短板

    最後一點,就是我們經常會說到的一個管理者或者一個職業經理人的通用軟技能。而對於通用軟技能的要求就是沒有明顯的短板,或者說是越強越好。

    在這裡面第一位的是溝通能力。

    一個管理者你可以看到你在完成產品或專案,在管理團隊,在績效溝通,在培養人的時候,都離不開溝通能力,溝通能力是基礎的基礎。

    有些技術人員天生不愛溝通,溝通能力弱,影響他們走向管理崗位。

    但是當你意識到你溝通能力有欠缺的時候,你要有意識的是改進,抓住每一次機會去改進。比如我常說的給團隊內做培訓,給客戶做售前交流,給技術人員講解技術點,給公司領導彙報專案進展等。所有這些都是鍛鍊溝通能力的地方。

    不是每個人天生溝通能力就強,需要的仍然是反覆不斷練習。

    因此我們看到軟技能包括的幾個方面

    溝通呈現能力:包括了溝通能力,寫作能力,PPT呈現能力,演講能力思維能力:包括了學習能力,事物認知,獨立分析和解決問題能力領導和決策能力:包括了領導力,決策能力

    這幾個方面的軟技能都相當重要,除了溝通外,另外一個關鍵能力就是寫作和呈現。培根說過,閱讀使人充實,而寫作使人精確。透過寫作你可以將自我實踐進一步進行體系化整理,形成知識庫沉澱和個人經驗庫,同時透過演進的方式呈現給他人,形成一個完整的歸納到演繹的閉環。

    這個不僅僅是簡單技能的提升,更加重要的是思維能力的提升。

    我原來一直在強調

    在職場上最後競爭的是思維能力,即獨立分析和解決問題的能力。

    對於經常看我人月神話新浪部落格文章的可能就明白,就我自己不僅僅是SOA專業的技術知識積累,更加重要的就是這些軟技能知識的不斷積累,而這些軟技能本身對管理能力提升起到了很好的輔助作用,是缺一不可的。

    管理者-招人,用人和培養人

    如果重新迴歸到管理者,簡單來說核心仍然是招人,用人和培養人。也可以理解為找到合適的人,為他們安排合適的工作,並時刻培養和激勵他們。這就是以人為核心的簡單的管理。

    一個技術人員走向管理的時候一定要注意去我

    簡單來說就是,當你走向技術崗位的時候,你不能再以自己為中心,以技術為中心。而是應該以公司或團隊目標為核心,以整體績效為中心。

    一個管理者要懂得授權

    但是在我們成為管理者後往往經常是盲目授權,在對下屬能力不清楚的情況下盲目授權,最終導致無法完成目標或既定的任務。

    因此技術類管理者要意識到,培養人往往比授權更加重要。一個管理者的精力更多應該放在基於團隊目標驅動來培養人上面,而授權僅僅是培養人後的一個結果。

    附文-個人工作和職業發展路徑總結

    最後講下自己從技術到管理的經歷供參考,首先要說明的一點就是我認為技術到管理後,沒有純管理,而更多是技術加管理。從2001年畢業到現在工作整整18年整。而自己的整個工作經歷也相當簡單,有8年的時間在中興通訊,然後在現在公司一直呆到現在。

    在中興的8年可以講給自己打下了很好的技術基礎和專案管理基礎,在第二階段10年時間則專注在SOA和雲計算方向,並差不多8年時間都在移動聯通的SOA大專案中進行現場管理和實施。

    第一階段:中興八年的工作經歷

    在中興八年的工作經驗可以說對自己的成長至關重要,從最初的軟體開發,到架構設計,再到專職化的IT專案管理,大專案群管理,基本是按照比較理想的個人成長路線在成長和發展。如果簡單歸類來說則是鍛鍊軟體工程,專案管理,產品管理,業務知識四個方面的核心能力。

    軟體開發和軟體工程

    在中興自己做了3年多的軟體開發和編碼,架構設計等。即使到了05年後期也還偶爾會做些小的關鍵功能的設計和開發工作。而這些工作為後續的專案管理,包括加入遠行後到客戶現場的大專案實施等都起到了很好的輔助作用。

    對於IT行業沒有純粹的管理,必須要有技術基礎積累,是技術+管理模式

    不僅僅是軟體開發,更加重要的就是整個軟體工程體系的實踐,從需求工程,架構設計,面向物件和UML,測試,互動設計和易用性,包括我們從04年開始實施CMMI二級,這些都使得自己對軟體生命週期和軟體工程體系有了更加深刻的理解的認識。

    可以將這些都是比較系統化的學習和實踐,對於需求,架構設計,UML等都是公司當時請了外部最好的培訓資源,2到3天的封閉培訓,正是如此,這些知識學習更加系統。

    軟體專案管理和CMMI

    中興當時的模式是一進入到專案經理崗位就是專職化的專案經理,而不再從事具體的需求,設計和開發等工作項。在04年下半年自己變為專職的專案經理,在06年透過PMP專案經理認證。

    同時我們在04年就啟動了CMMI二級的評估工作,在04年通過了CMMI二級,在05年通過了CMMI三級,然後再花了兩年時間在07年通過了CMMI四級。而整個CMMI評估過程,從作為專案經理到作為大專案經理全程參與評估和過程改進,也為自己打下了更加堅實的技術基礎。

    而中興的軟體專案管理則是結合了CMMI中專案管理相關的PA內容和PMBOK知識體系內容進一步整合而成的,整個專案管理規範和流程雖然較為繁瑣,但是也更加細緻和專業,同時我們自己開發了類似PMS,PDB,缺陷管理,IOA週報協同和問題管理等諸多的業務系統對我們專案管理進行有效的支撐。

    產品管理和專案群管理

    進入到06年下半年,自己升為產品總工和大專案經理,下面有4個子專案同時屬於PLM產品線,因此更多的是進行專案群管理和專案組合管理方面的工作。而在這個階段,自己也作為專案組員參與了到兩個公司級的重要專案,一個是和IPD類似的PACE高效產品研發,一個是當時外請了羅蘭貝格諮詢公司來做的專案化運作諮詢。

    特別是在PACE高效產品研發中,由於PLM產品線下面的PDM,EC,PMS,RCS,PPM本身就是PACE的關鍵支撐系統。因此在這個過程中對PACE也進行了系統化的學習,特別是裡面的MM市場管理,組合管理,管道管理,產品決策。這些也讓市場驅動研發,產品全生命週期的概念進一步深入到自己的實踐經驗中。

    業務架構和業務積累

    所有的IT系統最終都是為企業業務目標和業務流程服務。而在中興的前面一半時間主要接觸SCM供應鏈相關流程和業務,而後面一段則主要接觸PLM產品生命週期管理。在前面一段還作為關鍵組員參加了公司組織的i2 APS業務知識培訓,這個使得自己供應鏈方面知識也更加系統化,而對於PLM則是參與PACE專案後對整個產品研發流程有了更加深刻的認識。

    而對於業務積累比較遺憾的就是在中興期間對於財務類業務和系統,市場營銷類業務和系統自己接觸的不多,對於這兩塊業務域本身也存在欠缺。這個在後期從中興出來後,在做企業整個的資訊化架構規劃,業務架構設計的時候還是明顯發現尋找一些底層業務細節無法梳理的很清楚的情況。

    我一直認為中興的八年對自己知識技能和經驗的積累至關重要,在後面從事外部專案實施和管理的時候也印證了這點。由於當時中興做內部IT專案,雖然也緊張也有進度壓力,但是相當來說比外部專案好很多,這也使得制定的規程,標準等能夠完全執行下去。這些雖然稍顯臃腫,但是這種專業化的鍛鍊為自己後續實踐打下很好積累。

    為學日益,為道日損。你必須先了解專業和標準化做法,並進行實踐,其次才可能知道如何更加實際的情況進行更好的靈活運用和過程裁剪。

    過程和目標也是我一直談到的點,而這裡面自己更加強調過程,即好的過程才能夠導致好的目標。雖然一些小事情有無過程無所謂,但是做大系統,大專案則過程是必須的,你簡單靠你的經驗,游擊隊的做法是沒法做大型專案和工程的。

    第二階段:工作經歷

    進入遠行後開始我第二段職場工作,也正是變成了一個真正的乙方,並從做企業內部IT專案到做外部企業專案,同時更多的需要現場管理和實施。雖然自己是以高層管理的身份進入遠行科技,但是當時公司本身也在剛起步的階段,因此更多的還是參與到一線專案的實施和管理中。

    而在遠行工作的差不多10年時間裡面,自己差不多70-80%的時間都在客戶現場,從大專案的管理和實施工作,同時裡面有70-80%左右的時間全部在做中國移動和中國聯通兩大集團的SOA整合平臺專案。初步算了下在這10年時間裡面,自己在北京呆的時間差不多就有6年以上。

    而在遠行工作的10年,最主要的可以理解為兩個方面的關鍵積累,一個是企業架構和資訊化規劃,一個就是SOA和雲計算,當然在這個中間還做過電力行業資訊化,智慧城市架構設計和實施,智慧家庭和物聯網等諸多事情,但是都不是主體。也就是說自己還是很專注在SOA和雲這個專業方向上,進行深入的實踐和積累。

    企業架構和資訊化規劃

    我一直強調過,工作以後更加重要的是在實踐中學習和成長,不斷的實踐,不斷的覆盤總結,最終將知識體系化和結構化。對於企業架構和資訊化規劃,自己做了電網行業的一些資訊化規劃,新疆移動資訊化規劃,廣東移動和TCL的SOA規劃等後,結合SOA架構諮詢和TOGAF方法論,對企業架構和資訊化規劃這塊的知識進行了體系化的整理。

    SOA和雲計算

    第二階段基本就是一直在從事SOA和雲計算相關的專案實踐過程,而這個過程中又以SOA為主,雲計算為輔。對於SOA和ESB服務匯流排,我們做了大量的大型集團專案,包括在12年啟動的聯調集團私有云PaaS平臺大專案,在整個實踐和專案實施過程中對於SOA和雲的關係有了更加深入的理解。這也將是我今年將要出版的SOA和雲計算-企業私有云平臺建設實踐這本書的重要內容。

    從16年開始,我們開始關注微服務架構和DevOps,特別是微服務架構實施方法,中臺構建思路等。在自己部落格上也可以看到自己對微服務架構關於中臺,服務識別定義,服務閘道器,服務治理中心,服務實施和傳統IT架構遷移等都有過詳細的闡述。同時我們也提供了結合微服務+容器化PaaS+DevOps的完整支撐平臺,這個也將成為我們後續推廣的一個重要產品和服務。

  • 中秋節和大豐收的關聯?
  • 最著名的悲劇英雄,楚霸王項羽到底差在哪裡?為何打不過劉邦?