初為項目經(jīng)理
初為項目經(jīng)理 原作：Karl E.Wiegers 這一天終于來到了：你從一個一線開發(fā)人員被提拔為項目經(jīng)理。也許你一直在期盼， 也許你心里還忐忑不安，也許這是你的職業(yè)發(fā)展選擇，也許你只是不情愿地答應(yīng)老板“試 一下”。不管哪種情況，可能你并沒有項目和人員管理及領(lǐng)導(dǎo)的教育背景或者培訓(xùn)經(jīng)歷。 領(lǐng)導(dǎo)和管理（這兩者是不同的）遠(yuǎn)非簡單的與Dilbert 的老板背道而馳（注：Dilbert 是一個漫畫人物，以“擁有”一個“白癡老板”而著稱）。當(dāng)你計劃如何做好項目管理時， 考慮采取以下列出的行動。也許你想做的事情很多，但下面的這些建議會幫助你集中到 那些能提高效率（你自己的效率和團(tuán)隊的效率）的事情上。 設(shè)立優(yōu)先級 你要著手的第一件大事，很可能就是有意識地設(shè)立你作為項目經(jīng)理的優(yōu)先級。盡管你 可能因?yàn)楦鞣N原因還需要很大程度上參與軟件的開發(fā)，但除此之外，你還有一些新的職 責(zé)。很多新任的項目經(jīng)理都擺脫不了技術(shù)的誘惑，以致忽略了項目成員向自己尋求的幫 助。 富有效率的項目經(jīng)理知道，他們最高優(yōu)先的就是為項目成員提供服務(wù)。這些服務(wù)包括 ：指導(dǎo)和教育，處理沖突，提供資源，設(shè)立項目目標(biāo)和優(yōu)先級等等，適當(dāng)時也要提供技 術(shù)指導(dǎo)。我發(fā)現(xiàn)，把自己視為為成員工作，而非監(jiān)工是很有價值的。不管你正在做或者 將要做多重要的事，來你這兒尋求幫助的項目成員應(yīng)該有“非屏蔽中斷”（注：非屏蔽中 斷是一個硬件術(shù)語，此處意即最優(yōu)先的）優(yōu)先級。 你第二優(yōu)先的是讓你所在組織的客戶滿意（注：在我們公司，產(chǎn)品就可以理解為項目 的客戶）。作為一個項目經(jīng)理，如果你不再涉足產(chǎn)品的一線開發(fā)，也許你很少有直接的 機(jī)會可以讓客戶滿意。但你必須為你的項目成員創(chuàng)造一個環(huán)境，使得他們在這個環(huán)境下 工作，可以最有效地滿足客戶的需求。這是項目經(jīng)理的一個重要職能。 你第三優(yōu)先的是你自己的事情?？赡苁且粋€與項目有關(guān)的技術(shù)問題（當(dāng)然也是你感興 趣的），也可能是你的老板要你做的某件事。但當(dāng)這些事與上面兩個較高優(yōu)先級沖突時 ，你要做好延后處理的準(zhǔn)備。 你最低優(yōu)先的是那些純粹取悅你的老板的事情。在一個正常的組織（非Dilbet 式的組織）中，如果你做好了前面所說的更重要的三件事情，你的老板已經(jīng)是非常驚喜 了。盡管并非每個人都那么幸運(yùn)可以在一個“正?！钡慕M織工作，但還是努力做好這三件 最重要的事。把注意力放在盡可能的幫助下屬富有效率——并且快樂——上，而不是取悅于 那些“上面”的人。 分析你的技能差距 初為項目經(jīng)理，通常你會意識到你在領(lǐng)導(dǎo)和管理技能方面的差距，除非你已經(jīng)為這個 新職位做了充分準(zhǔn)備。你有很強(qiáng)的技術(shù)背景，可能這也是提拔你領(lǐng)導(dǎo)技術(shù)團(tuán)隊的一個原 因，但你還需要一些其他的技能。你需要客觀的評價自己的長處和短處，并且著手縮小 自己的差距。 做軟件的人常常被認(rèn)為缺乏出色的交際能力。你需要加強(qiáng)你的人際處理能力，諸如調(diào) 解矛盾、說服他人、“推銷”自己。你需要應(yīng)付一些不想應(yīng)付的場面，比如批評你的下屬 、為爭取下屬的績效“吵架”。 伴我開始經(jīng)理職業(yè)生涯的是傾聽（Listening）技能的課程，我覺得很有價值。在一 線開發(fā)時，往往我們都有過人的精力來表達(dá)自己的技術(shù)觀點(diǎn)。但作為管理人員，更需要 一種包容和聆聽的工作風(fēng)格和交流方式。然后，從“聽”的位置走到“說”的位置，你需要 提高你的演講（Presentation）技能。如果你對在公眾場合演講感到不適，你需要接受 一些專門的演講培訓(xùn)。這對你今后的工作很有好處。 作為一個項目經(jīng)理，協(xié)調(diào)他人的工作、計劃和跟蹤項目、必要時進(jìn)行項目回溯并采取 糾正措施等等都是你的職責(zé)?？赡艿脑?，接受有關(guān)項目管理的培訓(xùn)，學(xué)習(xí)如何設(shè)立優(yōu)先 級、如何主持高效的會議、如何明白無誤地溝通等等技能；多看一些項目管理和風(fēng)險管 理的書籍和雜志，比如Project Management Institute 的月刊《PM Network 》。你還可以從SW- CMM（軟件能力成熟度模型）中找到很多有關(guān)軟件項目管理的有用建議。 定義“質(zhì)量” 盡管絕大多數(shù)人都認(rèn)真對待質(zhì)量，也想生產(chǎn)出優(yōu)質(zhì)的產(chǎn)品；但是，有關(guān)軟件質(zhì)量的定 義仍存在很大爭議，比如高質(zhì)量是“足夠好”還是更為經(jīng)典的質(zhì)量觀點(diǎn)——“無缺陷”。為了 領(lǐng)導(dǎo)你的團(tuán)隊走向成功，你需要花些時間和你的下屬以及客戶一起來明確：對于他們， 質(zhì)量意味著什么。 你的下屬和客戶是不同的兩幫人，他們很可能對質(zhì)量沒有一致的看法，也容易抱有不 同的目的。如果客戶很強(qiáng)調(diào)交貨期，那他很可能沒有耐心聽程序員解釋為什么需要額外 的時間去檢查每一行代碼。如果客戶看重的是軟件的可靠性，那他在增加功能和減少Bu g 之間多半會選擇后者。如果客戶習(xí)慣了老版本的鍵盤操作，那他很少會對新的圖形操作 界面感興趣。 在我曾經(jīng)負(fù)責(zé)的一個項目中，為了更好地了解客戶的質(zhì)量要求，我舉辦了一次開放式 討論會（Open Forum），除了項目成員和客戶參加外，我還請客戶的上司們一起來參加討論。這次討論 很有價值，因?yàn)槲覀儼l(fā)現(xiàn)很多原有的想法是和客戶真正的質(zhì)量需求背道而馳的。了解這 些想法的差異，使得我們可以把力量集中在讓客戶滿意的事情上，而不是放在讓“開發(fā)滿 意”的事情上。 軟件質(zhì)量通常被理解為合乎規(guī)格說明，滿足客戶需求，以及在文檔和代碼中盡量少的 缺陷（Defect）等等，這些都是比較“經(jīng)典”的定義?！傲鞲翊a質(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)者還是消費(fèi)者，我們都希望產(chǎn)品 的質(zhì)量在所有這些方面都是盡量高的，但事實(shí)上，我們總要在其中做出權(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） 表彰進(jìn)步 表揚(yáng)和獎勵項目成員的成績是很重要的激勵方式。你要把建立獎勵機(jī)制（Recogniti on Program）視為頭等大事，除非你已經(jīng)有了適當(dāng)?shù)莫剟顧C(jī)制。獎勵既可以是象征性的獎狀 、證書，也可以是實(shí)實(shí)在在的獎品和現(xiàn)金。發(fā)獎時記得說，“感謝您的幫助”，或者“祝賀 您完成了……”。還要記得獎勵的范圍不要局限在你的項目組內(nèi)部，客戶代表和一些向你提 供特別幫助的項目組外部人員也是要考慮的。 獎勵機(jī)制不僅需要你投入一小筆錢，也需要你多動動腦，想想以何種方式獎勵。和你 的下屬多交流，了解他們在乎什么樣的獎勵。要把獎勵活動變成團(tuán)隊文化的一部分。另 外，嘗試“隱形”的獎勵，讓你的下屬明白你是真的知曉他們所做的貢獻(xiàn)，并且對此心存 感激。（注：在我們公司，榮譽(yù)獎和榮譽(yù)獎券是非常好的激勵資源。在微軟，很多項目 組中都有一頂小丑的帽子，在每天的Building檢查中，如果有人出了問題就要把這頂帽 子戴一天。） 前車之鑒，后事之師 你負(fù)責(zé)的項目很可能是半途接手的，而且你的前任做得并不怎么好；或者，雖然是新 項目，但從前有類似的項目完成，當(dāng)然有成功的，也有失敗的。不管是哪種情形，你作 為項目的負(fù)責(zé)人，應(yīng)該花些時間分析以往的成功經(jīng)驗(yàn)和失敗教訓(xùn)。你要了解這些項目曾 經(jīng)出現(xiàn)過什么問題，以此避免自己重蹈覆轍。失敗是成功之母，但你沒有太多的機(jī)會失 敗，所以你要多從別人的失敗中學(xué)習(xí)。 不要戴著有色眼鏡去看以往的項目，或許某個你不喜歡的家伙出色地完成了他的項目 ，你當(dāng)然可以把這歸結(jié)為運(yùn)氣或者僥幸，但如果你客觀地分析，或許更有助于你的成功 。 你也需要客觀的去評價自己完成的一些項目（如果有的話），了解自己的團(tuán)隊究竟強(qiáng) 在哪里，弱在何處。事實(shí)上，每個完成的項目都要進(jìn)行項目回顧（Post-project Review），有時這種總結(jié)式的項目回顧也叫做“開棺驗(yàn)尸”（Postmortem）。注意項目回 顧不是為了追究誰的責(zé)任，發(fā)現(xiàn)問題、剖析問題是為了以后做得更好。你可以采取頭腦 風(fēng)暴的做法，鼓勵項目組成員各抒己見。另外，這種項目回顧也可以擴(kuò)展到項目進(jìn)行中 ，在每個大的階段結(jié)束時都進(jìn)行回顧。 除此之外，你需要了解被軟件業(yè)界普遍認(rèn)可的最佳實(shí)踐（Best practice）。在Steve McConnell 的《Rapid Development 》（Microsoft Press，1996）中介紹了27 個最佳實(shí)踐和36 個軟件開發(fā)的“經(jīng)典”問題。此書曾獲Jolt Award，是一個很好的學(xué)習(xí)起點(diǎn)。當(dāng)你想把一些好的方法、工具和流程引入到你的項目中 時，其他人可能會排斥、反對，甚至抵制，而這恰恰是你的職責(zé)所在，你要讓項目成員 明白為什么要這樣做，并且確保他們不折不扣的執(zhí)行。在你的團(tuán)隊內(nèi)部，也會產(chǎn)生一些 最佳實(shí)踐，所以你要采取一些措施，促使在項目成員之間交流和采納這些實(shí)踐。 設(shè)立改進(jìn)目標(biāo) 當(dāng)你回顧了以往的項目，并且確定了“質(zhì)量”的含義，你需要設(shè)立一些短期的和長期的 改進(jìn)目標(biāo)。只要可能，這些目標(biāo)應(yīng)該是可以量化的，這樣你可以通過一些簡單的指標(biāo)來 衡量自己是否在朝著這些目標(biāo)前進(jìn)。舉個例子，你發(fā)現(xiàn)以往的項目由于需求多變而經(jīng)常 延后，于是，你可以設(shè)立一個半年的目標(biāo)，力求將需求的穩(wěn)定性提高50%。這樣的一個目 標(biāo)要求你每周每月做實(shí)際的工作：統(tǒng)計需求的改變數(shù)，查明需求的來源和改變的原因， 采取措施來控制改變。這很可能將改變你與那些需求更改者的交往方式。 你的這些目標(biāo)和指標(biāo)構(gòu)成了軟件流程改進(jìn)的一部分。盡管流程改進(jìn)常被人指責(zé)為“官 僚作風(fēng)”的體現(xiàn)，但事實(shí)上，每個團(tuán)隊都能找到一些可以改進(jìn)的地方。如果你停留在一貫 以來的做事方法上，你最好不要指望能獲得比以前更好的結(jié)果。 改進(jìn)流程的原因通常有兩個：糾正錯誤和預(yù)防錯誤。你要把精力集中到威脅或者可能 威脅項目成功的因素上；帶領(lǐng)你的團(tuán)隊一起分析你們目前做法的長處和短處，以及所面 臨的威脅。 我自己的團(tuán)隊就組織過一次兩階段的頭腦風(fēng)暴練習(xí)，以此來確認(rèn)提高我們的產(chǎn)量和質(zhì) 量的障礙。在第一階段，參與者將自己想到的障礙寫在即時貼上，每張即時貼寫一個想 法；然后，協(xié)調(diào)者就把這些即時貼收集起來，并進(jìn)行分類；于是我們得到了若干大的分 類，我們就把這些分類寫在一張大的白紙上。在第二階段，同樣還是這些參與者，針對 前面寫的障礙，把想到的克服方法寫到即時貼上，并且粘貼到相應(yīng)的分類上。經(jīng)過進(jìn)一 步的討論和分析，我們得以把這些障礙細(xì)化，并且獲得了一系列可操作的應(yīng)對方法。 設(shè)立可度量的、可爭取的目標(biāo)將集中你為改進(jìn)流程而付出的努力。你要和你的隊員們 一起定期檢視改進(jìn)的結(jié)果。記住流程改進(jìn)的目的是為了項目和公司的成功，而不是為了 滿足書本上的條條框框。把流程改進(jìn)當(dāng)成項目來操作，有自己的進(jìn)度、投入和產(chǎn)出。否 則，流程改進(jìn)總是得不到應(yīng)有的重視，最終被瑣碎的日常工作而淹沒。 不要急于求成 本文所建議的一些做法將幫助你這個項目管理的新手和你的團(tuán)隊取得更大的成功，隨 著你每天面臨的工作壓力，你或許會淪為又一個“茍延殘喘”者，但是，你要始終明白你 肩負(fù)的一個任務(wù)（可能也是你獲得成功的機(jī)會），那就是形成你的團(tuán)隊文化和一套做事 的方法，這是一個長期的任務(wù)。你不可能一下子把想做的事都做到，你可以根據(jù)自己的 處境有所選擇，從容上路。 祝你好運(yùn)！ 【注】：Karl E.Wiegers，軟件工程經(jīng)典《軟件需求》的作者。
初為項目經(jīng)理