初為項目經(jīng)理

申請免費試用、咨詢電話：400-8352-114

初為項目經(jīng)理

初為
原作：Karl E. Wiegers
這一天終于來到了：你從一個一線開發(fā)人員被提拔為項目經(jīng)理。也許你一直在期盼，也
許你心里還忐忑不安，也許這是你的職業(yè)發(fā)展選擇，也許你只是不情愿的答應(yīng)老板“試
一下”。不管哪種情況，可能你并沒有項目和人員管理及領(lǐng)導的教育背景或者培訓經(jīng)歷
。
領(lǐng)導和管理（這兩者是不同的）遠非簡單的與Dilbert
的老板背道而馳（譯者注：Dilbert 是一個漫畫人物，以“擁有”一個“白癡老板”而
著稱）。當你計劃如何做好項目管理時，考慮采取以下列出的行動。也許你想做的事情
很多，但下面的這些建議會幫助你集中到那些能提高效率（你自己的效率和團隊的效率
）的事情上。
設(shè)立優(yōu)先級
你要著手的第一件大事很可能就是有意識的設(shè)立你作為項目經(jīng)理的優(yōu)先級。盡管你可能
因為各種原因還需要很大程度上參與軟件的開發(fā)，但除此之外，你還有一些新的職責。
很多新任的項目經(jīng)理都擺脫不了技術(shù)的誘惑，以致忽略了項目成員向自己尋求的幫助。

富有效率的項目經(jīng)理知道，他們最高優(yōu)先的就是為項目成員提供服務(wù)。這些服務(wù)包括：
指導和教育，處理沖突，提供資源，設(shè)立項目目標和優(yōu)先級等等，適當時也要提供技術(shù)
指導。我發(fā)現(xiàn)，把自己視為為成員工作，而非監(jiān)工是很有價值的。不管你正在做或者將
要做多重要的事，來你這兒尋求幫助的項目成員應(yīng)該有“非屏蔽中斷”（譯者注：非屏
蔽中斷是一個硬件術(shù)語，此處意即最優(yōu)先的）優(yōu)先級。
你第二優(yōu)先的是讓你所在組織的客戶滿意。作為一個項目經(jīng)理，如果你不再涉足產(chǎn)品的
一線開發(fā)，也許你很少有直接的機會可以讓客戶滿意。但你必須為你的項目成員創(chuàng)造一
個環(huán)境，使得他們在這個環(huán)境下工作，可以最有效的滿足客戶的需求。這是項目經(jīng)理的
一個重要職能。
你第三優(yōu)先的是你自己的事情?？赡苁且粋€與項目有關(guān)的技術(shù)問題（當然也是你感興趣
的），也可能是你的老板要你做的某件事。但當這些事與上面兩個較高優(yōu)先級沖突時，
你要做好延后處理的準備。
你最低優(yōu)先的是那些純粹取悅你的老板的事情。在一個正常的組織（非Dilbet 式的組織
）中，如果你做好了前面所說的更重要的三件事情，你的老板已經(jīng)是非常驚喜了。盡管
并非每個人都那么幸運可以在一個“正?！钡慕M織工作，但還是努力做好這三件最重要
的事。把注意力放在盡可能的幫助下屬富有效率--
并且快樂-- 上，而不是取悅于那些“上面”的人。
分析你的技能差距
初為項目經(jīng)理，通常你會意識到你在領(lǐng)導和管理技能方面的差距，除非你已經(jīng)為這個新
職位做了充分準備。你有很強的技術(shù)背景，可能這也是提拔你領(lǐng)導技術(shù)團隊的一個原因
，但你還需要一些其他的技能。你需要客觀的評價自己的長處和短處，并且著手縮小自
己的差距。
做軟件的人常常被認為缺乏出色的交際能力。你需要加強你的人際處理能，諸如調(diào)解矛
盾、說服他人、“推銷”自己。你需要應(yīng)付一些不想應(yīng)付的場面，比如解雇你的下屬、
在進度上“討價還價”、為爭取下屬的績效“吵架”。
伴我開始經(jīng)理職涯的是傾聽（Listening）技能的課程，我覺得很有價值。一線開發(fā)時，
往往我們都有過人的精力來表達自己的技術(shù)觀點。但作為管理人員，更需要一種包容和
聆聽的工作風格和交流方式。然后，從“聽”的位置走到“說”的位置，你需要提高你
的演講（Presentation）技能。如果你對在公眾場合演講感到不適，你需要接受一些專
門的演講培訓。這對你今后的工作很有好處。
作為一個項目經(jīng)理，協(xié)調(diào)他人的工作、計劃和跟蹤項目、必要時進行項目回溯并采取糾
正措施等等都是你的職責?？赡艿脑?，接受有關(guān)項目管理的培訓，學習如何設(shè)立優(yōu)先級
、如何主持高效的會議、如何明白無誤的溝通等等技能；多看一些項目管理和風險管理
的書籍和雜志，比如Project Management Institute 的月刊《PM Network》（譯者注：
你也可以從《PMT 評論》獲得大量有價值的軟件項目知識）。你還可以從SW（軟件能
力成熟度模型）中找到很多有關(guān)軟件項目管理的有用建議。
定義“ 質(zhì)量”
盡管絕大多數(shù)人都認真對待質(zhì)量，也想生產(chǎn)出優(yōu)質(zhì)的產(chǎn)品；但是，有關(guān)軟件質(zhì)量的定義
仍存在很大爭議，比如高質(zhì)量是“足夠好”還是更為經(jīng)典的質(zhì)量觀點--“無缺陷”。為
了領(lǐng)導你的團隊走向成功彼岸，你需要花些時間和你的下屬以及客戶一起來明確，對于
他們，質(zhì)量意味著什么。
你的下屬和客戶是不同的兩幫人，他們很可能對質(zhì)量沒有一致的看法，也就容易抱有不
同的目的。如果客戶很強調(diào)交貨期，那他很可能沒有耐心聽程序員解釋為什么需要額外
的時間去檢查每一行代碼。如果客戶看重的是軟件的可靠性，那他在增加功能和減少Bu
g之間多半會選擇后者。如果客戶習慣了老版本的鍵盤操作，那他很少會對新的圖形操作
界面感興趣。
在我曾經(jīng)負責的一個項目中，為了更好的了解客戶的質(zhì)量要求，我舉辦了一次開放式討
論會（Open Forum），除了項目成員和客戶參加外，我還客戶的上司們一起來參加討論
。這次討論很有價值，因為我們發(fā)現(xiàn)很多原有的想法是和客戶真正的質(zhì)量需求背道而馳
的。了解這些想法的差異，使得我們可以把力量集中在讓客戶滿意的事情上，而不是放
在讓“開發(fā)滿意”的事情上。
軟件質(zhì)量通常被理解為合乎規(guī)格說明，滿足客戶需求，以及在文檔和代碼中盡量少的缺
陷（Defect）等等，這些都是比較“經(jīng)典”的定義。“六西格碼質(zhì)量”（Six-sigma Qu
ality，譯者注：是一種質(zhì)量標準及相應(yīng)的質(zhì)量管理方法）為缺陷密度（Defect Densit
y）和/ 或失效率（Frequency of Failure）設(shè)定了一個很高的標準，但是，它沒有涉及
質(zhì)量的其他方面，比如交貨期、可用性、特性集和性能價格比等等。無論我們是作為生
產(chǎn)者還是消費者，我們都希望產(chǎn)品的質(zhì)量在所有這些方面都是盡量高的，但事實上，我
們總要在其中做出權(quán)衡和選擇。
我們在需求階段就考慮，對于客戶哪些質(zhì)量特性是重要的，并把它們列舉出來（比如，
交互性、正確性、易學性等）。然后，我們找來一些關(guān)鍵的客戶代表，請他們對這些質(zhì)
量特性打分。這樣，我們就可以掌握哪些質(zhì)量特性是最主要的，哪些是次要的，從而就
可以有的放矢，為這些質(zhì)量特性而優(yōu)化設(shè)計。
我聽說的更有意思的一種軟件質(zhì)量定義是“客戶回來的，但產(chǎn)品沒有”（the customer
comes back, but the product does not）。和你的下屬以及客戶一起定義合適的質(zhì)量
目標，一旦定義了，則要不遺余力的為達成這些目標而努力。也要以身作則，以高標準
要求自己。記住這句話：“非完美不爭取，非卓越不滿足”（Strive for perfection;
settle for excellence）。
表彰進步
表揚和獎勵項目成員的成績是很重要的激勵方式。你要把建立獎勵計劃Recognition Pr
ogram）視為頭等大事，除非你已經(jīng)有了適當?shù)莫剟钣媱?。獎勵既可以是象征性的獎狀?
證書，也可以是實實在在的獎品和現(xiàn)金。發(fā)獎時記得說，“感謝您的幫助”，或者“祝
賀您完成了...”。還要記得獎勵的范圍不要局限在你的項目組內(nèi)部，客戶代表和一些向
你提供特別幫助的項目組外部人員也是要考慮的。
獎勵計劃不僅需要你投入一小筆錢，也需要你多動動腦，想想以何種方式獎勵。和你的
下屬多交流，了解他們在乎什么樣的獎勵。要把獎勵活動變成團隊文化的一部分。另外
，嘗試“隱形”的獎勵，讓你的下屬明白你是真的知曉他們所做的貢獻，并且對此心存
感激。
前車之鑒， 后事之師
你負責的項目很可能是半途接手的，而且你的前任做的并不怎么好；或者，雖然是新項
目，但從前有類似的項目完成，當然有成功的，也有失敗的。不管是哪種情形，你作為
項目的負責人，應(yīng)該花些時間分析以往的成功經(jīng)驗和失敗教訓。你要了解這些項目曾經(jīng)
出現(xiàn)過什么問題，以此避免自己重 父 轍。失敗是成功之母，但你沒有太多的機會失敗
，所以你要多從別人的失敗中學習。
不要戴著有色眼鏡去看以往的項目，或許某個你不喜歡的家伙出色的完成了他的項目，
你當然可以把這歸結(jié)為運氣或者僥幸，但如果你客觀的分析，或許更有助于你的成功。

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