20年研發管理經驗談（十三）

本文繼20年研發管理經驗談（十二）。

初爲項目經理

做者：Karl E.Wiegers
這一天終於來到了：你從一個一線開發人員被提拔爲項目經理。也許你一直在期盼，也許你內心還忐忑不安，也許這是你的職業發展選擇，也許你只是不情願地答應老闆「試一下」。無論哪一種狀況，可能你並無項目和人員管理及領導的教育背景或者培訓經歷。

領導和管理（這二者是不一樣的）遠非簡單的與Dilbert 的老闆背道而馳（注：Dilbert 是一個漫畫人物，以「擁有」一個「白癡老闆」而著稱）。當你計劃如何作好項目管理時，考慮採起如下列出的行動。也許你想作的事情不少，但下面的這些建議會幫助你集中到那些能提升效率（你本身的效率和團隊的效率）的事情上。

設立優先級

你要着手的第一件大事，極可能就是有意識地設立你做爲項目經理的優先級。儘管你可能由於各類緣由還須要很大程度上參與軟件的開發，但除此以外，你還有一些新的職責。不少新任的項目經理都擺脫不了技術的誘惑，以至忽略了項目成員向本身尋求的幫助。

富有效率的項目經理知道，他們最高優先的就是爲項目成員提供服務。這些服務包括：指導和教育，處理衝突，提供資源，設立項目目標和優先級等等，適當時也要提供技術指導。我發現，把本身視爲爲成員工做，而非監工是頗有價值的。無論你正在作或者將要作多重要的事，來你這兒尋求幫助的項目成員應該有「非屏蔽中斷」（注：非屏蔽中斷是一個硬件術語，此處意即最優先的）優先級。

你第二優先的是讓你所在組織的客戶滿意（注：在咱們公司，產品就能夠理解爲項目的客戶）。做爲一個項目經理，若是你再也不涉足產品的一線開發，也許你不多有直接的機會可讓客戶滿意。但你必須爲你的項目成員創造一個環境，使得他們在這個環境下工做，能夠最有效地知足客戶的需求。這是項目經理的一個重要職能。

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

你最低優先的是那些純粹取悅你的老闆的事情。在一個正常的組織（非Dilbet 式的組織）中，若是你作好了前面所說的更重要的三件事情，你的老闆已是很是驚喜了。儘管並不是每一個人都那麼幸運能夠在一個「正常」的組織工做，但仍是努力作好這三件最重要的事。把注意力放在儘量的幫助下屬富有效率——而且快樂——上，而不是取悅於那些「上面」的人。

分析你的技能差距

初爲項目經理，一般你會意識到你在領導和管理技能方面的差距，除非你已經爲這個新職位作了充分準備。你有很強的技術背景，可能這也是提拔你領導技術團隊的一個緣由，但你還須要一些其餘的技能。你須要客觀的評價本身的長處和短處，而且着手縮小本身的差距。

作軟件的人經常被認爲缺少出色的交際能力。你須要增強你的人際處理能力，諸如調解矛盾、說服他人、「推銷」本身。你須要應付一些不想應付的場面，好比批評你的下屬、爲爭取下屬的績效「吵架」。

伴我開始經理職業生涯的是傾聽（Listening）技能的課程，我以爲頗有價值。在一線開發時，每每咱們都有過人的精力來表達本身的技術觀點。但做爲管理人員，更須要一種包容和聆聽的工做風格和交流方式。而後，從「聽」的位置走到「說」的位置，你須要提升你的演講（Presentation）技能。若是你對在公衆場合演講感到不適，你須要接受一些專門的演講培訓。這對你從此的工做頗有好處。

做爲一個項目經理，協調他人的工做、計劃和跟蹤項目、必要時進行項目回溯並採起糾正措施等等都是你的職責。可能的話，接受有關項目管理的培訓，學習如何設立優先級、如何主持高效的會議、如何明白無誤地溝通等等技能；多看一些項目管理和風險管理的書籍和雜誌，好比Project Management Institute 的月刊《PM Network 》。你還能夠從SW-CMM（軟件能力成熟度模型）中找到不少有關軟件項目管理的有用建議。

定義「質量」

儘管絕大多數人都認真對待質量，也想生產出優質的產品；可是，有關軟件質量的定義仍存在很大爭議，好比高質量是「足夠好」仍是更爲經典的質量觀點——「完好陷」。爲了領導你的團隊走向成功，你須要花些時間和你的下屬以及客戶一塊兒來明確：對於他們，質量意味着什麼。

你的下屬和客戶是不一樣的兩幫人，他們極可能對質量沒有一致的見解，也容易抱有不一樣的目的。若是客戶很強調交貨期，那他極可能沒有耐心聽程序員解釋爲何須要額外的時間去檢查每一行代碼。若是客戶看重的是軟件的可靠性，那他在增長功能和減小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）視爲頭等大事，除非你已經有了適當的獎勵機制。獎勵既能夠是象徵性的獎狀、證書，也能夠是實實在在的獎品和現金。發獎時記得說，「感謝您的幫助」，或者「祝賀您完成了……」。還要記得獎勵的範圍不要侷限在你的項目組內部，客戶表明和一些向你提供特別幫助的項目組外部人員也是要考慮的。

獎勵機制不只須要你投入一小筆錢，也須要你多動動腦，想一想以何種方式獎勵。和你的下屬多交流，瞭解他們在意什麼樣的獎勵。要把獎勵活動變成團隊文化的一部分。另外，嘗試「隱形」的獎勵，讓你的下屬明白你是真的知曉他們所作的貢獻，而且對此心存感激。（注：在咱們公司，榮譽獎和榮譽獎券是很是好的激勵資源。在微軟，不少項目組中都有一頂小丑的帽子，在天天的Building檢查中，若是有人出了問題就要把這頂帽子戴一天。）

前車可鑑，後事之師

你負責的項目極可能是半途接手的，並且你的前任作得並不怎麼好；或者，雖然是新項目，但從前有相似的項目完成，固然有成功的，也有失敗的。無論是哪一種情形，你做爲項目的負責人，應該花些時間分析以往的成功經驗和失敗教訓。你要了解這些項目曾經出現過什麼問題，以此避免本身重蹈覆轍。失敗是成功之母，但你沒有太多的機會失敗，因此你要多從別人的失敗中學習。

不要戴着有色眼鏡去看以往的項目，或許某個你不喜歡的傢伙出色地完成了他的項目，你固然能夠把這歸結爲運氣或者僥倖，但若是你客觀地分析，或許更有助於你的成功。

你也須要客觀的去評價本身完成的一些項目（若是有的話），瞭解本身的團隊究竟強在哪裏，弱在何處。事實上，每一個完成的項目都要進行項目回顧（Post-project Review），有時這種總結式的項目回顧也叫作「開棺驗屍」（Postmortem）。注意項目回顧不是爲了追究誰的責任，發現問題、剖析問題是爲了之後作得更好。你能夠採起頭腦風暴的作法，鼓勵項目組成員各抒己見。另外，這種項目回顧也能夠擴展到項目進行中，在每一個大的階段結束時都進行回顧。

除此以外，你須要瞭解被軟件業界廣泛承認的最佳實踐（Best practice）。在Steve McConnell 的《Rapid Development 》（Microsoft Press，1996）中介紹了27 個最佳實踐和36 個軟件開發的「經典」問題。此書曾獲Jolt Award，是一個很好的學習起點。當你想把一些好的方法、工具和流程引入到你的項目中時，其餘人可能會排斥、反對，甚至抵制，而這偏偏是你的職責所在，你要讓項目成員明白爲何要這樣作，而且確保他們徹徹底底的執行。在你的團隊內部，也會產生一些最佳實踐，因此你要採起一些措施，促使在項目成員之間交流和採納這些實踐。

設立改進目標

當你回顧了以往的項目，而且肯定了「質量」的含義，你須要設立一些短時間的和長期的改進目標。只要可能，這些目標應該是能夠量化的，這樣你能夠經過一些簡單的指標來衡量本身是否在朝着這些目標前進。舉個例子，你發現以往的項目因爲需求多變而常常延後，因而，你能夠設立一個半年的目標，力求將需求的穩定性提升50%。這樣的一個目標要求你每週每個月作實際的工做：統計需求的改變數，查明需求的來源和改變的緣由，採起措施來控制改變。這極可能將改變你與那些需求更改者的交往方式。

你的這些目標和指標構成了軟件流程改進的一部分。儘管流程改進常被人指責爲「官僚做風」的體現，但事實上，每一個團隊都能找到一些能夠改進的地方。若是你停留在一向以來的作事方法上，你最好不要期望能得到比之前更好的結果。

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

我本身的團隊就組織過一次兩階段的頭腦風暴練習，以此來確認提升咱們的產量和質量的障礙。在第一階段，參與者將本身想到的障礙寫在即時貼上，每張即時貼寫一個想法；而後，協調者就把這些即時貼收集起來，並進行分類；因而咱們獲得了若干大的分類，咱們就把這些分類寫在一張大的白紙上。在第二階段，一樣仍是這些參與者，針對前面寫的障礙，把想到的克服方法寫到即時貼上，而且粘貼到相應的分類上。通過進一步的討論和分析，咱們得以把這些障礙細化，而且得到了一系列可操做的應對方法。

設立可度量的、可爭取的目標將集中你爲改進流程而付出的努力。你要和你的隊員們一塊兒按期檢視改進的結果。記住流程改進的目的是爲了項目和公司的成功，而不是爲了知足書本上的條條框框。把流程改進當成項目來操做，有本身的進度、投入和產出。不然，流程改進老是得不到應有的重視，最終被瑣碎的平常工做而淹沒。

不要急於求成

本文所建議的一些作法將幫助你這個項目管理的新手和你的團隊取得更大的成功，隨着你天天面臨的工做壓力，你或許會淪爲又一個「苟延殘喘」者，可是，你要始終明白你肩負的一個任務（可能也是你得到成功的機會），那就是造成你的團隊文化和一套作事的方法，這是一個長期的任務。你不可能一會兒把想作的事都作到，你能夠根據本身的處境有所選擇，從容上路。