初為項目經理

        這一天終于來到了：你從一個一線開發人員被提拔為項目經理。也許你一直在期盼，也許你心裡還忐忑不安，也許這是你的職業發展選擇，也許你隻是不情願的答應老闆“試一下”。不管哪種情況，可能你并沒有項目和人員管理及上司的教育背景或者教育訓練經曆。

       上司和管理（這兩者是不同的）遠非簡單的與Dilbert的老闆背道而馳（譯者注：Dilbert 是一個漫畫人物，以“擁有”一個“白癡老闆”而著稱）。當你計劃如何做好項目管理時，考慮采取以下列出的行動。也許你想做的事情很多，但下面的這些建議會幫助你集中到那些能提高效率（你自己的效率和團隊的效率）的事情上。

設立優先級

        你要着手的第一件大事很可能就是有意識的設立你作為項目經理的優先級。盡管你可能因為各種原因還需要很大程度上參與軟體的開發，但除此之外，你還有一些新的職責。很多新任的項目經理都擺脫不了技術的誘惑，以緻忽略了項目成員向自己尋求的幫助。

        富有效率的項目經理知道，他們最高優先的就是為項目成員提供服務。這些服務包括：指導和教育，處理沖突，提供資源，設立項目目标和優先級等等，适當時也要提供技術指導。我發現，把自己視為為成員工作，而非監工是很有價值的。不管你正在做或者将要做多重要的事，來你這兒尋求幫助的項目成員應該有“非屏蔽中斷”（譯者注：非屏蔽中斷是一個硬體術語，此處意即最優先的）優先級。

        你第二優先的是讓你所在組織的客戶滿意。作為一個項目經理，如果你不再涉足産品的一線開發，也許你很少有直接的機會可以讓客戶滿意。但你必須為你的項目成員創造一個環境，使得他們在這個環境下工作，可以最有效的滿足客戶的需求。這是項目經理的一個重要職能。

        你第三優先的是你自己的事情。可能是一個與項目有關的技術問題（當然也是你感興趣的），也可能是你的老闆要你做的某件事。但當這些事與上面兩個較高優先級沖突時，你要做好延後處理的準備。

        你最低優先的是那些純粹取悅你的老闆的事情。在一個正常的組織（非Dilbet 式的組織）中，如果你做好了前面所說的更重要的三件事情，你的老闆已經是非常驚喜了。盡管并非每個人都那麼幸運可以在一個“正常”的組織工作，但還是努力做好這三件最重要的事。把注意力放在盡可能的幫助下屬富有效率-- 并且快樂-- 上，而不是取悅于那些“上面”的人。

分析你的技能差距

        初為項目經理，通常你會意識到你在上司和管理技能方面的差距，除非你已經為這個新職位做了充分準備。你有很強的技術背景，可能這也是提拔你上司技術團隊的一個原因，但你還需要一些其他的技能。你需要客觀的評價自己的長處和短處，并且着手縮小自己的差距。

        做軟體的人常常被認為缺乏出色的交際能力。你需要加強你的人際處理能，諸如調解沖突、說服他人、“推銷”自己。你需要應付一些不想應付的場面，比如解雇你的下屬、在進度上“讨價還價”、為争取下屬的績效“吵架”。

        伴我開始經理職涯的是傾聽（Listening）技能的課程，我覺得很有價值。一線開發時，往往我們都有過人的精力來表達自己的技術觀點。但作為管理人員，更需要一種包容和聆聽的工作風格和交流方式。然後，從“聽”的位置走到“說”的位置，你需要提高你的演講（Presentation）技能。如果你對在公衆場合演講感到不适，你需要接受一些專門的演講教育訓練。這對你今後的工作很有好處。

        作為一個項目經理，協調他人的工作、計劃和跟蹤項目、必要時進行項目回溯并采取糾正措施等等都是你的職責。可能的話，接受有關項目管理的教育訓練，學習如何設立優先級、如何主持高效的會議、如何明白無誤的溝通等等技能；多看一些項目管理和風險管理的書籍和雜志，比如Project Management Institute 的月刊《PM Network》（譯者注：你也可以從《PMT 評論》獲得大量有價值的軟體項目知識）。你還可以從SWCMM（軟體能力成熟度模型）中找到很多有關軟體項目管理的有用建議。

定義“ 品質”

        盡管絕大多數人都認真對待品質，也想生産出優質的産品；但是，有關軟體品質的定義仍存在很大争議，比如高品質是“足夠好”還是更為經典的品質觀點--“無缺陷”。為了上司你的團隊走向成功彼岸，你需要花些時間和你的下屬以及客戶一起來明确，對于他們，品質意味着什麼。

        你的下屬和客戶是不同的兩幫人，他們很可能對品質沒有一緻的看法，也就容易抱有不同的目的。如果客戶很強調交貨期，那他很可能沒有耐心聽程式員解釋為什麼需要額外的時間去檢查每一行代碼。如果客戶看重的是軟體的可靠性，那他在增加功能和減少Bug之間多半會選擇後者。如果客戶習慣了老版本的鍵盤操作，那他很少會對新的圖形操作界面感興趣。

        在我曾經負責的一個項目中，為了更好的了解客戶的品質要求，我舉辦了一次開放式讨論會（Open Forum），除了項目成員和客戶參加外，我還客戶的上司們一起來參加讨論。這次讨論很有價值，因為我們發現很多原有的想法是和客戶真正的品質需求背道而馳的。了解這些想法的差異，使得我們可以把力量集中在讓客戶滿意的事情上，而不是放在讓“開發滿意”的事情上。

        軟體品質通常被了解為合乎規格說明，滿足客戶需求，以及在文檔和代碼中盡量少的缺陷（Defect）等等，這些都是比較“經典”的定義。“六西格碼品質”（Six-sigma Quality，譯者注：是一種品質标準及相應的品質管理方法）為缺陷密度（Defect Density）和/ 或失效率（Frequency of Failure）設定了一個很高的标準，但是，它沒有涉及品質的其他方面，比如交貨期、可用性、特性集和性能價格比等等。無論我們是作為生産者還是消費者，我們都希望産品的品質在所有這些方面都是盡量高的，但事實上，我們總要在其中做出權衡和選擇。

        我們在需求階段就考慮，對于客戶哪些品質特性是重要的，并把它們列舉出來（比如，互動性、正确性、易學性等）。然後，我們找來一些關鍵的客戶代表，請他們對這些品質特性打分。這樣，我們就可以掌握哪些品質特性是最主要的，哪些是次要的，進而就可以有的放矢，為這些品質特性而優化設計。

        我聽說的更有意思的一種軟體品質定義是“客戶回來的，但産品沒有”（the customer comes back, but the product does not）。和你的下屬以及客戶一起定義合适的品質目标，一旦定義了，則要不遺餘力的為達成這些目标而努力。也要以身作則，以高标準要求自己。記住這句話：“非完美不争取，非卓越不滿足”（Strive for perfection; settle for excellence）。

表彰進步

        表揚和獎勵項目成員的成績是很重要的激勵方式。你要把建立獎勵計劃Recognition Program）視為頭等大事，除非你已經有了适當的獎勵計劃。獎勵既可以是象征性的獎狀、證書，也可以是實實在在的獎品和現金。發獎時記得說，“感謝您的幫助”，或者“祝賀您完成了...”。還要記得獎勵的範圍不要局限在你的項目組内部，客戶代表和一些向你提供特别幫助的項目組外部人員也是要考慮的。

        獎勵計劃不僅需要你投入一小筆錢，也需要你多動動腦，想想以何種方式獎勵。和你的下屬多交流，了解他們在乎什麼樣的獎勵。要把獎勵活動變成團隊文化的一部分。另外，嘗試“隐形”的獎勵，讓你的下屬明白你是真的知曉他們所做的貢獻，并且對此心存感激。

前車之鑒， 後事之師

        你負責的項目很可能是半途接手的，而且你的前任做的并不怎麼好；或者，雖然是新項目，但從前有類似的項目完成，當然有成功的，也有失敗的。不管是哪種情形，你作為項目的負責人，應該花些時間分析以往的成功經驗和失敗教訓。你要了解這些項目曾經出現過什麼問題，以此避免自己重蹈覆轍。失敗是成功之母，但你沒有太多的機會失敗，是以你要多從别人的失敗中學習。

        不要戴着有色眼鏡去看以往的項目，或許某個你不喜歡的家夥出色的完成了他的項目，你當然可以把這歸結為運氣或者僥幸，但如果你客觀的分析，或許更有助于你的成功。

        你也需要客觀的去評價自己完成的一些項目（如果有的話），了解自己的團隊究竟強在哪裡，弱在何處。事實上，每個完成的項目都要進行項目回顧（Post-project Review），有時這種總結式的項目回顧也叫做“開棺驗屍”（Postmortem）。注意項目回顧不是為了追究誰的責任，發現問題、剖析問題是為了以後做得更好。你可以采取頭腦風暴的做法，鼓勵項目組成員各抒己見。另外，這種項目回顧也可以擴充到項目進行中，在每個大的階段結束時都進行回顧。

        除此之外，你需要了解被軟體業界普遍認可的最佳實踐（Best practice）。在SteveMcConnell 的《Rapid Development》（Microsoft Press，1996）中介紹了27 個最佳實踐和36 個軟體開發的“經典”問題。此書曾獲Jolt Award，是一個很好的學習起點。當你想把一些好的方法、工具和流程引入到你的項目中時，其他人可能會排斥、反對，甚至抵制，而這恰恰是你的職責所在，你要讓項目成員明白為什麼要這樣做，并且確定他們不折不扣的執行。在你的團隊内部，也會産生一些最佳實踐，是以你要采取一些措施，促使在項目成員之間交流和采納這些實踐。

設立改進目标

        當你回顧了以往的項目，并且确定了“品質”的含義，你需要設立一些短期的和長期的改進目标。隻要可能，這些目标應該是可以量化的，這樣你可以通過一些簡單的名額來衡量自己是否在朝着這些目标前進。

        舉個例子，你發現以往的項目由于需求多變而經常延後，于是，你可以設立一個半年的目标，力求将需求的穩定性提高50%。這樣的一個目标要求你每周每月做實際的工作：統計需求的改變數，查明需求的來源和改變的原因，采取措施來控制改變。這很可能将改變你與那些需求更改者的交往方式。

        你的這些目标和名額構成了軟體流程改進的一部分。盡管流程改進常被人指責為“官僚作風”的展現，但事實上，每個團隊都能找到一些可以改進的地方。如果你停留在一貫以來的做事方法上，你最好不要指望能獲得比以前更好的結果。

        改進流程的原因通常有兩個：糾正錯誤和預防錯誤。你要把精力集中到威脅或者可能威脅項目成功的因素上；帶領你的團隊一起分析你們目前做法的長處和短處，以及所面臨的威脅。

        我自己的團隊就組織過一次兩階段的頭腦風暴練習，以此來确認提高我們的産量和品質的障礙。在第一階段，參與者将自己想到的障礙寫在即時貼上，每張即時貼寫一個想法；然後，協調者就把這些即時貼收集起來，并進行分類；于是我們得到了若幹大的分類，我們就把這些分類寫在一張大的白紙上。

        在第二階段，同樣還是這些參與者，針對前面寫的障礙，把想到的克服方法寫到即時貼上，并且粘貼到相應的分類上。經過進一步的讨論和分析，我們得以把這些障礙細化，并且獲得了一系列可操作的應對方法。設立可度量的、可争取的目标将集中你為改進流程而付出的努力。你要和你的隊員們一起定期檢視改進的結果。記住流程改進的目的是為了項目和公司的成功，而不是為了滿足書本上的條條框框。把流程改進當成項目來操作，有自己的進度、投入和産出。否則，流程改進總是得不到應有的重視，最終被瑣碎的日常工作而淹沒。

不要急于求成

        本文所建議的一些做法将幫助你這個項目管理的新手和你的團隊取得更大的成功，随着你每天面臨的工作壓力，你或許會淪為又一個“苟延殘喘”者，但是，你要始終明白你肩負的一個任務（可能也是你獲得成功的機會），那就是形成你的團隊文化和一套做事的方法，這是一個長期的任務。你不可能一下子把想做的事都做到，你可以根據自己的處境有所選擇，從容上路。