技術轉管理，我做了什么來拯救自己？
原創【51CTO.com原創稿件】最開始，我極度不適應這個崗位。感覺很累，還不見成效。經過一年多的摸索，我終于在工作中總結出了一些心得和套路。
所以我想給技術轉管理的同學們講一講：我做了什么，來拯救自己。
個人背景和公司背景
首先單說下我的個人及公司背景：
· 我是一名野生程序員（就是非計算機專業畢業）。
· 目前為止工作 4 年半，也就是說，我做了 3 年開發，1 年半管理。
· 我寫過 Android、iOS、Web 頁面、Java 后端、Python 后端等等。雖然看起來像傳說中的全棧程序員，但其實我心知肚明，就是那種啥都會但啥也不行的程序員。
· 公司此前做產品，后來在產品的基礎上轉型外包擴大規模。
· 公司轉型的基礎上，我也轉型成了管理。
· 我司項目經理是一個專門的職位，負責項目管理、技術架構、客戶對接。總之項目的一切相關問題，包括技術問題，都由項目經理負責。
我做了什么
事必躬親，會毀了團隊也會毀了自己
這恐怕是所有從技術轉管理的人都會犯的通病。我剛開始帶團隊的時候，核心代碼都要自己寫。
然后看同事進度的時候總是嫌這個慢，那個不行。看不下去了索性自己上手吭哧吭哧寫好，這樣弄得自己非常疲憊。
通常技術能力強的人，更有機會轉型管理崗。所以在帶團隊的過程中，總是情不自禁的親自動手完成別人應該做的事情。最終結果就是總會替代同事做他們自己本應該做的事情。
但這個行為對管理者來說，只會讓管理者越來越疲憊。而對整個團隊來說，更是溫水煮青蛙，一步一步把團隊帶進深淵。
管理者負擔太多工作，導致團隊長期無法成長。輕則導致管理者累崩；重則導致項目崩塌、團隊分崩離析。
我應該怎么辦？實際上，影響別人去做好一件事，比親自去做要難的多。
而我處理這個問題的方式如下：
· 忍住自己親自動手的心理
· 復雜任務拆解細化，分派任務時明確任務目標和驗收標準
· 分派任務時給予同事鼓勵，對他們保持充分信任
· 有難度的任務，提供一定的輔助或者培訓
多想、多說、多做
我開始帶團隊的時候，一直忙于處理各種各樣的項目問題，寫代碼、溝通需求、進度匯報、現場演示。
大部分時間都埋頭于項目本身，以為只要把項目做好，按時交付就行。做的太多， 導致思考的時間少了，對團隊同事的關注也就少了。而一個團隊***，多做是應該的，更重要的是多思考和多說。
思考什么：
- 項目干系人是否清楚，干系人不清楚會導致項目管理混亂，出的東西不滿足要求。
- 需求是否合理，需求是否可以優化、技術架構是否滿足需求。
- 功能是否拆解到位，任務分派是否合理。
- 若嘗試新技術，是否有把握在出問題的時候力挽狂瀾。
- 團隊成員狀態如何，要如何激勵他們。
- 項目流程是否合理，如何改進。
- 項目成本如何控制，時間節點如何把握，質量如何保證。
以上都是我目前每個項目都會思考的問題。項目管理者一定要告誡自己：不要用戰術上的勤奮掩蓋戰略上的懶惰。
說什么：
- 需求不清楚要問。
- 需求可以優化要說，不要悶聲發大財，坑的是自己。
- 有困難處理不了要及時匯報給領導，悉知客戶。
- 團隊成員有問題要給予正確指導，而不是放任自由。
- 進度情況、項目情況要積極和客戶保持溝通。
不僅是監督，更要做指引
“那個功能寫完了嗎？”；“這個功能怎么還沒做好”；“你這個東西什么時候能夠寫完”。
以上是我日常工作中最常做的事情，即便到了目前，我依然在做這些事。
監督催促同事干活！每天像個監工一樣，漫步在同事周圍，監督他們的進度，在他們耳邊逼逼叨。
但我認為，催促同事干活的不應該是項目經理，而是項目流程，是規則。每個人明確自己的角色，各司其職，由規則約束著大家前行。而不是簡單靠項目經理趕著大家往前走。
但我并沒有做好這個工作，目前還是處于制定計劃、監督執行的死循環中。對于規則、流程只是有個模糊的想法，還不成型，也未經試驗。暫不與大家分享。
救火能力固然重要，要防范于未然
我由技術轉管理的初期，最擅長的事情就是技術。所以一直在項目中充當救火隊員的角色。
有突發情況？我自己來；沒有人能攻克的技術難點？那我自己來；開發了很久，發現需求理解錯誤？咔咔咔自己一頓改。
總之就是這有問題，咔咔咔自己一頓弄；那有問題，嗒嗒嗒自己一頓搞。總用自己的技術能力挽救項目中的各種突發情況。
而作為一個項目管理者，救火能力固然重要，要在關鍵時刻能夠站出來力挽狂瀾。但更重要的，我想是如何去避免突發情況吧。
要避免突發情況，就要思考如何做好風險管理。提早做好準備，把可能出現的未知風險扼殺在襁褓中。
在 IT 項目管理中，我認為風險主要存在于以下幾點，應思考準備以便規避風險：
- 需求變更。開發中需求變更是難免的，但如何控制需求變更，如何管理需求變更是我們著重要考慮的問題。SCALPEL 方法，大家可以了解一下。
- 項目干系人不清楚，導致項目需求分歧。
- 技術難點預估不足。總是會存在開發過程中才發現某項功能無法實現或者實現成本過高，這主要是由于前期對需求理解不足，對自我或團隊太自信造成的。
- 計劃制定問題。開發計劃制定有問題，可能由于錯誤的估計了團隊的能力，項目的難度造成的。
- 計劃風險通常是由項目經理自己造成，需自我強化、學習、思考來避免此問題。
- 組織成員問題。開發成員不足、人員離職、其他項目需緊急支援人手、團隊溝通不暢都可能引起此問題。
- 流程風險。過于流程化，導致流程工作占用太多開發時間，流程和靈活是一對沖突的概念。
- 如何解決項目管理中流程化和靈活度的問題，我認為是項目經理較重要的能力之一。
- 性能問題。開發過程中，最怕的是功能做完了，***發現性能不行。導致前期開發工作全白費。
所以在需求階段，軟件的用戶量，數據量都是要考慮在內的。在開發之初，就要在程序設計過程中將性能問題考慮進去。
保持內心強大
項目管理是一個磨人的工作。雖然外面說要做風險管理，但突發情況避免不了。一個合格的項目管理者，要有泰山崩于前而色不變的內心。
需求變了不要緊、計劃變了不要緊、成員情況發生變化不要緊。畢竟我們都知道世界上唯一不變的就是變化，盡可能的給自己準備好 Plan B。
背黑鍋要上，邀功也要上
我相信各位做開發的時候，最討厭的就是那種黑鍋你背，有功他領的 Leader。既然如此，希望我們也不要變成這樣的人。
項目經理嘛，統管這個項目的一切。項目出了問題，不管因為什么原因，都一定是項目經理的責任。
你的同事可能在項目里表現不佳，你的客戶可能經常變更需求。不管多少理由，都不是你甩鍋的理由。有鍋一定要自己扛著，所以，背黑鍋要上。
做的好，也要說出來。超出客戶預期的項目閃光點，要告訴客戶團隊的優秀。
項目完成的不錯，要告訴老板團隊的優秀。讓客戶讓老板知道你們團隊做的好，下一次他們才會給你們更充分的信任。
項目成員表現優秀的地方，不光要表揚，也要和上級說。你是和你團隊成員接觸最緊密的人，他們的優點別人不知道，但你知道。
所以他們優秀的地方，要宣揚，要讓別的部門知道，要讓上級知道。所以邀功也要上。
在幫派里，不能為兄弟們擋刀并***兄弟們前進的老大是不值得追隨的，弟兄們在你手下做事受盡委屈，爭不了一口氣，那這個老大也做不長。
技術出身的管理者中，我相信背黑鍋要上是大家都能做到的。但技術人員不善言辭，總是悶頭干活，不會表達。所以要適當學會邀功，為團隊邀功。希望大家都能學會邀功也要上。
別拋棄技術，它可能是你的救命良藥
做項目管理以后，尤其是像我現在這種一個人帶多個項目的情況。管理工作會占用每天極多的時間。
這是工作本身需要你做的，無可厚非。我想說的是，即便如此，也要保證自己對技術的學習。
了解新技術也好，寫寫開源項目也好，總之要保持對技術的持續學習。它總能在你需要的時候幫到你。學如逆水行舟，不進則退，與大家共勉。
總結
總體而言，我認為一個新手項目經理，要學會以下事情：
- 要學會帶領團隊成長，不要事必躬親
- 要多進行思考
- 要學會風險管理
- 要保持內心的強大
- 要學會邀功
以上，就是我想和大家分享的內容，其中很多點，我自己做的也不是很好，依然需要自我練習和努力。希望各位技術轉管理的同學，都能盡快適應自己的工作。
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
