java開發管理者們常犯之錯誤與解決辦法

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

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

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

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

　　事必躬親

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

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

　　糟糕的定期會議

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

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

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

　　過度積極地加以激勵

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

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

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

　　信任才是關鍵

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

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