一個敏捷教練中止越軌列車的故事

作者 Richard H.B. Sun

我必須承認，我的管理經驗是不足的。最近一次我對下屬的工作處理的介入讓我學到不少我以前沒有經歷過的工作經驗，在此和大家分享一下我的認識和感悟。這件事情的處理，一般人可能認為這無異於辦公室政治風雲，對我來說這是一次很好的管理經歷。讓我認識到如何使用敏捷教條對管理方面的問題進行分析，如何採取合適策略來解決此類問題。

數月前，我被分派到一個新成立的小組做QA Lead，開始了我的管理“事業”。當時只有我一人協助三個開發者。隨後，增加到協助4.5個開發人員，外加兩個客戶端開發者。很快我就發現自己被很多事情所包圍，無法在短期內完成一下子堆積起來的工作。也就是這時，我和我的上司D提議增加人手。當時是2007年6月，正好沒有人手，我就按照自己知道的敏捷互動知識，對自己的工作進行安排，一件件地處理。到了得心應手的階段時，終於有人手可以分配過來時（2007年9月中），我得知一個我覺得能力很差的高階工程師A會被轉移到我的組裡幫我。我的第一個反應是，“能不能分配其他人手到我的組裡。”我的上司D說，“先讓這個人過來試試。”我就沒有多說什麼，那個時候我就已經預見了今天我不得不作出的處理。

我的第一個反應是從兵法“用人不疑，疑人不用”的角度產生的，當時我們組聘用了A，我們在面試時看好這個人，但是僱用之後我和他的一些互動中發現此人除了知道如何使用Visual Studio .NET 2005，其他什麼都不會；而且他還不願意學這些能夠幫助他適應新環境的東西。後來因為A是以高階工程師，開始成為我當時所在組的Team Lead。作為Team Lead那一段時間，我們整組發現他無法對管理層作出的無禮要求進行抵擋，甚至談判，只知道如何一味地向管理層妥協。然後自己不身先士卒，而是把一些重要的東西攤派給屬下。然後自己就開始進行一些無關緊要的流程改進工作。我是看在眼裡，記在心裡，因為我很早就被調到我現在的崗位，所以也沒有說些什麼。我知道，這樣的人不能重用，我對他沒有信任感。

就這樣到了九月底，我感覺可以讓他轉移到我的組裡開始前期準備工作。我當時的感覺是，我要尊重我的上司D的安排，盡力和他一起攜手合作。我馬上就碰到了一個問題，他無意從自己的專案中擺脫出來，他的託詞是，“我需要一點時間完成我手上的事務，這樣可以很好的交接給其他人。”我就給了他一個星期，同時也和信任的Team Lead B進行了溝通。B原來是個開發者，在9月份轉來做QA，因為他的經驗豐富，而且A在組裡不做正事，其他組員意見很大，所以A轉到我的組後，就丟掉了Team Lead的頭銜。我和B的溝通是，A應該把工作重心放到新的工作上去，而不是找藉口推託自己應該承擔的責任。B向A轉達了這樣的意向，但是一時間沒起什麼作用。

隨後，A以領導的名義向我們的上司D回信，列出我們這組人在08年應盡的義務。我一看，心裡就騰起一股火氣，他自己承擔的任務裡，沒有一項是和他新工作相關的，而且每個都要花費不少時間操作。這不是明擺著要消極處理他的新工作嗎？我很不客氣地回信，並抄送一封給我的上司D，表示了我對他的態度的不滿。當時我的感覺是這個人不適合在我的組裡做事。精簡敏捷開發的宗旨是團隊需要集中注意力處理當前最重要的事務，在最短時間內用最便宜的手段為整個商業組織創造價值，我的組主要工作是設計測試案例，開發測試案例是給整個開發組織的最大價值，而不是把時間花費在無意義的流程改進或是為高層收集測試資料，沒有人設計開發測試案例，收集的測試資料是沒有意義的。而這種雞毛蒜皮的小事正是A最感興趣的事情。我寫的信讓D很不高興，因為我寫得很不留情。這也是沒有經驗的管理者應該注意的，盡力避免這麼直接的舉動，多進行面對面溝通，實在不行才使用這種下下策。我和B溝通後，B又寫信給A說，你的首要任務是對新責任負責。A回覆說，我不覺得這個新專案有什麼重要的，大家對此都沒有什麼重視，所以還是讓我完成我的測試資料收集。A的信送出後，我也沒來得及看。一天後B找到我，跟我說了這事，我才知道B也火了，也寫了一封措辭嚴厲的信給A並抄送了我們的上司D。當然D也找B談話說不能這麼不留情面（大家知道了，要先進行面對面溝通，之後才能作出這樣肆無忌憚的舉動）。

又過了一個星期，事態有所改進，開發組的上司H也不知從哪裡知道了這件事，寫信給A說要把工作重心轉移到我分配的事務上。然後我們上司D也對A做特別安排，讓他全力幫助我。A態度馬上大轉變，說他會全力和我一起協作，我仗著我有令箭和A的態度轉變，就開始給他分配任務，每天和他進行2分鐘的Scrum。同時也幫他開始建立開發環境，我花費了三天，才把他的開發環境整理清除，他被聘開始工作到現在，對自己的開發環境維護什麼都沒有做，一切都是亂七八糟，然後自己還不懂到我們的開發測試Wiki上找答案。讓我可笑可氣的是，他拿了一個很簡單的問題問我如何處理。錯誤資訊就在他面前，讀一讀，再考慮一下就能解決，A的處事態度怎麼能這麼不認真，還是能力不行？三天之後，一切都搞好了，我覺得，A也該開始閱讀專案文件，並向我向開發者提出大量的問題。

事實還不是我想象的那樣，時間到十月初的第二個星期，我在週一分配了任務讓他閱讀文件，我給了他一個星期。我認為，作為高階工程師，是知道自己該做什麼，我的分配是很清晰的，閱讀文件，準備寫測試計劃，有任何問題，儘管問我。週五中午B跑來跟我說，開發部上司H很不滿A不準備在下一週進行程式釋出測試（Release Verification Testing），我說我完全支援A的決定，心裡還有高興，A終於可以專心做正事了。我甚至對B說我覺得A需要一點時間閱讀文件。如果他能專心做事有進展，我會幫他處理這些雜事的。下午，我馬上發現我的想法是極大錯誤，A和開發者開會時淨問一些沒有一點技術背景的問題。我坐在那裡看著開發者艱難地解答他提出的問題，還有他不著邊際的回覆，心裡急啊！最後我坐了35分鐘，藉口離開去找B反映這個發現。我容忍了A四個星期的不作為，他已經開始破壞我的全盤測試計劃。

於是我和B又找了我們前任QA Lead —— J。J是個德高望重的人，A之前的QA Lead，給了我們的建議是，直接找上司D。於是我和B起草了一封信說A一個星期下來沒有實質性進展，反而有負進展。他的態度是我們不能容忍的。希望D能替我們安排一個好的解決方案，我們對事情發展到這個狀態已經無能為力了。週末，我仔細想了一下，和D見面時不能透露無望的神情。讀者如果看過《教父》，知道Don Corleone在電影一開始接見好萊塢大明星Johnny Fontane，Johnny希望Don幫他擺平一個電影角色的，當時他無望地對Don說，“Godfather, I don’t know what to do…”Don的反應是痛斥Johnny的無能，說“You can be like a Man!!...”我當時的感受可能就和Johnny Fontane差不多。我在週日晚上仔細考慮了一下，知道自己不能象廢物一樣給上司D彙報這一情況。而且Ken Schwaber在他的書中提到，Scrum master必須能夠對情況和發展作出合理判斷，把各種可能發生的事件和後果進行總結歸類，再同管理層進行溝通，幫助管理層理解種種處理的不同後果。我列舉了幾種處理方式：

1. 調離A，在分配新的人員給我。後果是要重複一系列培訓，開發環境設定等工作。
2. 分配新的人員給我，讓A和這個新人一起協作相互牽制，如果A合作不順就要。後果是我不需要太多介入培訓新人，幫助設定開發環境的問題。而且我可以繼續我的測試工作。但是要更多地管理。
3. 繼續給A一定的時間，我會更嚴格地監管A，後果是我要花費很多精力監視，甚至介入A的工作，我的測試進度將受影響。

星期一，我和D見面，D馬上和我說了他的安排，讓A在我手下再幹三個星期，然後他能轉到其他組去。我從D那裡得知A上一星期把時間都花在測試資料收集的工作上了，還表示了他對自己現在工作的不適應，希望調離。我可以看得出D和我一樣對事態非常失望。D要我和A商量好三個星期必須完成的任務，然後等A休假回來後在安排A的工作事宜。我帶去的事情處理方案，和收集的彙報都沒有用到。下午，我從D那裡接到通知說A馬上就轉到另一個組。事情就這樣解決了。

讀者會問這件事和敏捷開發有何關係？我的感觸是，敏捷開發是不能容忍開發進度中任何能夠造成進度停滯的問題。敏捷開發必須像耍獨孤九劍一樣連貫自如，任何問題必須從問題一發生就馬上解決，同時不斷改進，根據情況不斷調整戰術保證進度的高速進行。在這件事情上，上司D一開始犯的錯誤就是高估了A的技能。我覺得他對A一直抱有一種沒有理由的錯誤判斷——A是個處理能力和技術能力強的專家，其實這和現實差得太遠了。D只是個經理，他不做技術性的工作，是無法瞭解下屬的真實情況。這是一個典型的例子，不懂技術也不懂下屬能力的經理會誤判下屬的真實情況。或多或少的蠻橫安排資源，不接受團隊回饋也是D所犯的錯誤。敏捷開發的一個重要手段是團隊自我管理，也就是在陣地上的士兵比在指揮所的軍官更瞭解戰場戰況，有時將在外，必須擁有“君命有所不受”的權利。上司D經常如此蠻橫地瞎指揮，下屬一般都以自己最好的判斷來盡力實施他的要求，但是做不到的時候也只有和他彙報，獲得他的理解，我想這是很多技術人員經常碰到的問題。

我的錯誤就是我懷疑了但是沒有及時直接向D溝通我的擔憂，但是就算我及時溝通了，也不會給我多大幫助。因為當時的人事資源就是那樣的，我沒有拒絕的餘地。我所做對的，是對我所能夠控制的局面進行了有效的監控；我利用了我所學的敏捷開發知識準確地判斷了事態可能的發展；我對事態發展作出了一步步的盤算及後果的考慮，作出了先影響甚至控制A的戰略，然後作出瞭如果A不合作，必須讓更高管理層替我解決問題的戰略。最後是在管理控制的同時收集下屬的不當所作所為，作為我的戰略資源，同時發動我的同事，我的上司對我進行支援。整個事件從發生到解決，花費了一個多月時間，我用最迅速比較妥帖的方式處理了這件事，而且沒有耽誤我自己的測試工作。第一次對專案和團隊進行管理，我對自己的表現感到十分滿意，近幾年的敏捷開發實踐畢竟是學有所成。但是我也意識到自己要好好學習更好人際溝通，在管理方面更加完善自己的能力。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-374659/，如需轉載，請註明出處，否則將追究法律責任。