一些項目管理和風(fēng)險管理的書籍和雜志，比如Project Management Institute 的月刊《PM Network》（譯者注：你也可以從《PMT 評論》獲得大量有價值的軟件項目知識）。你還可以從SWCMM（軟件能力成熟度模型）中找到很多有關(guān)軟件項目管理的有用建議。
定義“ 質(zhì)量”
盡管絕大多數(shù)人都認(rèn)真對待質(zhì)量，也想生產(chǎn)出優(yōu)質(zhì)的產(chǎn)品；但是，有關(guān)軟件質(zhì)量的定義仍存在很大爭議，比如高質(zhì)量是“足夠好”還是更為經(jīng)典的質(zhì)量觀點--“無缺陷”。為了領(lǐng)導(dǎo)你的團隊走向成功彼岸，你需要花些時間和你的下屬以及客戶一起來明確，對于他們，質(zhì)量意味著什么。
你的下屬和客戶是不同的兩幫人，他們很可能對質(zhì)量沒有一致的看法，也就容易抱有不同的目的。如果客戶很強調(diào)交貨期，那他很可能沒有耐心聽程序員解釋為什么需要額外的時間去檢查每一行代碼。如果客戶看重的是軟件的可靠性，那他在增加功能和減少Bug之間多半會選擇后者。如果客戶習(xí)慣了老版本的鍵盤操作，那他很少會對新的圖形操作界面感興趣。
在我曾經(jīng)負(fù)責(zé)的一個項目中，為了更好的了解客戶的質(zhì)量要求，我舉辦了一次開放式討論會（Open Forum），除了項目成員和客戶參加外，我和還客戶的上司們一起來參加討論。這次討論很有價值，因為我們發(fā)現(xiàn)很多原有的想法是和客戶真正的質(zhì)量需求背道而馳的。了解這些想法的差異，使得我們可以把力量集中在讓客戶滿意的事情上，而不是放在讓“開發(fā)滿意”的事情上。
軟件質(zhì)量通常被理解為合乎規(guī)格說明，滿足客戶需求，以及在文檔和代碼中盡量少的缺陷（Defect）等等，這些都是比較“經(jīng)典”的定義?！?/SPAN>
六西格碼質(zhì)量”（Six-sigma Quality，譯者注：是一種質(zhì)量標(biāo)準(zhǔn)及相應(yīng)的質(zhì)量管理方法）為缺陷密度（Defect Density）和/ 或失效率（Frequency of Failure）設(shè)定了一個很高的標(biāo)準(zhǔn)，但是，它沒有涉及質(zhì)量的其他方面，比如交貨期、可用性、特性集和性能價格比等等。無論我們是作為生產(chǎn)者還是消費者，我們都希望產(chǎn)品的質(zhì)量在所有這些方面都是盡量高的，但事實上，我們總要在其中做出權(quán)衡和選擇。
我們在需求階段就考慮，對于客戶哪些質(zhì)量特性是重要的，并把它們列舉出來（比如，交互性、正確性、易學(xué)性等）。然后，我們找來一些關(guān)鍵的客戶代表，請他們對這些質(zhì)量特性打分。這樣，我們就可以掌握哪些質(zhì)量特性是最主要的，哪些是次要的，從而就可以有的放矢，為這些質(zhì)量特性而優(yōu)化設(shè)計。
我聽說的更有意思的一種軟件質(zhì)量定義是“客戶回來的，但產(chǎn)品沒有”（the customer comes back, but the product does not）。和你的下屬以及客戶一起定義合適的質(zhì)量目標(biāo)，一旦定義了，則要不遺余力的為達(dá)成這些目標(biāo)而努力。也要以身作則，以高標(biāo)準(zhǔn)要求自己。記住這句話：“非完美不爭取，非卓越不滿足”（Strive for perfection; settle for excellence）。
表彰進步
表揚和獎勵項目成員的成績是很重要的激勵方式。你要把建立獎勵計劃Recognition Program）視為頭等大事，除非你已經(jīng)有了適當(dāng)?shù)莫剟钣媱潯＊剟罴瓤梢允窍笳餍缘莫劆?、證書，也可以是實實在在的獎品和現(xiàn)金。發(fā)獎時記得說，“感謝您的幫助”，或者“祝賀您完成了...”。
還要記得獎勵的范圍不要局限在你的項目組內(nèi)部，客戶代表和一些向你提供特別幫助的項目組外部人員也是要考慮的。
獎勵計劃不僅需要你投入一小筆錢，也需要你多動動腦，想想以何種方式獎勵。和你的下屬多交流，了解他們在乎什么樣的獎勵。