要把獎勵活動變成團隊文化的一部分。另外，嘗試“隱形”的獎勵，讓你的下屬明白你是真的知曉他們所做的貢獻，并且對此心存感激。
前車之鑒， 后事之師
你負責的項目很可能是半途接手的，而且你的前任做的并不怎么好；或者，雖然是新項目，但從前有類似的項目完成，當然有成功的，也有失敗的。不管是哪種情形，你作為項目的負責人，應該花些時間分析以往的成功經(jīng)驗和失敗教訓。你要了解這些項目曾經(jīng)出現(xiàn)過什么問題，以此避免自己重蹈覆轍。失敗是成功之母，但你沒有太多的機會失敗，所以你要多從別人的失敗中學習。
不要戴著有色眼鏡去看以往的項目，或許某個你不喜歡的家伙出色的完成了他的項目，你當然可以把這歸結為運氣或者僥幸，但如果你客觀的分析，或許更有助于你的成功。
你也需要客觀的去評價自己完成的一些項目（如果有的話），了解自己的團隊究竟強在哪里，弱在何處。事實上，每個完成的項目都要進行項目回顧（Post-project
Review），有時這種總結式的項目回顧也叫做“開棺驗尸”（Postmortem）。注意項目回顧不是為了追究誰的責任，發(fā)現(xiàn)問題、剖析問題是為了以后做得更好。你可以采取頭腦風暴的做法，鼓勵項目組成員各抒己見。另外，這種項目回顧也可以擴展到項目進行中，在每個大的階段結束時都進行回顧。
除此之外，你需要了解被軟件業(yè)界普遍認可的最佳實踐（Best practice）。在SteveMcConnell 的《Rapid Development》（Microsoft Press，1996）中介紹了27 個最佳實踐和36 個軟件開發(fā)的“經(jīng)典”問題。此書曾獲Jolt Award，是一個很好的學習起點。當你想把一些好的方法、工具和流程引入到你的項目中時，其他人可能會排斥、反對，甚至抵制，而這恰恰是你的職責所在，你要讓項目成員明白為什么要這樣做，并且確保他們不折不扣的執(zhí)行。在你的團隊內(nèi)部，也會產(chǎn)生一些最佳實踐，所以你要采取一些措施，促使在項目成員之間交流和采納這些實踐。
設立改進目標
當你回顧了以往的項目，并且確定了“質(zhì)量”的含義，你需要設立一些短期的和長期的改進目標。只要可能，這些目標應該是可以量化的，這樣你可以通過一些簡單的指標來衡量自己是否在朝著這些目標前進。
舉個例子，你發(fā)現(xiàn)以往的項目由于需求多變而經(jīng)常延后，于是，你可以設立一個半年的目標，力求將需求的穩(wěn)定性提高50%。這樣的一個目標要求你每周每月做實際的工作：統(tǒng)計需求的改變數(shù)，查明需求的來源和改變的原因，采取措施來控制改變。這很可能將改變你與那些需求更改者的交往方式。
你的這些目標和指標構成了軟件流程改進的一部分。盡管流程改進常被人指責為“官僚作風”的體現(xiàn)，但事實上，每個團隊都能找到一些可以改進的地方。如果你停留在一貫以來的做事方法上，你最好不要指望能獲得比以前更好的結果。
改進流程的原因通常有兩個：糾正錯誤和預防錯誤。你要把精力集中到威脅或者可能威脅項目成功的因素上；帶領你的團隊一起分析你們目前做法的長處和短處，以及所面臨的威脅。
我自己的團隊就組織過一次兩階段的頭腦風暴練習，以此來確認提高我們的產(chǎn)量和質(zhì)量的障礙。在第一階段，參與者將自己想到的障礙寫在即時貼上，每張即時貼寫一個想法；然后，協(xié)調(diào)者就把這些即時貼收集起來，并進行分類；于是我們得到了若干大的分類，我們就把這些分類寫在一張大的白紙上。
在第二階段，同樣還是這些參與者，針對前面寫的障礙，把想到的克服方法寫到即時貼上，并且粘貼到相應的分類上。經(jīng)過進一步的討論和分析，我們得以把這些障礙細化，并且
獲得了一系列可操作的應對方法。
設立可度量的、可爭取的目標將集中你為改進流程而付出的努力。你要和你的隊員們一起定期檢視改進的結果。記住流程改進的目的是為了項目和公司的成功，而不是為了滿足書本上的條條框框。把流程改進當成項目來操作，有自己的進度、投入和產(chǎn)出。否則，流程改進總是得不到應有的重視，最終被瑣碎的日常工作而淹沒。
不要急于求成
本文所建議的一些做法將幫助你這個項目管理的新手和你的團隊取得更大的成功，隨著你每天面臨的工作壓力，你或許會淪為又一個“茍延殘喘”者，但是，你要始終明白你肩負的一個任務（可能也是你獲得成功的機會），那就是形成你的團隊文化和一套做事的方法，這是一個長期的任務。你不可能一下子把想做的事都做到，你可以根據(jù)自己的處境有所選擇，從容上路。
作者：Karl E. Wiegers
翻譯改寫：吳昊