作者：zer0black
來源：https://www.cnblogs.com/zer0Black/p/9571987.html
作者：zer0black
來源：https://www.cnblogs.com/zer0Black/p/9571987.html
我是一名新手項目經理，轉項目管理崗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. 要學會邀功
以上，就是我想和大家分享的內容，其中很多點，我自己做的也不是很好，依然需要自我練習和努力。希望各位技術轉管理的同學，都能儘快適應自己的工作。