(項目管理)項目管理的五大過程

1、項目管理的五大過程一 . 商務(wù)談判1. 作人的姿態(tài)作人似乎跟商務(wù)談判不太有關(guān)系，很多技術(shù)人員相信PM需要的是本事，是如何做好一個項目，而不是會搞好關(guān)系弄的四平八穩(wěn)的人。隨著PM*中國的悄悄興起，越來越多的PM開始在老總的授意下參與商務(wù)談判，和銷售們一起打單子，這就比較實在的需要PM們?nèi)ゴ蛻舻男睦怼４蛻粜睦硇枰卸喾矫娴闹R， 需要深度和廣度， 然而， 最重要的仍然是作人。如何放下架子，降低作人的姿態(tài)，對從技術(shù)人員轉(zhuǎn)型的PMKil來說，是至關(guān)重要的。 降低作人的姿態(tài)需要從多個方面去實施， 最主要應(yīng)該記住： 人不可貌相， 更不可以地位衡量。 很多公司為了保持公司形象， 會統(tǒng)一叫員工打扮的好

2、看一點， 看起來象個白領(lǐng)的樣子。 然而， 老板多半是沒有約束的。 中國改革開放才二十年， 很多有錢的老板實業(yè)家文化層次都不高， 往往是當(dāng)大學(xué)生們只會把屁股坐在板凳上肆意揮霍父母辛苦積攢的財富時， 他們已經(jīng)在各地奔波， 積累豐富的商業(yè)經(jīng)驗并對金錢， 人生和社會的本質(zhì)有了充分的認識， 形成了自己穩(wěn)定的思維框架。 這些人， 很多都是穿著舊舊的衣服， 戴著破破的手表， 說話的時候經(jīng)常會帶上三字經(jīng)， 鉆進上海的人堆里，搞不好你會把他當(dāng)成民工。因為到他們所處的社會地位，已經(jīng)不需要任何華麗的外表來襯托自己的身份，他們有的是底氣。對PM來說， 這是個非常危險的挑戰(zhàn)。 雖然說項目在初期有意向時會對對方的人事和關(guān)

3、鍵人物有一定的了解， 然而大項目里能說的上話的人太多了。 上海人最瞧不起的就是土氣， 很多人談項目的時候看到民工或很俗氣的表現(xiàn)不免會皺皺眉頭， 往往在皺眉頭的時候就失去了項目， 也就是失去了市場和金錢。PM必須作到能與每一個層次的人交談，尤其是看起來比自己層次要低的群體，哪怕是公司里掃地的阿姨。只有作到謙虛謹慎，不擺架子，尊重別人， 才會得到別人的尊重， 才有機會贏得項目。 鼻子比眼睛高的人只會把自己的鼻子撞扁。2. 豐富的知識面光尊重別人還不足以贏得項目，準(zhǔn)確的說是贏得對方關(guān)鍵人物的信賴。 PM一般用不著陪客戶喝酒吃飯，那是銷售們的事情，但是PMffi客戶討論問題可能是最多的。 討論問題的時

4、候就是機會， 如何投其所好， 是一大關(guān)鍵。 金錢與美女依然是常規(guī)的敲門磚， 然而這種傻瓜也知道的辦法人人都會去做。 老板的關(guān)系也只是一個方面， 如今的大老板， 哪個沒有關(guān)系？同等條件下PM憑什么去勝過別人一籌？我一個朋友（PM打一個單子時，發(fā)現(xiàn)對方對什么都不太感興趣， 費了很大力氣也找不到突破口。 對方這個人非常順利， 金錢地位美女樣樣不缺。 他花了好多天和對方交談， 以自己的博學(xué)逐漸取得了對方的信任。 后來他隱約發(fā)現(xiàn)對方對數(shù)學(xué)和天文學(xué)的發(fā)展史有所涉獵， 如獲至寶， 回家花一個通宵的時間在網(wǎng)絡(luò)上搜索相關(guān)資料。第二天他根本不談項目的事情， 只跟對方大談特談哥白尼， 布魯諾， 伽利 略這些人的生平

5、， 整整吹了一天。 對方點頭如搗蒜泥， 態(tài)度和熱情都來個 一百八十度轉(zhuǎn)彎， 隔天他就拿到了單子。 這是個經(jīng)典的戰(zhàn)例， 誰能事先想到哥白尼會來幫助IT的人賺錢？這個PMB的就是博學(xué)和由博學(xué)引申出的敏銳的感覺抓住了機會， 讓客戶產(chǎn)生共鳴。 客戶感覺他層次也很高， 而且和自己有共通之處， 信任度大大增強， 把項目交給他放心。 如今這種例子在商務(wù)談判中已經(jīng)屢見不鮮了。對PM來說，并不要求在各個方面都很精通，那是不可能的事情，只要PM對一些流行的話題和天文地理歷史各方面的知識有個大概的了解， 在需要的時候能盡快的掌握， 才有機會創(chuàng)造機 遇和把握機遇。3. 強大的溝通能力胸中有萬千墨水卻不知如何表達其實是

6、比較少見的， 但并非絕對沒有。 每個人的人生軌跡都有所不同， 思維受環(huán)境的影響也各有差異。 包括象我們目前這個班級里的一些未來的MS日門，一定有比較內(nèi)向或者不太愛表達自己觀點的人， 這些人比較被動， 往往很難承擔(dān)起談判的重任。 從今天開始，這類人就必須重新學(xué)習(xí)如何說話， 如何大聲的爭論。 溝通， 并不僅僅是大聲說話， 而是在表達自己觀點的同時發(fā)現(xiàn)問題并綜合整理加以解決。 除此之外，溝通的能力與社會經(jīng)驗息息相關(guān)，與PM的見識聯(lián)系緊密。在日常生活中，PM就要多留心，多思考，當(dāng)別人想到某個層次的時候要爭取比 別人考慮的更深。 當(dāng)然， 也有一些不夠踏實的朋友把溝通和吹牛當(dāng)成了完全的一回事情， 在和客戶

7、交流的時候口若懸河的說一些不著邊際的話。 這種人， 碰到不懂， 不太認真或者好奇心強的客戶是有一定市場的； 而有水平，負責(zé)任的客戶往往會覺得這種人不可靠，一般不會把單子交給他。 PM需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎(chǔ)的 去吹， 對從來沒涉及過的領(lǐng)域或者根本不懂的東西輕易不要發(fā)表意見， 挑選自己熟悉的方向合理的進行發(fā)揮， 適當(dāng)?shù)牧羯弦粌墒郑?給對方高深莫測 的感覺，效果最好。4. 優(yōu)秀的售前團隊這個團隊一般是由總經(jīng)理發(fā)起并組建的， 通常不指定PMP， 對團隊的成員如SALES PM SA, ENGINEER的團隊合作提出了比較高的要求。一般公司在接下一個單子進行到一定程

8、度的時候，PM往往會尷尬的發(fā)現(xiàn)協(xié)議上銷售代表們對客戶的一些承諾是幾乎做不到或者根本做不到的事情。 這種情況非常多，銷售的任務(wù)是拿下單子，我聽到的銷售們說的最多的就是"沒問題 " 或者 "NO PROBLEM， 但是當(dāng)我聽到客戶的要求和銷售的回答時我"總是心驚肉跳， 很不自然。 銷售是非常辛苦的， 為了建立客戶關(guān)系， 尤其是空白的市場是很不容易的， 往往為了一個單子會犧牲非常多。 在這種情況下，和銷售進行協(xié)調(diào)自然而然的又落到了PM的頭上。在銷售和客戶做承諾之前，P主動的跟銷售交流，提供粗略的總體設(shè)計框架和技術(shù)難關(guān)以及能考慮出的工作量，而不是等出了問題再被動

9、和銷售在老板面前互相推委責(zé)任。在組建團隊的時候，PM要根據(jù)團隊里每個人的素質(zhì)和任務(wù)進行因人置宜的信息傳遞。優(yōu)秀的售前團隊合作是接單的重要保障。在商務(wù)談判的實際操作中，存在著各式各樣的問題，PM的職責(zé)和要求絕非以上幾點所能描述詳盡。 根據(jù)環(huán)境， 政策， 人文， 關(guān)系等各方面的不同情況，PM的不同成長經(jīng)歷，每個PM最終都會建立自己對商務(wù)談判的看法和 經(jīng)驗。但是有一點可以肯定，這是PM成為PM的第一道關(guān)，也是最重要的一關(guān)。接不到單子，PMW失去存在的意義。與銷售有所不同，PM在該階段的任務(wù)除了接單， 還要盡可能的搜集客戶關(guān)鍵人物的資料并與對方各個階層的負責(zé)人建立良好的客戶關(guān)系，以便在項目實施時充分調(diào)

10、動資源。二 . 啟動階段1. 項目的一些基本概念項目三要素有多種版本， 各不相同。 實際操作中多分為范圍， 成本與進度，其中最重要的莫過于范圍。 我們把項目最終生成并提交給用戶的產(chǎn)品和文檔統(tǒng)稱為遞交件。 談判的時候一定要確立遞交件的標(biāo)準(zhǔn)和要求， 也就是范圍。 盡管商戰(zhàn)的時候不可避免的客戶會不斷提高標(biāo)準(zhǔn)和要求， 而承諾的款項卻不會有一分錢的增加。但是這個標(biāo)準(zhǔn)對每個公司來說都有一個底線，一旦超過了這個底線， 那項目就肯定是虧的。 除非是為了二期有利可圖或者是為了搞好關(guān)系，否則范圍超過底線的時候情愿不做，再厲害的 PMI*這種情況下也是無能為力。建立范圍需要的就是PM的多年的實戰(zhàn)經(jīng)驗，在大大小小的項

11、目中用血淚換來的一些體會。在這個時候，很能體現(xiàn)PM與技術(shù)人員的區(qū)別。 成本就是客戶答應(yīng)付的款項， 與我們的投入成本并不是一回事情。進度就不用多描述了。項目如何成功？也有一些關(guān)鍵的因素。 個人的理解也不盡相同， 通常包括以下幾個方面：界定工作目標(biāo)及工作任務(wù)；老板或高層的支持；優(yōu)秀的 PM和開發(fā)團隊；充足的資源；良好的溝通；對客戶的積極反應(yīng)以及適當(dāng)?shù)谋O(jiān)控和反饋。 這里要注意的就是資源和高層的支持。 一個上規(guī)模的公司總 是同時會有很多項目， 可是再大規(guī)模的公司資源也不足以保證每個項目都能組建最合適的開發(fā)隊伍或擁有最好的環(huán)境。 這時候各個團隊或者部門之間不可避免的會發(fā)生資源爭奪戰(zhàn)，摩擦再所難免。這時候

12、對PM的作人再次提出挑戰(zhàn)。除了高層對PM頁目的重視程度，如果PM平時在公司與同事 相處的好往往能使很多別人看起來很棘手的問題迎刃而解。 相反， 一個不 會作人的PM由于人緣差，即使高層強壓別的部門或團隊配合，別人也會 能拖就拖，延緩項目的進度和質(zhì)量。有時候，這種內(nèi)耗對項目和PM來說是毀滅性的。對客戶的積極反應(yīng)也比較關(guān)鍵。一般來說PM已經(jīng)被項目里大大小小的事情搞的筋疲力盡，要PM去主動要求客戶配合是很吃力的事情。然而，這個時候，越是困難，越是覺得累，越是要去主動?？蛻敉膊皇翘貏e的積極， 主動與客戶聯(lián)系溝通和測試能及早發(fā)現(xiàn)問題。 從風(fēng)險控制的角度來說， 問題發(fā)現(xiàn)的越早， 風(fēng)險越小， 損失也就越

13、小。 積極的態(tài)度可以帶動客戶的積極性， 在項目完工的時候， 客戶對你的感激往往是難以用語言描述的， 這對以后接單或者做二期三期會打下良好的基礎(chǔ)。 因為 在和別的新客戶談判的時候， 新客戶自然會找你的老客戶了解情況， 這時 老客戶隨意的一句話頂?shù)纳夏愫苜M心的十句。項目具有商業(yè)行為的幾個重要特征， 有消費源， 有參與者， 有成功關(guān)鍵因 素，有財務(wù)目標(biāo)，有風(fēng)險。2. 啟動階段的主要任務(wù)根據(jù)PMI的解釋，接單之后項目自然轉(zhuǎn)入啟動階段。啟動階段PM的主要任務(wù)是率領(lǐng)總體架構(gòu)設(shè)計師和系統(tǒng)分析員收集盡可能詳細的數(shù)據(jù)， 確立盡 可能詳細的需求， 進一步確立詳細的項目范圍， 預(yù)估資源， 確立其他方案并獲得進入下一

14、階段的批準(zhǔn)。在這個階段，隨著需求分析的深入，PMI&開始在公司內(nèi)部進行人員挑選和資源爭奪， 著手組建自己的項目團隊。 項 目即將進入計劃階段。在收集完數(shù)據(jù)之后，P般和客戶開始明確項目的大小，成本，規(guī)格，期限等重要特征并將其寫入合同文本， 同時準(zhǔn)備內(nèi)部的包括預(yù)算， 衡量標(biāo)準(zhǔn)等文檔，建立項目的評估標(biāo)準(zhǔn)。接下來就是需求分析。由于專業(yè)的原因，我們這里僅討論軟件工程項目的需求分析 （以下簡稱需求分析） 。 需求分析的主要參與人員有PM總體架構(gòu)設(shè)計師，系統(tǒng)分析員，熟悉業(yè)務(wù)流程的客戶。PM統(tǒng)領(lǐng)的團隊這時候還不是真正的開發(fā)團隊，我們叫做前期團隊。 隨著需求分析的逐步深入， 新的團隊成員不斷加入， 啟動

15、階段結(jié)束的時候正式的團隊將建立。 對一個已經(jīng)啟動的項目來說， 需求分析直接決定了項目的成功與失敗。 最初的需求體現(xiàn)在客戶的工作說明書或招標(biāo)文件及附件上。 這種需求一般比較含糊， 無法體現(xiàn)客戶真正的需求。 前期團隊要根據(jù)自己的經(jīng)驗和客戶溝通并引導(dǎo)客戶進入正軌。 有時候客戶會很不講道理或者思路僵化， 就要求按照他的思維去定一些明顯錯誤的需求。 這個時候團隊成員要耐心和客戶舉事實， 談經(jīng)驗， 講道理， 用圖形或模型等直觀的方式將需求描述出來， 比如常見的數(shù)據(jù)流圖等。 所以說， 爭論再所難免， 客戶有時候會吹胡子瞪眼睛拍桌子甚至?xí)f"這個東西不要你們做了 "之類的話。PMlt匕時除

16、了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關(guān)系， 確保關(guān)系不會惡化到無法收拾的地步。 只要PM盡力約束團隊中的成員，這個度還是很容易控制的。對快速開發(fā)和疊代開發(fā)來說， 需求和實現(xiàn)往往是同步進行， 開發(fā)速度快是一大優(yōu)勢。 對有相同或類似模式的小項目來說采用快速開發(fā)或疊代開發(fā)是很合算的做法， 時下流行的極限編程就是針對這方面建立的思維模式。 然而， 大中型項目中有太多不一樣的需求和模塊。 如果不是因為項目有差異，那么市場上就只有產(chǎn)品而沒有項目了。 所以， 大中型項目的需求要認真仔細的去做。 我們要討論一個問題， 究竟應(yīng)該在需求分析和總體設(shè)計上花費多少時間？我們熟悉的瀑布開發(fā)模

17、式基本上分需求分析， 總體設(shè)計， 軟件開發(fā)， 測試等幾個階段， 然而究竟應(yīng)該在前兩個階段上花多少時間卻沒有定論。 實際項目操作的例子表明， 分析設(shè)計的時間越長， 需求設(shè)計做的越詳細， 測試的時間就越短， 返工率越低， 風(fēng)險也越小， 成本越容易得到控制。而需求分析和總體設(shè)計沒有做好就急忙上馬進行開發(fā)的項目在項目初期進展順利的時候問題不大， 到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來， 造成返工， 延長測試時間。 所以與其把問題堆積到緊張的項目后期， 不如把時間多花點到需求分析和總體設(shè)計上。 基礎(chǔ)夯實了， 金字塔就容易造了。 在日本公司打工的程序員們可能都知道， 小

18、日本的軟件規(guī)范非常厲害， 他們花在需求分析和總體設(shè)計上的時間通常在40%到 50%左右，遠遠超過國內(nèi)軟件項目的實施，效果也要強的多。 他們總體設(shè)計的規(guī)范甚至詳盡到某個過程該如何判斷， 確立什么樣的條件，換言之就是把什么時候該如何寫(if.else)語句都幫程序員定好了。 在這樣的軟件規(guī)范下， 程序員更象是裝配流水線上的工人， 對一個模塊或技術(shù)熟悉到一定程序就變成了完全的重復(fù)性勞動。 所以在日本和歐美經(jīng)常會有程序員是低級工作一說， 很多人不明就里， 對國內(nèi)程序員也照搬， 對國內(nèi)的程序員來說是很不公平的。 在國內(nèi)， 只會照抄別人代碼，一點都不懂創(chuàng)新， 凡事依靠別人， 快下班就盯著表看的程序員是不少

19、， 這種人一般很難有什么前途。 但是， 優(yōu)秀的不斷進取的程序員也很多。 由于國內(nèi)沒有象CM陋樣的軟件規(guī)范或者很少，所以這類優(yōu)秀的程序員不少都 是干著系統(tǒng)分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在 起步時會吃很多虧， 而且是主動找虧吃， 然而幾年之后與前一種程序員的社會地位會出現(xiàn)明顯的分化。當(dāng)上進的程序員們作為PM進行商務(wù)談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。日本的軟件規(guī)范與CMMT驚人的相似，其中至少有35姒上都是幾乎一模一樣的。 最近經(jīng)濟不景氣， 東京倒閉了 160 家軟件公司， 這個數(shù)字是今年6 月份的，還在不斷增加。這些公司紛紛

20、搶灘上海，招收技術(shù)人員。如果去這樣的公司應(yīng)聘就要考慮清楚了，進去可以學(xué)到他們的規(guī)范和質(zhì)量控制，可是要想從程序員成為系統(tǒng)分析員或PM比登天還難。往往一個程序員進去干了好幾年， 對自己的那一塊熟的不得了， 而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMMZ伴為印度研究所已經(jīng)通過 CMM4, 對在華為工作的程序員們來說可謂福禍難料。當(dāng)然，已經(jīng)作到PM或QA或者熱愛CODING勺朋友例外。 需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長， 分析員們在客戶的各個部門之間幾乎把腿都跑斷， 把口水說干， 就是為了確立一個初期的需求模型。 所有的文檔將會提交給PM進行復(fù)審并簽字，不合格

21、的打回重做。反饋表隨之將提交給客戶， 第二遍第三遍等等等等接踵而來， 與客戶反復(fù)討論和磋商， 反復(fù)提交文檔和表格，目的只有一個，明確需求。當(dāng)PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責(zé)人簽字。 這些文檔將作為合同的附件添加， 以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據(jù)。需要說明的是， 客戶并非都是蠻不講理， 但是說實話， 頗有無奈， 國內(nèi)目前的項目大多數(shù)客戶為了不讓自己的錢白花， 經(jīng)常變著法子提需求。 在啟動階段明確需求并簽字， 無論最終情況如何， 一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。 詳盡的需求分析有一個額外

22、的好處就是對一些雙方都很陌生或者從來無人嘗試的領(lǐng)域?qū)⑹且粋€決定是否進行項目的判斷標(biāo)準(zhǔn)。 有時候， 這種大項目在簽單時雙方都沒有絕對把握保證可以出成果， 一旦在需求分析階段發(fā)現(xiàn)難以逾越的技術(shù)難關(guān)，就會放棄項目。典型的例子就是NMD'N際導(dǎo)彈防御系統(tǒng)。上世紀八十年代初美國搞星球大戰(zhàn)計劃，拖跨了蘇聯(lián)。大家對那段歷史有些含糊，很多人認為蘇聯(lián)人上了美國的當(dāng)。 其實并不完全如此， 蘇聯(lián)人的情報機構(gòu)無孔不入， 并非那么容易上當(dāng)受騙。 實際上當(dāng)時美國國防部已經(jīng)開始著手NM疏統(tǒng)軟件的需求分析，前后耗資數(shù)億美圓，耗時兩年，僅僅是做需求分析，終于發(fā)現(xiàn)存在著在當(dāng)時技術(shù)上無法達到的高度，隨后項目被放棄。3. 項

23、目啟動 項目啟動要確定項目計劃， 與客戶一起實施第一次項目審核， 確認并對一些產(chǎn)品和服務(wù)向下包廠商下訂單。這個時候的PM會忽然發(fā)現(xiàn)有開不完的會， 一天開三到四個會議是很正常的事情。 這些會議有與客戶的會議， 與下包廠商的， 有團隊的， 有公司高層的。 團隊的會議主要是建立正式的團隊， 提供團隊成員的角色和職責(zé)， 提供績效管理方法， 向成員提供項目范圍和目標(biāo)。與客戶的一個主要會議將是項目啟動會議。在這個會議上 PM會與客戶確立正式的交流渠道， 項目綜合描述， 讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小， 電話多少部， 所有人的聯(lián)系方式等等都要

24、在會議上確立， 并做會議記錄。這都是些非?，嵥榈氖虑?，聽起來婆婆* ，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。這時候，作為公司高層，應(yīng)該向全公司發(fā)表申明，正式給PM發(fā)布項目經(jīng)理任命書和項目授權(quán)書。 這個動作雖然在別人看來有些形式主義， 但是對提高PM本人的士氣和責(zé)任感是有很大助力的。三 . 計劃階段1. 定義結(jié)構(gòu)分工結(jié)構(gòu)圖（WBS）啟動階段結(jié)束后， 項目進入計劃階段， 也就正式進入實施。 這里概念可能有些不太對頭， 其實是翻譯的緣故， 反正大家明白意思就行， 不用拘泥于字面。WB系一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內(nèi)容， 資源， 成本角度考慮項目

25、范圍； 建立一套系統(tǒng)所需要的分層工作結(jié)構(gòu)；把項目分解成易于管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。可以說，WB系計劃階段的核心。WB噲詳細的分到遞交件，包括給自己人用的項目使用的過程文件， 給客戶用的模塊和說明文檔， 完成每個細目的標(biāo)準(zhǔn)以及如何把這些細目的責(zé)任分配到具體的個人。WBST縮進式和樹狀式，我這里也沒辦法畫圖，大家 參考一些項目管理的書籍， 里面有詳細介紹。 我整個文章只挑我覺得需要注意的地方，如非必要，對技術(shù)細節(jié)或者工具使用不做詳細介紹。WBS勺細目并不需要分解到同一水平， 最下面的細目叫做工作包， 分包的依據(jù)是 個人的責(zé)任和可信度， 也就是說到每個人頭

26、上的任務(wù)是否能落實， 是否有 把握完成；還有就是準(zhǔn)備對項目進行控制的程度，程度越深，WBS寸也就越深。由于WB邃實用性的東西，根據(jù)個人理解也不一樣，所以一個項目 可能會有幾個正確的 WBS看PM的需要和最適合當(dāng)前團隊狀態(tài)的進行選 擇。WBS勺定義還是很麻煩的。PM要召開團隊進行討論，向成員提供與項目相關(guān)的所有詳細資料， 并把W BS樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風(fēng)暴式(BRAINING STORM思考，制訂工作產(chǎn)出和相應(yīng)人員的職責(zé)， 記錄每一個工作 包的完成標(biāo)準(zhǔn)。在頭腦風(fēng)暴式思考時，會有很激烈的爭論，PM要協(xié)調(diào)關(guān)系， 調(diào)節(jié)氣氛， 從自己能考慮到的各個角度旁推側(cè)敲， 提示成員

27、的思維角度和方向并加以總結(jié)。盡管很麻煩，制訂WBS5然是非常值得的。如同需 求分析一樣，WBSB備的越充分，編碼的進度越快。2. 風(fēng)險管理既然是商業(yè)行為， 那么項目的風(fēng)險必然存在， 相信閱讀這個帖子的朋友不少人都經(jīng)歷過或大或小的風(fēng)險。 有些風(fēng)險很容易解決， 有些風(fēng)險則大大損害利益。 不論什么樣的風(fēng)險， 能避免盡量避免， 所以有必要對風(fēng)險進行管理。 由于風(fēng)險的不可預(yù)知性， 風(fēng)險管理難度很大， 概念也很難講清楚， 只能從一些可行的角度去分析，進行管理。首先要識別風(fēng)險。這是個難度很高的活。P般先召開風(fēng)險識別會議，這個會議面向公司， 高層， 跨部門的有經(jīng)驗的人都將參加。 然后審核由項目小組生成的風(fēng)險清

28、單并與重要成員進行風(fēng)險溝通， 檢查一些重要的風(fēng)險源如WBS成本（時間）預(yù)估，人員計劃，采購管理等等。最后就要用到 PM本身在以前類似項目中得到的經(jīng)驗教訓(xùn)。識別之后要進行分析。 我們可以進行粗略的量化分析 （精確分析是不可能的事情）。有經(jīng)驗的人可以一起參加討論，把提交出來的風(fēng)險進行分類。首先按發(fā)生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合， 碰到可能性也高， 成本也高的風(fēng)險就定位為不能接受。 碰到這種風(fēng)險只好讓客戶修改需求或者增加風(fēng)險預(yù)留成本， 否則一旦虧起來不是虧一點點， 有可能賠的很

29、厲害。 高和中， 中和中的搭配都是屬于高風(fēng)險， 中和低， 低和低搭配屬于低， 高和低搭配屬于中。針對出現(xiàn)的可能性， 需要采取一些手段降低風(fēng)險。 到目前為止也沒有一個定論說有絕對好的方式， 只能盡其所能的避免。 有幾種方法可以考慮， 第一種是將風(fēng)險納入項目管理計劃并指定負責(zé)人， 由外部人員定期檢查項目 風(fēng)險， 一旦風(fēng)險發(fā)生， 執(zhí)行風(fēng)險管理計劃； 第二種是保險， 這種屬于風(fēng)險 轉(zhuǎn)嫁； 第三種方式有點奸， 不過最保險， 就是把客戶拖下水， 讓他們一起參與風(fēng)險管理， 呵呵， 到時候就好說話了： ) 風(fēng)險管理作為項目計劃之后，PMR要更新WBS修改日程計劃和更新風(fēng)險管理計劃。風(fēng)險預(yù)留通常是成本的8%。3

30、. 預(yù)估預(yù)估是從量化的角度對項目進行評估， 主要包括工作量， 任務(wù)期限， 人力，設(shè)備， 材料， 成本等， 要注意預(yù)估不是財務(wù)策略或報價。 預(yù)估其實并不是一次性工作， 在整個項目過程中， 預(yù)估始終需要。 預(yù)估似乎沒什么特別需要提的地方，每個PM接到項目的時候自然會有預(yù)估，在項目發(fā)生變更或進入下一階段時也會預(yù)估。預(yù)估的作用主要還是讓PM作到心中有個底， 安排計劃時不至于毫無頭緒。4.進度計劃 進度計劃就是一個模塊或功能要寫多長時間， P砥排個日 期，設(shè)立里程碑，叫程序員們不能偷懶。進度計劃是從 WBSI取過來的。對PM來說，合理的安排進度計劃對項目控制和激勵團隊士氣有著很大的作用。 對程序員來說，

31、 進度計劃毫無疑問是噩夢。 顯示進度計劃一般有先后順序圖，甘特圖和里程碑圖表。上回邵衛(wèi)老師講課，推薦的工具是m$W PROJECTT這個工具我還不會用，因為沒時間去摸索。我的頭倒是用的很溜了，近一個月來他就用這個 PROJEC畫了一個又一個的里程碑圖，不停的折磨我和同事的神經(jīng)。 我們一般都是一邊開發(fā)一邊做UNIT TEST，效果上來看， 因為有強大的時間壓力， 效率上比之前確實要提高不少， 可是我們也只能結(jié)結(jié)巴巴的趕完進度。由于TEAM1人少，我們都是一個人做幾個人的活。 我每天早晨六點多出門， 經(jīng)過將近兩小時顛簸， 八點多點已經(jīng)坐在位子上，中午吃 15 分鐘的飯，干到晚上八點下班，到家吃完飯

32、往往已經(jīng) 11 點了。一個多月我從來沒吃過早飯，沒有睡過六個小時以上的懶覺。 雖然強大的壓力使我們能在短時間內(nèi)掌握盡可能多的技能， 開發(fā)更多的模塊， 但是對我們的情緒也是有很大的影響。 所以說， 項目里程碑是一把雙刃劍， 合理安排才能既促進效率也不至于打擊士氣。 團隊成員士氣的逐級衰落會給項目后期的開發(fā)帶來難以估計的影響， 進度將會大大延緩。關(guān)于PMB團隊的問題我們后面會講到，這里我先祥林嫂一把，然后跳過。 里程碑圖表的特征是任務(wù)， 成員和時間， 任務(wù)和成員用文字標(biāo)志，時間用數(shù)字描述并輔助以圖線跨度， 象階梯一樣非常形象， 一目了然。 管理起來非常方便，完了的打個鉤就可以了。網(wǎng)絡(luò)邏輯圖是表示任

33、務(wù)和邏輯關(guān)系的示意圖， 可以用先后次序表示， 也可以用關(guān)鍵路徑表示。其實把各個活動劃分為 1 ， 2， 3， 4 等階段，每個階段包括小活動1.1 ， 1.2 ， 2.1 ， 2.2 ， 2.3 ， 2.4 ， 3.1 ， 3.2 ， 3.3 ， 4.1 ， 4.2 等，日程計劃也分四種，一般只提到從前向后和從后向前兩種。從前向后的概念就是某項活動必須相同或晚于直接指向這項活動的的所有活動的最早結(jié)束時間的最晚時間。有些繞口，我們打個比方： 2 階段指向 3 階段，那么 2 階段里的 4 個子階段也都指向 3。假設(shè) 2.1 結(jié)束時間為 1 月 12 日， 2.2 結(jié)束時間為 1 月 22 日，

34、2.3 結(jié)束時間為 1 月 15 日， 2.4 結(jié)束時間為 1 月 20 日，那么， 2 階段中最晚的結(jié)束時間是2.2 的 1 月 22 日，所以在 3 階段中的 3 個子階段 3.1 ， 3.2 ， 3.3 的最早開始時間都不能早于 1月 22 日。至于從后向前的例子大家自己去推吧，我就不舉了，剛才幾個123 打的我累死了：） 項目經(jīng)常需要調(diào)整進度。在不改變項目范圍的情況下， 調(diào)整進度有幾種方法： 利用快速跟蹤手段來改變?nèi)蝿?wù)間的關(guān)系； 將串行的任務(wù)改成并行；改變工作方法（可能改變WBS ;改變?nèi)掌谙拗?，使關(guān)鍵路徑上的任務(wù)開始或結(jié)束的更早。雖然方法多樣化，在我看來只有一條，就是拼命的壓榨程序員

35、的勞動力。如何壓榨， 還是個技巧。 如前面所分析的， 需求分析恨不得多分點時間給它， 壓需求是不太可能； 測試階段后期接近完工， 羅里巴唆的事情一大堆，忙都忙不完，那時候PML門心思提前/按時完工，好收錢，壓那段時間似乎也不太可能。說來殘酷，最能壓的還是CODING編碼階段往往是壓縮重點， 總之大家埋頭苦干就是了， 大項目壓縮的時候程序員吃喝拉撒都在公司是很正常的事情， 相信不少人都有很深的體會， 這里傷心事情也就不提了。只是我總結(jié)一下，讓未來的PM們有壓榨后來人的依據(jù)，呵呵。測試前期也可以適當(dāng)?shù)膲阂粔海?那時候人剛完工， 都比較懶散。 國內(nèi)一般企業(yè)規(guī)模都不大， 沒有專門的質(zhì)量控制部門， 所以

36、質(zhì)量保證和測試往往就是程序員或PM本身。其實質(zhì)量保證和測試人員的人數(shù)和素質(zhì)都應(yīng)該要高于程序員。在日本和CMM?施的公司里，編碼壓縮是很容易實現(xiàn)的事情，因為那些程序員真的是技能熟練的裝配工人， 壓起來方便的很。 他們這樣培養(yǎng)人的目的或許就是為了壓縮吧？！ 四. 控制和執(zhí)行階段1 . 軟件開發(fā) 實在沒什么好說的， 也是大家最不愿意談的， 平時在公司里談的已經(jīng)夠多的了， 還要在這里受我嘮叨。 需要提醒的依然是團隊合作精神和完善的文檔管理制度。SOURCESAFE工具有時候還是有必要使用的。 經(jīng)?？吹接腥苏f天才程序員不寫注釋什么的。 我相信有這種天才程序員，因為我碰到過幾個。我愛人公司里也有一個， 他

37、們的一套產(chǎn)品核心代碼就是這個人寫的， 4 年過去了， 周邊代碼換了好幾茬， 核心算法始終沒換過， 可惜這小子跟了李洪痔， 如今已經(jīng)不知所蹤了。 但是他的代碼似乎也要有點注釋的， 沒有注釋過段時間再天才的程序員也不能保證他是最有記憶力的。 而且， 對一個項目的編碼來說， 靠一兩個人打天下如今是不可能了。 別人的公司都是團隊， 兩人智慧勝一人， 這頭還在靠一個天才支撐門面， 實際上市場可就別人搶了去，那時候再天才也沒用了。編碼的時候講究技術(shù)公開，程序員不要藏著掖著，對大家沒好處，PMB里想辦法調(diào)動大家創(chuàng)新思維的積極性， 營造良好的技術(shù)討論氛圍， 碰到技術(shù)難關(guān)的時候就容易攻破了。有個問題需要單獨對還

38、沒有 PM覺悟的程序員說， 其實是在調(diào)研的時候就定了的， 就是使用什么樣的開發(fā)工具。 沒有經(jīng)驗的程序員往往會拿著C+鉞者JAVA的資格證書或者擁有一兩個開發(fā)工具的一些經(jīng)驗而得意洋洋。其實老板和PM根本不看重這個，他們關(guān)心的是使用什么樣的工具能盡快的達到目的。管你什么C+， DELPH，I PB還是JAVA只要能做的出來，VFP都可以用。我舉這個例子并非說不看中 工具，而是提醒想轉(zhuǎn)型為 PM的程序員，第一要把工具當(dāng)作工具，而不要 被工具套進去， 鉆研一些一輩子都用不上的技術(shù)； 第二要掌握的并非是單獨的一個工具， 而是流行的程序設(shè)計的思想， 以及在最短時間內(nèi)掌握一門陌生工具的能力。只有建立了這樣的

39、思維，才有可能轉(zhuǎn)為 PM否則一輩子都是技術(shù)工人，最多就是個技術(shù)總監(jiān)。2 . 變更 對任何項目， 變更無可避免， 無從逃避， 只能去積極應(yīng)對， 這個應(yīng)對應(yīng)該是從需求分析就開始了。對一個需求分析做的很好的項目來說，基準(zhǔn)文件定義的范圍越詳細清晰，用戶跟PM扯皮的幌子就越少。而需求沒做好， 基準(zhǔn)文件里的范圍含糊不清， 被客戶抓住空子搞你一下是非常頭疼的事情， 往往要付出無謂的犧牲， 有時候甚至非?；鸫?。 需求做的好，文檔清晰又有客戶簽字，那么后期客戶提出的變更就超出了合同的范圍，需要另外收費。 這個時候千萬不能手軟， 并非要刻意賺取客戶的錢財， 而是不能養(yǎng)成客戶經(jīng)常變更的習(xí)慣，否則后患無窮，維護的成本

40、會讓PM吃不消。在客戶提出變更請求時， 要建立變更申請登記表和變更申請表， 并讓客戶簽字。當(dāng)然，有時候一些不是非常關(guān)鍵的模塊PMm不至于一點不講情面，該賣面子的時候還是要賣， 尤其是當(dāng)著對方領(lǐng)導(dǎo)的面， 千萬要賣面子， 但是也別賣的太干脆， 不要讓他們得到的太容易。 需求做的不好， 客戶抓住漏洞或者非常不講道理， 麻煩就大了。 有時候爭論會很厲害， 到非常白熱化的地步，PM與客戶代表幾乎溝通不了。PM在客戶關(guān)系和短期利益兩方面難以取舍， 一般都是向客戶妥協(xié)， 最終形成惡性循環(huán)。 這種情況非常難辦。 一般這種情況都是到了項目后期， 做重大的更改幾乎是不可能的事情，如果白做就要虧錢。而這個時候如果P

41、M艮對方高層的人關(guān)系搞的定，可以透過對方高層把事情壓住。 然而由于已經(jīng)到后期， 客戶代表不會輕易更換， 對方這次沒有改成， 必然心懷不滿， 下回在別的模塊依然會找麻煩或者在談二期的時候動動手腳，都是很讓PM方腦筋的事情，這方面目前 還沒有什么好的解決方法， 所以盡可能的做好需求比什么都重要。 相對需 求來說，什么wbs風(fēng)險管理，計劃進度都是扯淡，需求做好了，一帆風(fēng) 順。還有一種辦法就是裝可憐，要裝的非常的象，在對方的領(lǐng)導(dǎo)面前裝，而且不能讓人看出是裝的樣子， 要讓你自己都覺得你自己是真的可憐， 那 么就算這次客戶硬是要求改了， 下回他也必然不好意思再叫你改。 其實人 心都是肉長的， 如果可能的話， 我還是不贊同使用一些手段的， 但是有時 候客戶非常難以在短時間打動而工期又將接近，這種情況下就要靠PM要一些手段了。各人有各人的方式，八仙過海，各顯神通吧。P帳變更管理中需要做的是分析變更請求， 評估變更可能帶來的風(fēng)險和修改基準(zhǔn)文 件。3 .質(zhì)量控制 大公司有質(zhì)量管理部門（QA , QA的成員基本