初為專案經理3（轉）

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

設立改進目標

當你回顧了以往的專案，並且確定了“質量”的含義，你需要設立一些短期的和長期的改進目標。只要可能，這些目標應該是可以量化的，這樣你可以透過一些簡單的指標來衡量自己是否在朝著這些目標前進。

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

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

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

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

在第二階段，同樣還是這些參與者，針對前面寫的障礙，把想到的克服方法寫到即時貼上，並且貼上到相應的分類上。經過進一步的討論和分析，我們得以把這些障礙細化，並且獲得了一系列可操作的應對方法。

設立可度量的、可爭取的目標將集中你為改進流程而付出的努力。你要和你的隊員們一起定期檢視改進的結果。記住流程改進的目的是為了專案和公司的成功，而不是為了滿足書本上的條條框框。把流程改進當成專案來操作，有自己的進度、投入和產出。否則，流程改進總是得不到應有的重視，最終被瑣碎的日常工作而淹沒。

不要急於求成

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