管理一支軟件開發隊伍無疑是一項艱巨的任務。而一旦在管理工作中囊括了組織結構職務（包括職業生涯發展與人力資源管理等）乃至團隊業績責任制度，其難度又會更度攀升至新的量級。在這種情況下，管理者需要深刻理解其日常業績表現，從而評估自身工作成效并推動改進舉措——然而事實上，團隊成員的工作內容往往并不具備理想的透明性。而在執行相關工作時，管理者往往相當于同時扮演球隊教練與比賽裁判的角色——更可怕的是，比賽規則通常并不明確。因此正如前面提到，這不啻為一項艱巨的任務。

作為項目管理者，大家應該已經在特定時間點上——甚至是最近——對相關技術有所了解。即使從未深入了解技術方案，大家也一定對其有著長期接觸并熟知其中的大量基礎性概念，至少對其抽象理論較為熟稔。不過無論如何，我們都不可能明確知曉團隊中的特定成員昨天編寫了哪些代碼內容。總而言之，也許是由于缺乏技術經驗、也許是因為多年來未進行編程而導致知識遺忘、又或者暫時沒有關注其他成員的日常工作進度，總之在管理者眼中，團隊成員們的工作內容并無透明度可言。

就像是在不了解相關規則的情況下對某種體育項目進行指導或者裁判，我們往往可以通過肢體語言及手勢逐步弄清當前態勢。如果團隊中的全部成員都對某種措施表達反感，那么其中一定出現了嚴重問題。雖然項目管理者在工作中或多或少會引入部分背景線索及調整手段，但將全部線索乃至手段納入管理機制仍然極為困難。在這種情況下，管理者的引導將不再是種指南——而更像是一場預先設置好的障礙訓練。

在這種情況下，犯錯的可能性亦會大大提高。外行指導內行總會引發無數矛盾，下面我們就將一同了解其中部分常見失誤，并探討通過哪些可行性方法——而非模糊的思路——對其加以解決。

事必躬親

開發團隊中的成員往往會不自常見地建立起一種非透明化運作流程，使得管理者感到自己失去了控制能力甚至被排除在外。面對這樣的情況，我們的下意識反應就是采取矯枉過正的舉措，并試圖通過多種手段盡可能提高控制水平。大多數事必躬親型管理者并沒有意識到自己存在這種問題，即他們已經成為那種“一切都要插手介入的控制狂”。相反，在他們看來，其各項工作只是“想要真正參與進來以符合時間規劃，當事情解決后我會立刻退出。”

[[163209]]

不過問題在于，這種方式會給團隊效率造成極大影響。作為管理者，這種行為可能會讓你“誤以為”團隊效率有所提升，因為你能夠掌握每項工作的發展進程。然而，實際情況是管理者自身這時已經成為一種瓶頸。我們必須放任成員們處理任務，并接受這種不受控甚至在一定程度上無法感知的現狀。這有點像拍電影，導演要做的不是用一個個枯燥的長鏡頭將所有細節展現給觀眾。相反，管理者需要信任自己的團隊——如果做不到這一點，那么管理者本身將成為比時間安排更難搞定的大問題。因此，保持冷靜與對團隊成員的充足信心，他們的自治效果絕對會讓你滿意。

糟糕的定期會議

強迫開發人員拿出寶貴時間解釋其執行細節還僅僅是毀掉生產效率的手段之一。另一種常見錯誤在于選擇糟糕的時間點召開定期會議。編程工作要求各位參與者始終處于流動狀態，從而***程度發揮其有效性與積極性。然而這種流程絕不能簡單用上下班打卡來衡量——而是一種非常奇妙的推進狀態。

很多開發人員都經歷過把一整天時間用于召開不間斷會議的狀況，如果他們認同這種作法并將其視為提升生產效率的必要手段，那么整個氛圍將非常和諧。然而一旦以強制性舉措刻意安排其參加會議，那么開發人員的情緒乃至生產能力都將受到嚴重影響。另外，會議的召開時間也很有講究。選在剛剛上班時、午餐之前或者之后往往效果更好，因為這些不會打斷開發人員的既定流程安排或者工作思路。然而，一旦把會議時間定在上午10點或者下午2點，那么其結果幾乎必然導致與會者們這一整天都無法進入工作狀態。

我的職業生涯基本可以劃分成管理工作與軟件開發工作兩大類，而且我打剛上班時就意識到，自己不能總是把時間浪費在考察開發人員的生產效率身上。這種錯誤常見于工作繁忙的管理者群體，即使曾經從事過技術方面的工作，他們仍然傾向于由自身時間規劃出發組織會議并獲取信息。很明顯，這種作法會令開發者本身付出沉重代價。因此盡可能減少開發團隊會議活動并幫助其將主要精力集中在真正的日常任務上才是明智之舉。

過度積極地加以激勵

大家在對開發團隊進行激勵時，同樣應該抱有審慎的態度。在這方面，最典型的例子就是開發團隊管理者會設定一套自動化單元測試方案。我們不妨從這樣的角度思考問題：為什么要設定這樣一個目標？是不是因為大家針對提升軟件質量及降低缺陷數量進行過深入研究，而大量文章、博客乃至高人氣講師認為高測試覆蓋度正是衡量軟件團隊出色與否的關鍵？本身并不需要實際編寫代碼的管理者是否在努力向開發人員（需要實際編寫代碼）講解如何才能更好地完成工作，并迫使他們按照管理層的思路行事？

這就又回到了之前提到的信任度話題，不過我們為什么不讓開發人員們自行找到最理想的任務完成方式？如果目標在于減少缺陷或者使發布流程更為順暢，那為什么不直接提出要求并允許團隊成員自己找到可行途徑？我很明白，大家是希望幫助團隊充分發揮業內總結出的優勢舉措，但這種思路無法讓開發人員在日常工作中獲得快樂。如果大家強行引入目標測試機制并要求團隊成員遵守，那么他們最終實現的也只能是目標測試機制的部署——而非真正重要的項目發展訴求。

因此，不要過度干涉成員們的執行思路。為這些睿智的同伴們提供必要幫助，同時相信他們有能力將理想轉化為現實。

信任才是關鍵

雖然這個主題此前已經被論證過無數次，但我們仍然值得將其作為總結陳詞加以重視。大家必須信任自己的開發團隊，也只有這樣我們才能夠實現規模擴展并取得成功。

如果無法給予信任，那么我們該怎么辦？這個問題可以說見仁見智，而企業***的存在意義也在于此——負責制定艱難的決策。大家需要想辦法讓團隊內的成員在專業層面具備可信度，同時發現并雇用那些值得信賴的潛在成員。大家的主要職責應該是找到值得依賴的人員、對其加以雇用并排除包括自己在內的全部干擾因素，從而保證他們能夠按照自己的理解完成工作。我們有我們的工作，他們有他們的——這就是所謂各司其職。

原文標題：Mistakes Dev Managers Make (and How to Avoid Them)

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】