《常年寫代碼的程序猿轉為管理后經常會犯哪些錯誤?》
前言
大家都知道做程序員不可能從頭到尾一直都是一個人寫代碼研究技術,到了一定階段 ,自身有了一些能力經驗可能就會轉變為組長,項目管理,哪怕沒有升職轉崗,公司領導可能也會讓你去帶一些新人。
說下我的情況,我迄今為止是做了2年多java開發,6年android開發,4年項目管理(java和Android時間有重疊),在上家公司完成了轉型 ,剛進公司時崗位是 Android開發工程師,后面調整為 Android開發組組長->移動開發組組長->項目經理->事業部經理。來到現在的公司基本還是做同樣的事情,只是項目規模不一樣。看似順風順水的職業道路上,其實我犯過很多的錯誤,因為畢竟是技術出身,程序員思維,在很多時候考慮問題真的是慣性思維,沒有調整過來,所以自己回顧復盤后希望把這些問題記錄下來,希望能對后面的小伙伴有一點點幫助。
(ps:不同公司對團隊領導定義略有區別 技術組長、技術經理、技術負責人、項目負責人、項目經理 這些角色我下文統稱 經理。)
一、自身職責不清晰
有的公司升為經理后很多還會承擔一些編碼工作。在他們剛開始轉為管理后,第一個最大的問題就是自身職責不夠清晰,習慣性總是先考慮自己的工作內容,忽略團隊的工作內容,一個新功能模塊習慣性先考慮自己應該做的話需要做哪些工作,都有哪些技術難點。還是習慣性的把自己當一個開發來定位,沒有整體考慮團隊成員每個人的工作情況,每個人的工作能力,工作如何合理分配,會有哪些困難,后續進度質量如何跟進等,這點尤其需要注意。
二、親力親為
很多時候經理還習慣性自己做,因為寫了那么多年代碼,看到團隊的某些小伙伴進度出問題或者碰到技術難點時候都會習慣性的說“我來搞”。
一 、為了在團隊成員面前顯示自己有能力
二 、有的項目工期確實緊張,自己做感覺進度能把控住。
舉個例子:公司新開發一個項目,一期計劃先實現基礎功能,里面有個登錄模塊。
經理:這個登錄功能很簡單,xx項目里面有現成的,小明你來做吧,你參考改改兩天差不多就搞完了,明天搞好了讓測試測一下先。結果兩天后去問進度,
小明:““xx的接口調試一直有問題,界面切圖設計還差兩個沒給我;這個產品經理xx說需要再改一下”等等諸如此類的答案。
這時候有的經理一看到這種情況,想了一下項目上線時間。
經理:行了,你先別弄了,代碼提交一下,我來搞吧!你先改下禪道上其他bug吧。
這是個非常普通但確實很多剛轉變角色的人都熟悉的案例,很多剛升職的經理 角色轉變沒有那么快,都會犯這樣的錯誤。
經理這過程的問題,沒有站在小明角度考慮問題,他主觀的認為自己做這件事的時間和小明做那件事的時間差不多。工作能力、公司項目熟悉程度、和其他部門協調溝通默契程度 等這些 他認為自己和小明應該差不多。
1.安排任務沒詳細溝通確認細節,后臺接口完成情況、設計部門時間等
2.當出現進度未按期完成時,應該幫忙協調溝通確認部門外其他部門完成時間,而不是攬下來自己做。
3.殊不知“行了,你先別弄了,代碼提交一下,我來搞吧!你先改下禪道上其他bug吧”當這句話說出來,不但傷害了小明自尊心,打擊了他的積極性,讓其他同事也會對小明有看法,破壞團隊氛圍的大忌。
三、對進度過于樂觀
還是上面的例子,項目任務下來了,項目計劃排好后,工作任務也安排給小明了,都落實到具體責任人身上了,這時候經理就坐等結果去了,那么可以嗎?顯然從結果來看,是不理想的,因為中間缺少了檢查監督環節,沒有及時跟進發現問題。布置好、落實好不代表監督好,一切工作還要有監督。另外還要通過監督總結,才可能發現問題、處理問題、總結經驗、汲取教訓,才可能在最后把項目完成得更好。
對進度太樂觀了,可能就會導致結果有問題。監督跟進的環節是非常重要的,千萬不要全憑經驗來做事。因為很多都是都是變化的,多考慮目前實際情況,用數據和理論依據來思考問題。
四、重進度、輕質量
一個項目不僅僅要管理好進度,還要保證項目的質量達到可以交付的標準。這個也是一個非常難的事情,因為對于信息化項目來講,變化的因素太多了,有效的保證項目順利進行,一定要建立一套完善的運行機制才可以,給大家舉一個真實發生在我身上的例子。
舉例:當時給某公司研發一套信息化平臺,原定2018年10月20號給客戶交底培訓V1.0版本的平臺,我當時為了確保萬無一失,和開發定的提前兩周封版,不增加任何功能,只做測試修復問題。
基本提前一周完成修改復測,最后幾天每天都登錄測試演示流程。2018年10月19號晚上8點左右還又和產品經理一起完整走了一遍流程,確保沒問題,開開心心回家了。第二天直接從家里面出發去客戶現場,提前一個小時到了現場,連上wifi開始測試,這時我發現演示的賬號admin登錄不上去了…緊急給開發打電話處理,開發這時候還沒有到公司(艱難)…后來半小時后開發說處理好了,讓我重新試一下,結果登錄上去以后 ,界面也有問題了…很多模塊權限不對了…后來當天一半內容用ppt完成的講解…
回來后,得知是其中一位開發人員臨時清理數據誤清除了其中的一個字典數據表,影響了整個系統的邏輯…當時我的心情簡直難以形容…每次我或者產品經理外出給客戶演示或者培訓時都交代不要動服務器的任何東西,也不要做任何更新操作,都在本地測試環境操作。竟然還會發生這種事…
后來我仔細回想了一下這個事情,其實是自己的管理機制有問題,之前我們的項目組后臺更新線上平臺和數據都是各自負責自己模塊,也就是說誰都可以有權限動線上的東西,假如當時只把更新代碼,操作線上系統數據庫權限等權限只分配給一位后臺開發人員,他每次更新系統版本或者操作修改線上數據庫之前都和我溝通一下,是不是就能很大程度的避免這種情況呢。
總之,項目經理對項目的管理不能只重視進度 ,不重視質量,任務安排下去完成后,要進行有效的監督檢查,制定完善的機制確保項目質量,才能保證項目按時正常交付。
五、工作重點、目標不明確
有些經理太過關注當下急需解決的事情,而缺乏遠慮和遠見。每天都在忙于處理各種突發緊急問題,做的都是緊急不重要的事情。對問題做出反應是人的本能,這讓經理感覺良好,因為他們在不停處理問題,而且別人也會看到他們在做事。
時間久了,經理還習慣了這樣的方式,典型的表現有以下幾種:
1.每天不停的處理各種看起來很緊急的問題,各種公司群,公司郵箱反饋回復。
2.在工位上大聲給項目團隊成員下達各種指令。
3.給公司外面的客戶或者領導打電話,不聊重要的事情,扯閑篇扯半天。
4.有的甚至沒工作的時候也要裝作很忙的樣子,找點八百年不維護的項目讓團隊的人去做優化。。
5.沒事喜歡往自己上級領導辦公室跑,去匯報一些雞毛蒜皮的小事情來刷存在感。
6.從來不認真分析團隊規劃、團隊文化建設、項目更新、技術創新等更有意義的事情。
六、缺乏擔當
舉例:項目原定10號上線,結果因為bug太多拖延到了15號。上級找經理問什么原因導致項目延期,晚上線了一周時間,給公司損失了搶占市場的絕佳機會。
經理:領導,這個事情是這樣的,本來功能都開發完了,也都測試完了。后來小明改了一下xx模塊,導致項目其他有關聯的模塊也都出了問題,bug太多我就決定先不上線,我安排他緊急加班處理的,同時我也讓測試和我一起加班復測了,復測都沒有問題后才上線的。
領導:好的,我知道了!
看似經理處理的很妥當,而且也表明自己在這個過程中和團隊加班一起處理跟進了,但是實際上經理把鍋甩給小明了,不是自己造成的!典型的甩鍋行為。
如果他能這樣回答,就好很多,也體現了作為一個領導的擔當:
“領導,這次的問題都是我對項目風險預估不足,中間出了些問題,好在我們團隊的人都非常給力,連續加了好幾天班,大家一起處理好了,已經及時上線了,延期了幾天上線,下來我會復盤總結,保證以后不出類似的問題”。
所以作為領導一定要搞清楚自己的定位,只要是你領導的團隊,他們當中任何一個人出了問題,你作為領導都有責任,不是說誰改錯找誰,他出的問題,你在團隊內部溝通,而不是去你領導那把自己團隊的人推到前面去背鍋。
合格的領導都有一個共同的優點,那就是有擔當,不合格的領導也有一個共同的缺點,那就是沒有擔當,沒有擔當就是這個人綜合工作能力的表現,想好好地開展工作和向上發展,就應該在合適的時候,合適的場合,選擇合適的對象,承擔起自己這個崗位應該肩負的責任,這才是正途!
七、溝通不明確
這個也是常犯的錯誤之一,交代任務后沒有確認團隊成員是否完全理解,是否真正的知道自己所要接收的任務目標是什么。尤其對沒有經驗的一些團隊成員,比如剛招進來的實習生,在傳達任務的時候一定要說清楚,并且將一些細節以及需要注意的問題都一并說清楚。其實這個最好的辦法是:安排任務后讓任務接收人復述一遍,這種辦法是最有效的。
當然自己在接收領導任務的時候也是一樣,老板有事情交代給你的時候,也要在接受任務的時候問清楚具體細節,這樣最后完成的結果才不會有太大的偏差。
八、抱怨、情緒化
有的時候項目周期客戶要求的上線時間要越快越好,給的開發周期非常短,客戶和領導一直催,一直問進度,部門員工還得讓他們不停加班趕進度,有的員工肯定會有怨言。作為團隊的領導在這樣的壓力下,通常難以理智冷靜面對各方需求,往往會做出習慣性否定、習慣性接受,在得不到滿意反饋時習慣性抱怨。
剛上任需要通過一段時間了解組員和項目的情況和問題,拿出合適的方案和老板協商并改進,不能盲目否定和接受別人的意見,更不要抱怨。因為作為團隊的領導一旦將不好的情緒展現到團隊成員面前,那么這個團隊的整體氛圍一定很差,工作效率也不會很高。
九、項目風險認識不足
互聯網的信息化項目從立項到交付驗收整個過程看似簡單的流程,其實充滿了各種各樣的風險,項目的各種不確定性實在太多了,需求、決策、團隊成員、進度等等。
這就需要我們對項目有整體的全景認知,認真詳細的提前考量各種約束風險,并且在各種實戰中積累出一套成體系的風險管理方法實踐,用這樣的方法做風險管理,我們才能做到胸有成竹,將風險降到最低,最大化的提升項目交付效率。
這需要在項目早期考慮這些風險,最好按類別逐項列出,一般的風險大概涵蓋以下幾類:
1. 人員風險
如:人員請假離職、項目人手不足、任務人員分配不合理、新加入成員對項目不熟悉、項目人員工作態度技術能力、項目組人員之間有矛盾等有問題
2. 需求風險
如:需求規劃不全面、需求不斷新增、需求不斷變更、部分需求存在技術難點、需求變更未及時通知各相關參與人員等
3. 技術風險
如:復雜需求技術存在難點、需求需要采用三方技術,技術選型周期過長、開發人員技術水平問題,做出來功能漏洞百出,開發環境不穩定、技術方案設計存在漏洞等
4. 外部風險
如:需和其他廠商配合開發,配合溝通有問題,調用三方服務不穩定、項目組外支持人員配合默契度不夠等
5. 環境風險
如:服務器、網絡、域名證書、手機等各種硬件測試設備不到位等
那這么多的風險如何應對呢?
1.需求調研多花時間確認細節,多在這個環節上花心思,最好通過幾輪的討論確定設計方案。
2.制定完善的流程,每件事對應到具體責任人來負責。
3.采用合理的管理工具及平臺,提高溝通協作效率。
4.出現任何問題,及時響應處理,不要拖延。
5.和各方人員溝通時,調整好心態。
十、不注重團隊建設
說起團隊建設可能很多人就認為是叫大家一起晚上吃個飯、K個歌,放松Happy一下,這個起作用嗎?起作用,但是這種方式并不是最植入內心的,只是增加大家團隊凝聚力的一種方式。人都是感情動物,在和團隊成員相處的時候一定是多換位思考,團隊成員佩服什么樣的領導,真正喜歡什么樣的工作氛圍其實大家應該也都清楚,畢竟都是從底層員工成長上來的。
好的領導我認為一般具備以下幾個特點:
能力、技術水平極為突出
情商非常高,有親和力,所有人和他相處都感覺很舒服
幫助團隊成員成長
非常有擔當
做事條理清晰、邏輯思維縝密
良好的心態 很少有負面情緒
員工心里面喜歡什么樣的領導:
1.能幫我解決我碰到的技術難點
2.能給我的工作提供思路和方法的
3.跟著他可以學習提高我的技術
4.能幫我爭取漲工資的
5.出了問題可以幫我頂雷的
所以綜上總結:團隊建設最核心的兩點我認為是尊重和幫助他們成長。
1.尊重
員工是員工,但是首先是個人,每個人在團隊中都希望被他人尊重,不能根據團隊成員的技術水平高低、項目經驗多少來貶低或者嘲諷他人,安排工作的時候有意或者無意的讓別人下不來臺。舉幾個反面例子,大家自己感受:
開會安排工作:xx模塊很簡單,所以這個就小明你來做。(當眾貶低他人)
小明遲到,當眾批評:你要再遲到,這個月的獎金就給你都扣了(粗暴解決問題)
這么簡單的問題搞不定嗎?大哥,你這基礎太差了(當眾貶低別人)
下次再這么多bug,你自己找老板說原因吧(用領導壓員工)
和其他同事說xx技術太差了,不能把這個讓他做。(背后貶低別人)
項目出問題,說是xxx的改的出了問題。(甩鍋行為)
獎金分配根據自己好惡及小圈子分配(標準不一,不透明)
工作任務安排不合理,強行壓縮工期(工作安排不合理)
項目取得成功,功勞歸為己有。(貪功,缺乏團隊意識)
制定各種扣錢制度(無能表現)
不多說了,有這些行為的各自對號入座吧…希望各位迷途知返
2.幫助他們成長
團隊的成員工作積極性是怎么被激發的?我認為就是他們可以在這個團隊獲得足夠多的成就感,這種成就感基本都是在工作中獲得的。
反面例子我就不舉了,對如何使團隊成員獲得成就感,我談下我自己的看法:
多贊美和鼓勵團隊員工
多和他們溝通,傾聽他們內心真實的想法
盡量不打斷他們說話,耐心聽完,然后再發表意見
他們犯了錯誤,及時指正提醒,不能放任不管
不要幫他們做任務,可以指導方法
承擔責任,不要把問題的責任都歸到團隊成員的身上,讓他們背負壓力
了解熟悉每個人的長處和短處,合理安排任務
其實這方面的經驗,我自己也在不停探索中,其實中國式的管理沒有那么強的條條框框。因人而異,因事而異,需要自己體會。同樣的方法對不同的人可能效果不一樣。但是多用心,拿出自己的真誠來面對團隊的每個人,我認為結果就不會太差。
還有10多天,就是2022年除夕了,提前祝大家新春快樂,身體健康,闔家歡樂!
Android 開發者 軟件開發 項目管理 ProjectMan
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。