從技術轉管理，我作了什麼來拯救本身？

我是一名新手項目經理，轉項目管理崗1年半。在作管理以前，我是一名開發。也就是說，我是最多見的技術轉管理了。

最開始，我極度不適應這個崗位。很累，可是不見成效。通過一年多的摸索，我終於在工做中總結出了一些心得，一些套路。因此我想給技術轉管理的同窗們講一講：
我作了什麼，來拯救本身

我的背景和公司背景

1.目前爲止工做4年半，也就是說，我作了3年開發，1年半管理
2.我是一名野生程序員（就是非計算機專業畢業）
3.我寫過Android、iOS、web頁面、java後端、python後端等等，看起來像傳說中的全棧程序員。但其實心知肚明，我就是那種啥都會但啥也不行的程序員
4.公司此前作產品，後來在產品的基礎上轉型外包擴大規模
5.公司轉型的基礎上，我也轉型成了管理
6.我司項目經理是一個專門的職位，負責項目管理、技術架構、客戶對接。總之項目的一切相關問題，包括技術問題，都由項目經理負責

我作了什麼

事必躬親，會毀了團隊也會毀了本身

這恐怕是全部從技術轉管理的人，都會犯的通病。我剛開始帶團隊的時候，核心代碼都要本身寫。而後看同事進度的時候老是嫌這個慢，那個不行的。看不下去了索性本身上手吭哧吭哧寫好。弄得本身很是疲憊。

一般技術能力強的人，更有機會轉型管理崗。因此在帶團隊的過程當中，老是不由自主的親自動手完成別人應該作的事情。最終結果就是總會替代同事作他們本身本應該作的事情。

但這個行爲對管理者來講，只會讓管理者愈來愈疲憊。而對整個團隊來講，更是溫水煮青蛙，一步一步把團隊帶進深淵。管理者負擔太多工做，致使團隊長期沒法成長。輕則致使管理者累崩。重則致使項目崩塌、團隊分崩離析。

我應該怎麼辦：
實際上，影響別人去作好一件事，比親自去作要難的多。而我處理這個問題的方式
1.忍住本身親自動手的心理
2.複雜任務拆解細化，分派任務時明確任務目標和驗收標準
3.分派任務時給予同事鼓勵，對他們保持充分信任
4.有難度的任務，提供必定的輔助或者培訓

多想、多說、多作

我開始帶團隊的時候，一直忙於處理各類各樣的項目問題，寫代碼、溝通需求、進度彙報、現場演示。大部分時間都埋頭於項目自己，覺得只要把項目作好，按時交付就行。作的太多， 致使思考的時間少了，對團隊同事的關注也就少了。

而一個團隊領導者，多作是應該的，更重要的是多思考，多說

思考什麼：
1.項目干係人是否清楚，干係人不清楚會致使項目管理混亂，出的東西不知足要求
2.需求是否合理，需求是否能夠優化、技術架構是否知足需求
3.功能是否拆解到位，任務分派是否可合理
4.若嘗試新技術，是否有把握在出問題的時候力挽狂瀾
5.團隊成員狀態如何，要如何激勵他們
6.項目流程是否合理，如何改進
7.項目成本如何控制，時間節點如何把握，質量如何保證

以上都是我目前每一個項目都會思考的問題。項目管理者必定要告誡本身：不要用戰術上的勤奮掩蓋戰略上的懶惰

說什麼：
1.需求不清楚要問
2.需求能夠優化要說，不要悶聲發大財，坑的是本身
3.有困難處理不了要及時彙報給領導，悉知客戶
4.團隊成員有問題要給予正確指導，而不是聽任自由
5.進度狀況、項目狀況要積極和客戶保持溝通

不只是監督，更要是指引

「那個功能寫完了嗎？」；「這個功能怎麼還沒作好」；「你這個東西何時可以寫完」。

以上是我平常工做中最常作的事情，即使到了目前，我依然在作這些事。監督催促同事幹活！天天像個監工同樣，漫步在同事周圍，監督他們的進度，在他們耳邊逼逼叨。

但我認爲，催促同事幹活的不該該是項目經理，而是項目流程，是規則。每一個人明確本身的角色，各司其職，由規則約束着你們前行。而不是簡單靠項目經理趕着你們往前走。

但我並無作好這個工做，目前仍是處於制定計劃、監督執行的死循環中。對於規則、流程只是有個模糊的想法，還不成型，也未經試驗。暫不與你們分享。

救火能力當然重要，但更要防範於未然

我由技術轉管理的初期，最擅長的事情就是技術。因此一直在項目中充當救火隊員的角色。

有突發狀況？我本身來；沒有人能攻克技術難點？那我本身來；開發了好久，發現需求理解錯誤？咔咔咔本身一頓改；總之就是這有問題，咔咔咔本身一頓弄，那有問題，嗒嗒嗒本身一頓搞。總用本身的技術能力挽救項目中的各類突發狀況。

而做爲一個項目管理者，救火能力當然重要，要在關鍵時刻可以站出來力挽狂瀾。但更重要的，我想是如何去避免突發狀況吧。而要避免突發狀況，就要思考如何作好風險管理。提前作好準備，把可能出現的未知風險扼殺在襁褓中。

在IT項目管理中，我認爲風險主要存在於如下幾點，應思考準備以便規避風險：
1.需求變動。開發中需求變動是不免的，但如何控制需求變動，如何管理需求變動是咱們着重要考慮的問題。SCALPEL方法，你們能夠了解一下
2.項目干係人不清楚，致使項目需求分歧
3.技術難點預估不足。老是會存在開發過程當中才發某項功能沒法實現或者實現成本太高，這主要是因爲前期對需求理解不足，對自我或團隊太自信形成的
4.計劃制定問題。開發計劃制定有問題，可能因爲錯誤的估計了團隊的能力，項目的難度形成的。計劃風險一般是由項目經理本身形成，需自我強化、學習、思考來避免此問題
5.組織成員問題。開發成員不足、人員離職、其它項目需緊急支援人手、團隊溝通不順暢均可能引發此問題
6.流程風險。過於流程化，致使流程工做佔用太多開發時間，流程和靈活是一對衝突的概念。如何解決項目管理中流程化和靈活度的問題，我認爲是項目經理較重要的能力之一
7.性能問題。開發過程當中，最怕的是功能作完了，最後發現性能不行。致使前期開發工做全白費。因此在需求階段，軟件的用戶量，數據量都是要考慮在內的。在開發之初，就要在程序設計過程當中將性能問題考慮進去

保持心裏強大

項目管理是一個磨人的工做。雖然外面說要作風險管理，但突發狀況避免不了。一個合格的項目管理者，要有泰山崩於前而色不變的心裏。

需求變了沒關係、計劃變了沒關係、成員狀況發生變化沒關係。畢竟咱們都知道世界上惟一不變的就是變化，儘量的給本身準備好Plan B

背黑鍋要上，邀功也要上

我相信各位作開發的時候，最討厭的就是那種黑鍋你背，有功他領的leader。既然如此，但願咱們也不要變成這樣的人。

項目經理嘛，統管這個項目的一切。項目出了問題，無論由於什麼緣由，都必定是項目經理的責任。你的同事可能在項目裏表現不佳，你的客戶可能常常變動需求。無論多少理由，都不是你甩鍋的理由。有鍋必定要本身扛着，因此，背黑鍋要上。

作的好，也要說出來。超出客戶預期的項目閃光點，要告訴客戶團隊的優秀。項目完成的不錯，要告訴老闆團隊的優秀。讓客戶讓老闆知道大家團隊作的好，下一次他們纔會給大家更充分的信任。項目成員表現優秀的地方，不光要表揚，也要和上級說。你是和你團隊成員接觸最緊密的人，他們的有點別人不知道，但你知道。因此他們優秀的地方，要宣揚，要讓別的部門知道，要讓上級知道。因此邀功也要上。

在幫派裏，不能爲兄弟們擋刀並引領兄弟們前進的老大是不值得追隨的，弟兄們在你手下作事受盡委屈，爭不了一口氣，那這個老大也作不長。

技術出身的管理者中，我相信背黑鍋要上是你們都能作到的。但技術人員不善言辭，老是悶頭幹活，不會表達。因此要適當學會邀功，爲團隊邀功。但願你們都能學會邀功也要上

不要拋棄技術，它多是你的救命良藥

作項目管理之後，尤爲是像我如今這種一我的帶多個項目的狀況。管理工做會佔用天天極多的時間。這是工做自己須要你作的，無可厚非。我想說的是，即使如此，也要保證本身對技術的學習。

瞭解新技術也好，寫寫開源項目也好，總之要保持對技術的持續學習。他總能在你須要的時候幫到你。

學如逆水行舟,不進則退，與你們共勉

總結

整體而言，我認爲一個新手項目經理，要學會如下事情：
1.要學會帶領團隊成長，不要事必躬親
2.要多進行思考
3.要學會風險管理
4.要保持心裏的強大
5.要學會邀功

以上，就是我想和你們分享的內容，其中不少點，我本身作的也不是很好，依然須要自我練習和努力。但願各位技術轉管理的同窗，都能儘快適應本身的工做。