初為專案經理2（轉）

定義“ 質量”

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

你的下屬和客戶是不同的兩幫人，他們很可能對質量沒有一致的看法，也就容易抱有不同的目的。如果客戶很強調交貨期，那他很可能沒有耐心聽程式設計師解釋為什麼需要額外的時間去檢查每一行程式碼。如果客戶看重的是軟體的可靠性，那他在增加功能和減少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）。注意專案回顧不是為了追究誰的責任，發現問題、剖析問題是為了以後做得更好。你可以採取頭腦風暴的做法，鼓勵專案組成員各抒己見。另外，這種專案回顧也可以擴充套件到專案進行中，在每個大的階段結束時都進行回顧。[@more@]