很久以後，我才認識到一個好的項目經理要有很強的應付各種壓力和尷尬處境的能力，要有一種很強的個性（strong personality）。項目經理的壓力往往來自至少四個方麵：客戶、運營經理（Operations，大老板）、市場部、工程部。市場部為了爭取客戶，往往給出不切實際的承諾；工程部永遠是人手不夠（under resourced）；營運經理一到月底就數票子；客戶永遠在那兒抱怨。項目經理的一個主要工作是要平衡各個方麵。可惜的是，斯哥特既沒這方麵的經驗，也沒一種天生的能力。
在項目的初始階段，斯哥特與別人的矛盾以及他所造成的矛盾沒有顯露出來。這個LTE項目組裏有許多編碼高手，大家一起討論如何代碼、文檔等的存儲結構（repository），統一版本控製工具（CVS，ClearCase etc）、代碼編寫格式和約定。我以前在一個軟件屋工作過，我在公司東歐的一個軟件中心夫人幫助下，製定了整個產品軟件的開發流程（process）、規範和文檔樣本。當這些都搞定後，問題就來了。
斯哥特的第一個任務就是給要開發的每一個模塊估算工作量。現在回頭看來，這本不應該是他這種項目協調人式項目經理的任務。他去一個一個人地談。從開發工程師的角度看，為了保證軟件的質量，總是希望多要一些時間。另外，誰不想讓自己的工作壓力小一些？這樣，當斯哥特把所有的單個時間與任務相關性輸入MS Project後，工程交付日期根本無法滿足用戶的要求。
為了解決這一問題，斯哥特隻要再去一個一個地勸說。有的工程師當然是願意做一些調整，但有的由於種種原因，比較難以減少到斯哥特期望的工作量。雙方一爭執，有的說話就說得比較難聽，像，“你要認為在這個時間段內能完成，你做就是了。”這種話斯哥特受不了，就去馬克那兒告狀。馬克就各打五十大板。我有一次聽到馬克在訓斥斯哥特，大意是“我（馬克）要管理整個部門，你就這點微觀管理（micro-management）的事也要找我？”斯哥特就一直處在這種壓力下。
為了“更客觀”地估計工作量，他想出了一個現在看來是很荒唐的辦法，即讓兩個工程師來獨立地估計工作量。他有一次要印度來的無線工程師蘇班卡做RLC（Radio Link Control / 無線鏈路控製）中的一個模塊，蘇班卡估計要一個禮拜。他不喜歡這個估計，就去問網絡工程師肯尼相同的問題，肯尼說最多兩天。然後再轉回來問蘇班卡為什麽你們兩人的估計相差那麽大？弄得蘇班卡與肯尼也不和。這樣的事做了幾次，也就再也沒人願意對不是自己的任務發表評論了。但同事之間由於斯哥特而產生了許多不必要的矛盾，這些矛盾一直到這個組解散都沒解決。
工作量估算隻是許多事裏的一個。其它一些事，如有的同事在使用一個公司專用的版本控製係統（不是流行的CVS或ClearCase）時，由於生疏而造成在模塊整合時的錯誤，他害怕影響項目進度，就會抱怨說這是一個不應該的錯誤之類的話。有人會指出這應該作在計劃裏，但斯哥特總是無休止地與人爭辯，最後弄得不歡而散。類似這樣的事在斯哥特那兒發生過多次。
公平地說，斯哥特是個很努力的人。為了把工作做好，自學MS Project，考PRINCE2等。白天找人談事、應付客戶，後半下午再開始更新計劃，經常很晚才下班。組裏因為氣氛不好，很多工程師們就早九晚五。工期拖了就讓管理部門，即馬克和蒂姆，去對付。
為此我曾經與馬克和蒂姆都談過。馬克好像也沒什麽辦法，隻好自己去與有關人員談，有時鼓勵一下，有時就直接質問工作表現。我記得與蒂姆談得時候，他是有意在下一個項目中換掉斯哥特。如果在項目中間換，一個閑人就多出來了。為了消除或減輕部門裏同事之間的緊張氣氛，蒂姆還想法弄來經費，讓整個部門去蘇格蘭高地做團隊建設（team-building）。
項目就這麽吵吵鬧鬧地進行著，我們贏來的一個LTE客戶也就成了最後一個客戶。這個充滿希望的LTE項目或來成了一個“死亡之旅（death march）”項目有許多原因，項目管理隻是其中之一。我離開“高科技先鋒”去了“百年老店”後，才慢慢悟出整個事情錯在那兒。
請閱讀更多我的博客文章>>>
選擇“Disable on www.wenxuecity.com”
選擇“don't run on pages on this domain”
