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

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

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

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

事必躬親

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

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

糟糕的定期會議

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

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

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

過度積極地加以激勵

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

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

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

信任才是關(guān)鍵

雖然這個主題此前已經(jīng)被論證過無數(shù)次，但我們?nèi)匀恢档脤⑵渥鳛榭偨Y(jié)陳詞加以重視。大家必須信任自己的開發(fā)團隊，也只有這樣我們才能夠?qū)崿F(xiàn)規(guī)模擴展并取得成功。

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

　　哈爾濱品用軟件有限公司致力于為哈爾濱的中小企業(yè)制作大氣、美觀的優(yōu)秀網(wǎng)站，并且能夠搭建符合百度排名規(guī)范的網(wǎng)站基底，使您的網(wǎng)站無需額外費用，即可穩(wěn)步提升排名至首頁。歡迎體驗最佳的哈爾濱網(wǎng)站建設(shè)。