項目管理的五大過程

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

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

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

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

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

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

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

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

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

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

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

12、時在公司與同事相處的好往往能使很多 別人看起來很棘手的問題迎刃而解。相反，一個不會作人的PM由于人緣差，即使高層強(qiáng)壓別的部門或團(tuán)隊配合，別人也會能拖就拖，延緩項目的進(jìn)度和 質(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)險越小， 損失也就越小。積極的態(tài)度可以帶動客戶的積極性，在項目完工的時候，客 戶對你的感激往

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

14、建自己的項目團(tuán)隊。項目即將進(jìn)入計劃 階段。在收集完數(shù)據(jù)之后，PM要和客戶開始明確項目的大小，成本，規(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)的團(tuán)隊這時候還不是真正的開發(fā)團(tuán)隊，我們叫做前期團(tuán)隊。隨著需求分析的逐 步深入，新的團(tuán)隊成員不斷加入，啟動階段結(jié)束的時候正式的團(tuán)隊將建立。 對一個已經(jīng)啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初 的需求體現(xiàn)在

15、客戶的工作說明書或招標(biāo)文件及附件上。這種需求一般比較含 糊，無法體現(xiàn)客戶真正的需求。前期團(tuán)隊要根據(jù)自己的經(jīng)驗(yàn)和客戶溝通并引 導(dǎo)客戶進(jìn)入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的 思維去定一些明顯錯誤的需求。這個時候團(tuán)隊成員要耐心和客戶舉事實(shí)，談 經(jīng)驗(yàn)，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數(shù) 據(jù)流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至 會說"這個東西不要你們做了 ”之類的話。PM此時除了要親身參與需求分析綜 合整理文檔之外，還要處理好團(tuán)隊成員與客戶的關(guān)系，確保關(guān)系不會惡化到 無法收拾的地步。只要PM盡力約束團(tuán)隊中的成員，這個度

16、還是很容易控制的。對快速開發(fā)和疊代開發(fā)來說，需求和實(shí)現(xiàn)往往是同步進(jìn)行，開發(fā)速度快是一 大優(yōu)勢。對有相同或類似模式的小項目來說采用快速開發(fā)或疊代開發(fā)是很合 算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大 中型項目中有太多不一樣的需求和模塊。如果不是因?yàn)轫椖坑胁町?，那么?場上就只有產(chǎn)品而沒有項目了。所以，大中型項目的需求要認(rèn)真仔細(xì)的去做。 我們要討論一個問題，究竟應(yīng)該在需求分析和總體設(shè)計上花費(fèi)多少時間？我 們熟悉的瀑布開發(fā)模式基本上分需求分析，總體設(shè)計，軟件開發(fā)，測試等幾 個階段，然而究竟應(yīng)該在前兩個階段上花多少時間卻沒有定論。實(shí)際項目操 作的例子表明，分析設(shè)計的時間越長，需

17、求設(shè)計做的越詳細(xì)，測試的時間就 越短，返工率越低，風(fēng)險也越小，成本越容易得到控制。而需求分析和總體設(shè)計沒有做好就急忙上馬進(jìn)行開發(fā)的項目在項目初期進(jìn)展 順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞 作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問 題堆積到緊張的項目后期，不如把時間多花點(diǎn)到需求分析和總體設(shè)計上。基 礎(chǔ)夯實(shí)了，金字塔就容易造了。 ?在日本公司打工的程序員們可能都知道，小 日本的軟件規(guī)范非常厲害， 他們花在需求分析和總體設(shè)計上的時間通常在 40% 到 50%左右，遠(yuǎn)遠(yuǎn)超過國內(nèi)軟件項目的實(shí)施，效果也要強(qiáng)的多。他們總體設(shè)計 的規(guī)范甚至詳盡到某個過程

18、該如何判斷，確立什么樣的條件，換言之就是把 什么時候該如何寫 (if.else)語句都幫程序員定好了。在這樣的軟件規(guī)范下，程序員更象是裝配流水線上的工人，對一個模塊或技術(shù)熟悉到一定程序 就變成了完全的重復(fù)性勞動。所以在日本和歐美經(jīng)常會有程序員是低級工作 一說，很多人不明就里，對國內(nèi)程序員也照搬，對國內(nèi)的程序員來說是很不 公平的。在國內(nèi)，只會照抄別人代碼，一點(diǎn)都不懂創(chuàng)新，凡事依靠別人，快 下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優(yōu)秀 的不斷進(jìn)取的程序員也很多。由于國內(nèi)沒有象 CMM這樣的軟件規(guī)范或者很少， 所以這類優(yōu)秀的程序員不少都是干著系統(tǒng)分析員甚至 PM的活，拿著程序員

19、的 工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年 之后與前一種程序員的社會地位會出現(xiàn)明顯的分化。 當(dāng)上進(jìn)的程序員們作為 P M進(jìn)行商務(wù)談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。 有些扯開了，回到我們的話題。日本的軟件規(guī)范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣 的。最近經(jīng)濟(jì)不景氣，東京倒閉了 160家軟件公司，這個數(shù)字是今年 6 月份 的，還在不斷增加。這些公司紛紛搶灘上海，招收技術(shù)人員。如果去這樣的 公司應(yīng)聘就要考慮清楚了，進(jìn)去可以學(xué)到他們的規(guī)范和質(zhì)量控制，可是要想 從程序員成為系統(tǒng)分析員或 PM比登天還難。往往一個程序員進(jìn)去干了好幾

20、年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳 華為正在嘗試CMM4華為印度研究所已經(jīng)通過CMM），對在華為工作的程序 員們來說可謂福禍難料。當(dāng)然，已經(jīng)作到 PM或 QA或者熱愛CODING勺朋友例 外。 ?需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最 長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為 了確立一個初期的需求模型。所有的文檔將會提交給PM進(jìn)行復(fù)審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而 來，與客戶反復(fù)討論和磋商，反復(fù)提交文檔和表格，目的只有一個，明確需 求。當(dāng)PM最終合并了所有文檔并確立需

21、求之后，最終生成的需求文檔將提交 給客戶的各部門負(fù)責(zé)人簽字。這些文檔將作為合同的附件添加，以便在將來 項目變更或者碰到重大問題時和客戶扯皮的重要依據(jù)。需要說明的是，客戶并非都是蠻不講理，但是說實(shí)話，頗有無奈，國內(nèi)目前 的項目大多數(shù)客戶為了不讓自己的錢白花，經(jīng)常變著法子提需求。在啟動階 段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多 口頭承諾或概念模糊的文檔帶來的許多問題。 ?詳盡的需求分析有一個額外的 好處就是對一些雙方都很陌生或者從來無人嘗試的領(lǐng)域?qū)⑹且粋€決定是否進(jìn) 行項目的判斷標(biāo)準(zhǔn)。有時候，這種大項目在簽單時雙方都沒有絕對把握保證 可以出成果，一旦在需求分析階段發(fā)現(xiàn)難以

22、逾越的技術(shù)難關(guān)，就會放棄項目。典型的例子就是NMD洲際導(dǎo)彈防御系統(tǒng)。上世紀(jì)八十年代初美國搞星球大戰(zhàn)計劃，拖跨了蘇聯(lián)。大家對那段歷史有些含糊，很多人認(rèn)為蘇聯(lián)人上了美國 的當(dāng)。其實(shí)并不完全如此，蘇聯(lián)人的情報機(jī)構(gòu)無孔不入，并非那么容易上當(dāng) 受騙。實(shí)際上當(dāng)時美國國防部已經(jīng)開始著手 NM系統(tǒng)軟件的需求分析，前后 耗資數(shù)億美圓，耗時兩年，僅僅是做需求分析，終于發(fā)現(xiàn)存在著在當(dāng)時技術(shù) 上無法達(dá)到的高度，隨后項目被放棄。3. 項目啟動項目啟動要確定項目計劃，與客戶一起實(shí)施第一次項目審核，確認(rèn)并對一些 產(chǎn)品和服務(wù)向下包廠商下訂單。這個時候的 PM會忽然發(fā)現(xiàn)有開不完的會，一 天開三到四個會議是很正常的事情。這些會議

23、有與客戶的會議，與下包廠商 的，有團(tuán)隊的，有公司高層的。團(tuán)隊的會議主要是建立正式的團(tuán)隊，提供團(tuán) 隊成員的角色和職責(zé)，提供績效管理方法，向成員提供項目范圍和目標(biāo)。與 客戶的一個主要會議將是項目啟動會議。在這個會議上 PM會與客戶確立正式 的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以 PM為核心的 管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部， 所有人的聯(lián)系方式等等都要在會議上確立，并做會議記錄。這都是些非常瑣 碎的事情，聽起來婆婆 * ，卻是非常必要，缺一不可。大概就是所謂三軍未 動，糧草先行吧。 ?這時候，作為公司高層，應(yīng)該向全公司發(fā)表申明，正式給PM發(fā)布項目

24、經(jīng)理任命書和項目授權(quán)書。這個動作雖然在別人看來有些形式主義，但是對提高 PM 本人的士氣和責(zé)任感是有很大助力的。三. 計劃階段1. 定義結(jié)構(gòu)分工結(jié)構(gòu)圖（ WBS）?啟動階段結(jié)束后，項目進(jìn)入計劃階段，也就正式進(jìn)入實(shí)施。這里概念可能有 些不太對頭，其實(shí)是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。WBS是 一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工 作內(nèi)容，資源，成本角度考慮項目范圍；建立一套系統(tǒng)所需要的分層工作結(jié) 構(gòu)；把項目分解成易于管理的幾個細(xì)目，這概念有些模糊，其實(shí)跟資源管理 器里分目錄是一回事情?？梢哉f， WBS是計劃階段的核心。WB陰詳細(xì)的分到 遞交件，包括給自

25、己人用的項目使用的過程文件，給客戶用的模塊和說明文 檔，完成每個細(xì)目的標(biāo)準(zhǔn)以及如何把這些細(xì)目的責(zé)任分配到具體的個人。 WBS 有縮進(jìn)式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍， 里面有詳細(xì)介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技 術(shù)細(xì)節(jié)或者工具使用不做詳細(xì)介紹。 WBS勺細(xì)目并不需要分解到同一水平， 最 下面的細(xì)目叫做工作包，分包的依據(jù)是個人的責(zé)任和可信度，也就是說到每 個人頭上的任務(wù)是否能落實(shí)，是否有把握完成；還有就是準(zhǔn)備對項目進(jìn)行控 制的程度，程度越深，WBS寸也就越深。由于 WBS是實(shí)用性的東西，根據(jù)個人 理解也不一樣，所以一個項目可能會有幾個正確的 WB

26、S看PM的需要和最適 合當(dāng)前團(tuán)隊狀態(tài)的進(jìn)行選擇。 ?wbS勺定義還是很麻煩的PM要召開團(tuán)隊進(jìn)行討論，向成員提供與項目相關(guān)的所有詳細(xì)資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員進(jìn)行頭腦風(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è)敲，提示成員的思維角度和方向并加以總 結(jié)。盡管很麻煩，制訂 WBS仍然是非常值得的。如同需求分析一樣， WBSt備 的越充分，編碼的進(jìn)度越快。2. 風(fēng)險管理既然是商業(yè)行為，那么項目的風(fēng)險必然存在，相信閱讀

27、這個帖子的朋友不少 人都經(jīng)歷過或大或小的風(fēng)險。有些風(fēng)險很容易解決，有些風(fēng)險則大大損害利 益。不論什么樣的風(fēng)險，能避免盡量避免，所以有必要對風(fēng)險進(jìn)行管理。由 于風(fēng)險的不可預(yù)知性，風(fēng)險管理難度很大，概念也很難講清楚，只能從一些 可行的角度去分析，進(jìn)行管理。首先要識別風(fēng)險。這是個難度很高的活。 PM要先召開風(fēng)險識別會議，這個會 議面向公司，高層，跨部門的有經(jīng)驗(yàn)的人都將參加。然后審核由項目小組生 成的風(fēng)險清單并與重要成員進(jìn)行風(fēng)險溝通，檢查一些重要的風(fēng)險源如WBS成 本（時間）預(yù)估，人員計劃，采購管理等等。最后就要用到PM本身在以前類似項目中得到的經(jīng)驗(yàn)教訓(xùn)。識別之后要進(jìn)行分析。我們可以進(jìn)行粗略的量化分析

28、（精確分析是不可能的事情）。有經(jīng)驗(yàn)的人可以一起參加討論，把提交出來的風(fēng)險進(jìn)行分類。首先 按發(fā)生的可能性分，一般分成高，中，低三個級別，雖然很勉強(qiáng)，但是好歹 也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這 兩種類別的三個級別進(jìn)行組合，碰到可能性也高，成本也高的風(fēng)險就定位為 不能接受。碰到這種風(fēng)險只好讓客戶修改需求或者增加風(fēng)險預(yù)留成本，否則 一旦虧起來不是虧一點(diǎn)點(diǎn)，有可能賠的很厲害。高和中，中和中的搭配都是 屬于高風(fēng)險，中和低，低和低搭配屬于低，高和低搭配屬于中。針對出現(xiàn)的可能性，需要采取一些手段降低風(fēng)險。到目前為止也沒有一個定 論說有絕對好的方式，只能盡其所能的避免。有幾種方

29、法可以考慮，第一種 是將風(fēng)險納入項目管理計劃并指定負(fù)責(zé)人，由外部人員定期檢查項目風(fēng)險， 一旦風(fēng)險發(fā)生，執(zhí)行風(fēng)險管理計劃；第二種是保險，這種屬于風(fēng)險轉(zhuǎn)嫁；第 三種方式有點(diǎn)奸，不過最保險，就是把客戶拖下水，讓他們一起參與風(fēng)險管 理，呵呵，到時候就好說話了：）？風(fēng)險管理作為項目計劃之后，PM需要更新WBS修改日程計劃和更新風(fēng)險管理計劃。 ？風(fēng)險預(yù)留通常是成本的8%3. 預(yù)估預(yù)估是從量化的角度對項目進(jìn)行評估，主要包括工作量，任務(wù)期限，人力， 設(shè)備，材料，成本等，要注意預(yù)估不是財務(wù)策略或報價。 ？預(yù)估其實(shí)并不是一 次性工作，在整個項目過程中，預(yù)估始終需要。預(yù)估似乎沒什么特別需要提 的地方，每個PM接到項

30、目的時候自然會有預(yù)估，在項目發(fā)生變更或進(jìn)入下一階段時也會預(yù)估。預(yù)估的作用主要還是讓 PM作到心中有個底，安排計劃時不 至于毫無頭緒。4.進(jìn)度計劃？進(jìn)度計劃就是一個模塊或功能要寫多長時間，PM安排個日期，設(shè) 立里程碑，叫程序員們不能偷懶。進(jìn)度計劃是從 WBSI取過來的。對PM來說， 合理的安排進(jìn)度計劃對項目控制和激勵團(tuán)隊士氣有著很大的作用。對程序員 來說，進(jìn)度計劃毫無疑問是噩夢。 ？顯示進(jìn)度計劃一般有先后順序圖，甘特圖 和里程碑圖表。上回邵衛(wèi)老師講課，推薦的工具是 m啲PROJECT這個工具 我還不會用，因?yàn)闆]時間去摸索。我的頭倒是用的很溜了，近一個月來他就 用這個PROJEC畫了一個又一個的里

31、程碑圖，不停的折磨我和同事的神經(jīng)。 我們一般都是一邊開發(fā)一邊做 UNIT?TEST效果上來看，因?yàn)橛袕?qiáng)大的時間壓 力，效率上比之前確實(shí)要提高不少，可是我們也只能結(jié)結(jié)巴巴的趕完進(jìn)度。由于TEAMS人少，我們都是一個人做幾個人的活。我每天早晨六點(diǎn)多出門， 經(jīng)過將近兩小時顛簸，八點(diǎn)多點(diǎn)已經(jīng)坐在位子上，中午吃 15 分鐘的飯，干到 晚上八點(diǎn)下班，到家吃完飯往往已經(jīng) 11 點(diǎn)了。一個多月我從來沒吃過早飯， 沒有睡過六個小時以上的懶覺。雖然強(qiáng)大的壓力使我們能在短時間內(nèi)掌握盡 可能多的技能，開發(fā)更多的模塊，但是對我們的情緒也是有很大的影響。所 以說，項目里程碑是一把雙刃劍，合理安排才能既促進(jìn)效率也不至于打擊

32、士 氣。團(tuán)隊成員士氣的逐級衰落會給項目后期的開發(fā)帶來難以估計的影響，進(jìn) 度將會大大延緩。關(guān)于PM和團(tuán)隊的問題我們后面會講到，這里我先祥林嫂一 把，然后跳過。 ?里程碑圖表的特征是任務(wù)，成員和時間，任務(wù)和成員用文字 標(biāo)志，時間用數(shù)字描述并輔助以圖線跨度，象階梯一樣非常形象，一目了然。 管理起來非常方便，完了的打個鉤就可以了。網(wǎng)絡(luò)邏輯圖是表示任務(wù)和邏輯關(guān)系的示意圖，可以用先后次序表示，也可以 用關(guān)鍵路徑表示。其實(shí)把各個活動劃分為 1，2，3，4 等階段，每個階段包括 小活動，等，日程計劃也分四種，一般只提到從前向后 和從后向前兩種。從前向后的概念就是某項活動必須相同或晚于直接指向這 項活動的的所有

33、活動的最早結(jié)束時間的最晚時間。有些繞口，我們打個比方： 2 階段指向 3 階段，那么 2 階段里的 4 個子階段也都指向 3 。假設(shè)結(jié)束時間為 1月12日，結(jié)束時間為 1月22日，結(jié)束時間為 1月 15日，結(jié)束時間為 1月 20日，那么， 2階段中最晚的結(jié)束時間是的 1月22日，所以在 3階段中的 3 個子階段，的最早開始時間都不能早于 1月 22日。至于從后向前的例子大 家自己去推吧，我就不舉了，剛才幾個 123 打的我累死了：） ?項目經(jīng)常需要 調(diào)整進(jìn)度。在不改變項目范圍的情況下，調(diào)整進(jìn)度有幾種方法：利用快速跟 蹤手段來改變?nèi)蝿?wù)間的關(guān)系；將串行的任務(wù)改成并行；改變工作方法（可能 改變WB$

34、;改變?nèi)掌谙拗?，使關(guān)鍵路徑上的任務(wù)開始或結(jié)束的更早。雖然方法多樣化，在我看來只有一條，就是拼命的壓榨程序員的勞動力。如 何壓榨，還是個技巧。如前面所分析的，需求分析恨不得多分點(diǎn)時間給它， 壓需求是不太可能;測試階段后期接近完工，羅里巴唆的事情一大堆，忙都 忙不完，那時候PM一門心思提前/按時完工，好收錢，壓那段時間似乎也不 太可能。說來殘酷，最能壓的還是 CODING編碼階段往往是壓縮重點(diǎn)，總之 大家埋頭苦干就是了，大項目壓縮的時候程序員吃喝拉撒都在公司是很正常 的事情，相信不少人都有很深的體會，這里傷心事情也就不提了。只是我總 結(jié)一下，讓未來的PM們有壓榨后來人的依據(jù)，呵呵。測試前期也可以適

35、當(dāng)?shù)?壓一壓，那時候人剛完工，都比較懶散。國內(nèi)一般企業(yè)規(guī)模都不大，沒有專門的質(zhì)量控制部門，所以質(zhì)量保證和測試往往就是程序員或PM本身。其實(shí)質(zhì)量保證和測試人員的人數(shù)和素質(zhì)都應(yīng)該要高于程序員。在日本和CMK實(shí)施的公司里，編碼壓縮是很容易實(shí)現(xiàn)的事情，因?yàn)槟切┏绦騿T真的是技能熟練的 裝配工人，壓起來方便的很。他們這樣培養(yǎng)人的目的或許就是為了壓縮吧？！四. 控制和執(zhí)行階段1. 軟件開發(fā) ?實(shí)在沒什么好說的，也是大家最不愿意談的，平時在公司里談的 已經(jīng)夠多的了，還要在這里受我嘮叨。需要提醒的依然是團(tuán)隊合作精神和完 善的文檔管理制度。SOURCESA這些工具有時候還是有必要使用的。經(jīng)?？?到有人說天才程序員

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

37、術(shù)討論氛圍，碰到技術(shù)難關(guān)的 時候就容易攻破了。？有個問題需要單獨(dú)對還沒有PM覺悟的程序員說，其實(shí) 是在調(diào)研的時候就定了的，就是使用什么樣的開發(fā)工具。沒有經(jīng)驗(yàn)的程序員往往會拿著C+或者JAVA的資格證書或者擁有一兩個開發(fā)工具的一些經(jīng)驗(yàn)而得意洋洋。其實(shí)老板和PM根本不看重這個，他們關(guān)心的是使用什么樣的工具 能盡快的達(dá)到目的。管你什么 C+ DELPHI PB還是JAVA只要能做的出來， VFP都可以用。我舉這個例子并非說不看中工具，而是提醒想轉(zhuǎn)型為PM的程序員，第一要把工具當(dāng)作工具，而不要被工具套進(jìn)去，鉆研一些一輩子都用 不上的技術(shù)；第二要掌握的并非是單獨(dú)的一個工具，而是流行的程序設(shè)計的 思想，以

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

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

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