從技術轉管理,我做了什麼來拯救自己?

zer0Black發表於2018-09-04

我是一名新手專案經理,轉專案管理崗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.要學會邀功

以上,就是我想和大家分享的內容,其中很多點,我自己做的也不是很好,依然需要自我練習和努力。希望各位技術轉管理的同學,都能儘快適應自己的工作。

相關文章