專案經理應該避免的一些錯誤總結
本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃!
很多錯誤可以歸結為缺乏信任——但是比起開發人員,管理人員更難意識到這一點。
管理軟體開發團隊是一項艱鉅的任務。這在直線管理包括組織結構圖職責(職業發展、人力資源文案等)和需要為團隊的釋出表現負責時,任務就更加艱鉅了。在這種情況下,你會被要求徹底瞭解他們的日常表現,以評估他們的表現和推動改善,儘管事實上,他們做的事情是完全不透明的。這就像是被要求同時執教一支球隊和裁判一場你不知道規則的運動比賽。正如我所說,這是一項艱鉅的任務。
我同意這一點,如果你是一名經理,那麼在某些時候甚至是近期,你可能也是技術人員。或者,你並非技術人員,但由於你長時間地淫浸於這一行,所以耳濡目染知道了很多概念,至少在理論上能夠誇誇而談。除了這兩種情況,如果有人問你,例如Alice昨日編碼了什麼東西,那麼你能回答嗎。原因或許是由於缺乏經驗,或許是因為多年沒有程式設計而“生鏽”了,或許是無法跟上其他8個人的腳步,因為他們的工作對你而言是不透明的。
正如輔導/裁判你不懂的遊戲,你可以學習他們的身體語言和手勢。如果團隊中的所有成員表示出對其中一個同事的反感,那麼很有可能這個人做了“十惡不赦”的壞事。你不需要所有的上下文的線索,也不需要推動槓桿,因為這些事情一點都不難,自然而然地你就會掌握,要是它們是如此明顯的話。你正在導航一個非常艱難的障礙訓練。
但是同時很容易犯錯誤。這也是可以理解的。下面我會帶大家去認識一些比較常見的錯誤,並提供一些建議和想法。
微觀管理
開發團隊勞動創造的不透明性,很容易讓你覺得自己無法掌控它。而對這種情況的自然衝動又非常容易矯枉過正,試圖施加儘可能多的控制。絕大多數的微觀管理人員並不這麼看待自己,“我想成為一個難以忍受的控制狂”,而不是,“我只是現在需要參與進來,因為最後的時間期限快到了,但是當事情安頓下來之後,我會退出。“
麻煩的是,這必然會拖累團隊的效率。雖然你作為一個經理,因為完全瞭解所有的進度而感覺更高效了。但現實的情況是,你成為了瓶頸。你必須放手,接受你無法掌控一切的事實,甚至於你可能無法對團隊發生的一切做到心中有數。你需要信任你的團隊,如果你不能信任你的團隊的話,那麼你會遭遇比臨近最後期限更大的問題。因此,保持冷靜,對你的團隊充滿信心,放手讓他們工作。
不適宜的會議安排
迫使開發人員花時間對你詳細清楚地解釋事情,並不是唯一會影響他們生產力的途徑。在錯誤的時間段宣佈開會,也會影響他們的生產力。程式設計需要參與者進入一定的狀態,才能最高效地編碼。但是這種狀態並不是打個響指就能進入的。這是一個漸變的過程。
很多開發人員都經歷過這樣的喜悅,如果看到今天沒有會議來打攪他們的話,因為他們知道,這將能最大限度地提高效率。如果你開始給他們安排會議,毫無疑問會嚴重影響他們的情緒和生產力。而且,不同的會議時間所造成的影響也是不一樣的。早晨的第一件事,午餐前後,或下班前都是不錯的時間段,因為這些時間基本上不會打斷他們的思緒流程。但是,隨便拍板把會議定在上午10點和下午2點,那麼幾乎可以保證,他們那一天都沒辦法真正進入工作的狀態。
由於管理和軟體開發是我職業生涯中都經歷過的角色,所以我深刻知道在開發人員最富有生產效率的時候打斷他們是多麼容易。Paul Graham關於管理者和決策者的日程安排寫了一篇偉大的文章。這是忙碌的經理,甚至是前技術人員,很容易犯的一個常見錯誤,那就是根據自己的時間安排和對於資訊的慾望而制定會議時間。然後讓團隊為此付出沉重的代價,所以最好的方法是,儘量減少開發團隊的會議,然後把那些必須要開的會議安排在邊緣時間。
自作聰明的激勵措施
我以前就提到過這一點,關於要如何激勵開發組,你應該小心謹慎。對於開發經理所設定的有問題的目標,最典型的例子是自動化單元測試覆蓋率。換一個角度思考。你為什麼要設定這樣的目標呢?是因為你做了一些關於如何提高軟體質量減少缺陷的研究,還是因為一些文章,部落格,演講者告訴你,良好的軟體組具有較高的測試覆蓋率?你(不以編碼為生的一類人)是不是正在試圖弄清楚開發人員(以編碼為生的一類人)如何才能更好地完成工作,然後強迫他們這樣做?
這又回到了信任這個話題,你為什麼不能讓他們自己去弄清楚如何最好地完成他們的工作?如果目標是更少的缺陷或更流暢的版本,那麼為什麼不直接說出這些目標,讓他們去解決呢?我能理解,你既想要提供幫助,又想要履行這個頭銜的心情,但是在這條路的終點等你的並非是皆大歡喜。如果你將測試覆蓋率定為目標,並採取相應的措施激勵他們,是會成功……但是,是在測試覆蓋率方面。不過,這對你的實際目標不會有太大的影響。
因此,不要自以為是地想太多。直接告訴這些聰明人你想要什麼,並相信他們能夠完成你的期望。
信任是關鍵
各種問題層出不窮,但歸根結底可以得出一個結論。你必須相信你的開發團隊。這是可以讓你擴充套件並獲得成功的唯一途徑。
那麼如果你不信任他們的話,該怎麼做呢?嗯,這是人事問題了,而且這也是為什麼組織領導崗位存在的原因——做一些艱難的決定。你需要弄清楚團隊中的人員如何在專業方面值得信賴,你需要弄清楚哪裡去尋找和聘請值得信賴的人。你的主要職責應該是找到可以信任的人,僱用他們,為他們清理所有的干擾因素,包括你自己,讓他們能夠一往無前。你做好你的工作,他們就會做好他們的工作。
譯文連結:http://www.codeceo.com/article/pm-avoid-mistake.html
英文原文:Mistakes Dev Managers Make (and How to Avoid Them)
翻譯作者:碼農網 – 小峰
[ 轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]
相關文章
- 【分享貼】需求變更、專案延誤,專案經理應該如何應對?
- 總結一些,書寫 CSS 的時候,經常犯的錯誤!CSS
- 專案進度延誤該如何避免和克服?
- 人工智慧專案需要避免的9個錯誤人工智慧
- MES專案執行:3個要避免的錯誤
- 專案經理每天、每週、每月應該做的都在這
- 專案經理應該知道的97件事 --譯者序
- 【專案經理應該知道的97件事】三位一體的專案管理專案管理
- 應用程式邏輯錯誤總結
- 日常專案經驗總結
- 用vue做專案的一些總結Vue
- node專案錯誤處理與日誌
- 收藏 | 資料視覺化應該避免的誤區視覺化
- 1000多個專案中的十大JavaScript錯誤以及如何避免JavaScript
- 【精益生產】專案管理要避免的錯誤,請引以為戒!專案管理
- 使用 Vue 3 時應避免的 10 個錯誤Vue
- 《軟體專案經驗總結》
- 專案經理如何應對專案需求變更?
- Apple Search Ads投放中,應該避免的7個誤區APP
- 你是怎麼處理vue專案中的錯誤的?Vue
- CIO應避免的三個低程式碼部署錯誤
- 一個專案經理的切身經驗總結:測試用例可以被替代嗎?
- 專案經理面對專案陷困境該這樣採取措施
- Polar mask錯誤總結
- Python部分錯誤總結Python
- 對MediaPlayer的錯誤使用總結
- Akka實踐一些總結(java專案)Java
- LNMP 環境部署 Laravel 專案的一些總結LNMPLaravel
- 專案經理該如何面對頻繁的需求變更?
- Web前端開發應該避免的幾個思維誤區Web前端
- 產品經理和專案經理的區別,讀這一篇就夠了!(史上最全總結)
- golang中經常會犯的一些錯誤Golang
- 不會玩魔獸的專案經理不是好專案經理
- Go 語言中遇到 _func not exported by package_ 錯誤,應該如何處理?GoExportPackage
- 專案整合Swagger遇到的錯誤Swagger
- 應用中的錯誤處理概述
- 5個需要避免的CSS錯誤CSS
- 專案經理必學的6個工具,這些知識能否幫你避免專案管理崩潰?專案管理
- Hadoop安裝錯誤總結Hadoop