1、項目管理的幾大過程一 . 商務談判 ?1. 作人的姿態 ?作人似乎跟商務談判不太有關系，很多技術人員相信 PM需要的是本事，是如何做好一個項目，而不是會搞好關系弄的四平八穩的人。隨著 PM在中國的悄悄興起， 越來越多的 PM開始在老總的授意下參與商務談判，和銷售們一起打單子，這就比較實在的需要 PM們去揣摩客戶的心理。揣摩客戶心理需要有多方面的知識，需要深度和廣度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿態，對從技術人員轉型的 PM們來說，是至關重要的。 ?降低作人的姿態需要從多個方面去實施，最主要應該記住：人不可貌相，更不可以地位衡量。很多公司為了保持公司形象， 會統一叫員工打扮

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

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

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

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

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

7、是有一定市場的； 而有水平，負責任的客戶往往會覺得這種人不可靠，一般不會把單子交給他。PM需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎的去吹，對從來沒涉及過的領域或者根本不懂的東西輕易不要發表意見，挑選自己熟悉的方向合理的進行發揮，適當的留上一兩手， 給對方高深莫測的感覺，效果最好。4. 優秀的售前團隊 ?這個團隊一般是由總經理發起并組建的，通常不指定 PMP，對團隊的成員如 SALES，PM，SA，ENGINEER們的團隊合作提出了比較高的要求。一般公司在接下一個單子進行到一定程度的時候， PM往往會尷尬的發現協議上銷售代表們對客戶的一些承諾是幾乎做不到或者根本做不到的事情。

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

9、信息傳遞。優秀的售前團隊合作是接單的重要保障。?在商務談判的實際操作中，存在著各式各樣的問題，PM的職責和要求絕非以上幾點所能描述詳盡。根據環境，政策，人文，關系等各方面的不同情況，PM的不同成長經歷，每個PM最終都會建立自己對商務談判的看法和經驗。但是有一點可以肯定，這是PM成為 PM的第一道關，也是最重要的一關。接不到單子，PM將失去存在的意義。與銷售有所不同，PM在該階段的任務除了接單，還要盡可能的搜集客戶關鍵人物的資料并與對方各個階層的負責人建立良好的客戶關系，以便在項目實施時充分調動資源。二. 啟動階段1. 項目的一些基本概念項目三要素有多種版本，各不相同。實際操作中多分為范圍，成本

10、與進度，其中最重要的莫過于范圍。 我們把項目最終生成并提交給用戶的產品和文檔統稱為遞交件。 談判的時候一定要確立遞交件的標準和要求，也就是范圍。 盡管商戰的時候不可避免的客戶會不斷提高標準和要求，而承諾的款項卻不會有一分錢的增加。 但是這個標準對每個公司來說都有一個底線， 一旦超過了這個底線， 那項目就肯定是虧的。除非是為了二期有利可圖或者是為了搞好關系， 否則范圍超過底線的時候情愿不做，再厲害的 PM在這種情況下也是無能為力。建立范圍需要的就是 PM的多年的實戰經驗，在大大小小的項目中用血淚換來的一些體會。在這個時候，很能體現 PM與技術人員的區別。成本就是客戶答應付的款項， 與我們的投入成

11、本并不是一回事情。 進度就不用多描述了。項目如何成功？也有一些關鍵的因素。 個人的理解也不盡相同， 通常包括以下幾個方面：界定工作目標及工作任務；老板或高層的支持；優秀的 PM和開發團隊；充足的資源；良好的溝通；對客戶的積極反應以及適當的監控和反饋。 這里要注意的就是資源和高層的支持。 一個上規模的公司總是同時會有很多項目， 可是再大規模的公司資源也不足以保證每個項目都能組建最合適的開發隊伍或擁有最好的環境。這時候各個團隊或者部門之間不可避免的會發生資源爭奪戰， 摩擦再所難免。這時候對 PM的作人再次提出挑戰。 除了高層對 PM項目的重視程度，如果 PM平時在公司與同事相處的好往往能使很多別人

12、看起來很棘手的問題迎刃而解。相反，一個不會作人的 PM由于人緣差，即使高層強壓別的部門或團隊配合， 別人也會能拖就拖， 延緩項目的進度和質量。有時候，這種內耗對項目和 PM來說是毀滅性的。對客戶的積極反應也比較關鍵。一般來說 PM已經被項目里大大小小的事情搞的筋疲力盡， 要 PM去主動要求客戶配合是很吃力的事情。 然而，這個時候，越是困難，越是覺得累，越是要去主動。客戶往往也不是特別的積極， 主動與客戶聯系溝通和測試能及早發現問題。 從風險控制的角度來說，問題發現的越早，風險越小，損失也就越小。積極的態度可以帶動客戶的積極性， 在項目完工的時候， 客戶對你的感激往往是難以用語言描述的， 這對以

13、后接單或者做二期三期會打下良好的基礎。因為在和別的新客戶談判的時候， 新客戶自然會找你的老客戶了解情況，這時老客戶隨意的一句話頂的上你很費心的十句。項目具有商業行為的幾個重要特征，有消費源，有參與者，有成功關鍵因素，有財務目標，有風險。2. 啟動階段的主要任務根據 PMI的解釋，接單之后項目自然轉入啟動階段。啟動階段 PM的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求， 進一步確立詳細的項目范圍， 預估資源，確立其他方案并獲得進入下一階段的批準。 在這個階段， 隨著需求分析的深入， PM也開始在公司內部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即

14、將進入計劃階段。在收集完數據之后， PM要和客戶開始明確項目的大小，成本，規格，期限等重要特征并將其寫入合同文本， 同時準備內部的包括預算， 衡量標準等文檔，建立項目的評估標準。接下來就是需求分析。由于專業的原因，我們這里僅討論軟件工程項目的需求分析 （以下簡稱需求分析）。 ?需求分析的主要參與人員有 PM，總體架構設計師，系統分析員，熟悉業務流程的客戶。 PM統領的團隊這時候還不是真正的開發團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入， 啟動階段結束的時候正式的團隊將建立。 對一個已經啟動的項目來說， 需求分析直接決定了項目的成功與失敗。 最初的需求體現在客戶的工作說

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

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

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

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

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

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

21、提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加， 以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據。需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花， 經常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。 ? 詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發現難以逾越的技術難關，就會放棄項目。 典型的

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

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

24、雖然在別人看來有些形式主義，但是對提高 PM本人的士氣和責任感是有很大助力的。三. 計劃階段1. 定義結構分工結構圖（ WBS）?啟動階段結束后，項目進入計劃階段，也就正式進入實施。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。 WBS是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構； 把項目分解成易于管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。可以說， WBS是計劃階段的核心。 WBS會詳細的分到遞交件，包括給自己人用的項目使用的過程文件， 給客戶用

25、的模塊和說明文檔， 完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。 WBS有縮進式和樹狀式，我這里也沒辦法畫圖， 大家參考一些項目管理的書籍，里面有詳細介紹。我整個文章只挑我覺得需要注意的地方， 如非必要，對技術細節或者工具使用不做詳細介紹。 WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包， 分包的依據是個人的責任和可信度，也就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深， WBS樹也就越深。由于 WBS是實用性的東西， 根據個人理解也不一樣， 所以一個項目可能會有幾個正確的WBS，看 PM的需要和最適合當前團隊狀態的進

26、行選擇。 ?WBS的定義還是很麻煩的。PM要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，并把 WBS樹分解到二層三層。 然后要花上一段時間讓成員進行頭腦風暴式（ BRAINING?STORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標準。 在頭腦風暴式思考時， 會有很激烈的爭論， PM要協調關系，調節氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準備的越充分，編碼的進度越快。2. 風險管理既然是商業行為， 那么項目的風險必然存在， 相信閱讀這個帖子的朋友不少人都經歷過或大或

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

28、人可以一起參加討論，把提交出來的風險進行分類。首先按發生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。 碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點點，有可能賠的很厲害。 高和中，中和中的搭配都是屬于高風險， 中和低，低和低搭配屬于低，高和低搭配屬于中。針對出現的可能性， 需要采取一些手段降低風險。 到目前為止也沒有一個定論說有絕對好的方式， 只能盡其所能的避免。 有幾種方法可以考慮，第一種是將風險納入項目管

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

30、變更或進入下一階段時也會預估。 預估的作用主要還是讓 PM作到心中有個底，安排計劃時不至于毫無頭緒。4. 進度計劃 ?進度計劃就是一個模塊或功能要寫多長時間， PM安排個日期，設立里程碑，叫程序員們不能偷懶。進度計劃是從 WBS提取過來的。對 PM來說，合理的安排進度計劃對項目控制和激勵團隊士氣有著很大的作用。對程序員來說，進度計劃毫無疑問是噩夢。?顯示進度計劃一般有先后順序圖， 甘特圖和里程碑圖表。 上回邵衛老師講課，推薦的工具是 m$的 PROJECT，這個工具我還不會用，因為沒時間去摸索。我的頭倒是用的很溜了， 近一個月來他就用這個 PROJECT畫了一個又一個的里程碑圖， 不停的折磨我

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

32、級衰落會給項目后期的開發帶來難以估計的影響， 進度將會大大延緩。關于 PM和團隊的問題我們后面會講到，這里我先祥林嫂一把，然后跳過。 ?里程碑圖表的特征是任務，成員和時間，任務和成員用文字標志， 時間用數字描述并輔助以圖線跨度， 象階梯一樣非常形象，一目了然。管理起來非常方便，完了的打個鉤就可以了。網絡邏輯圖是表示任務和邏輯關系的示意圖，可以用先后次序表示，也可以用關鍵路徑表示。其實把各個活動劃分為 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 等，日程計劃也分四種，一般只提到從前向后和從

33、后向前兩種。從前向后的概念就是某項活動必須相同或晚于直接指向這項活動的的所有活動的最早結束時間的最晚時間。有些繞口，我們打個比方： 2 階段指向 3 階段，那么 2 階段里的 4 個子階段也都指向 3。假設 2.1 結束時間為 1 月 12 日， 2.2 結束時間為 1 月 22 日， 2.3 結束時間為 1 月 15 日， 2.4 結束時間為 1 月 20 日，那么， 2 階段中最晚的結束時間是 2.2 的 1 月 22 日，所以在 3 階段中的 3 個子階段 3. 1，3.2 ，3.3 的最早開始時間都不能早于 1 月 22 日。至于從后向前的例子大家自己去推吧， 我就不舉了，剛才幾個 1

34、23 打的我累死了：）?項目經常需要調整進度。 在不改變項目范圍的情況下，調整進度有幾種方法：利用快速跟蹤手段來改變任務間的關系；將串行的任務改成并行；改變工作方法（可能改變WBS）；改變日期限制，使關鍵路徑上的任務開始或結束的更早。雖然方法多樣化， 在我看來只有一條， 就是拼命的壓榨程序員的勞動力。如何壓榨，還是個技巧。如前面所分析的，需求分析恨不得多分點時間給它，壓需求是不太可能；測試階段后期接近完工，羅里巴唆的事情一大堆，忙都忙不完，那時候PM一門心思提前 / 按時完工，好收錢，壓那段時間似乎也不太可能。說來殘酷，最能壓的還是CODING，編碼階段往往是壓縮重點，總之大家埋頭苦干就是了，

35、大項目壓縮的時候程序員吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的體會，這里傷心事情也就不提了。只是我總結一下，讓未來的PM們有壓榨后來人的依據，呵呵。測試前期也可以適當的壓一壓，那時候人剛完工，都比較懶散。國內一般企業規模都不大，沒有專門的質量控制部門，所以質量保證和測試往往就是程序員或 PM本身。其實質量保證和測試人員的人數和素質都應該要高于程序員。 在日本和 CMM實施的公司里， 編碼壓縮是很容易實現的事情， 因為那些程序員真的是技能熟練的裝配工人， 壓起來方便的很。 他們這樣培養人的目的或許就是為了壓縮吧？！四. 控制和執行階段1. 軟件開發 ?實在沒什么好說的，也是大家最不愿

36、意談的，平時在公司里談的已經夠多的了， 還要在這里受我嘮叨。 需要提醒的依然是團隊合作精神和完善的文檔管理制度。 SOURCESAFE這些工具有時候還是有必要使用的。 經常看到有人說天才程序員不寫注釋什么的。 我相信有這種天才程序員，因為我碰到過幾個。我愛人公司里也有一個，他們的一套產品核心代碼就是這個人寫的，4 年過去了，周邊代碼換了好幾茬，核心算法始終沒換過，可惜這小子跟了李洪痔， 如今已經不知所蹤了。 但是他的代碼似乎也要有點注釋的，沒有注釋過段時間再天才的程序員也不能保證他是最有記憶力的。而且，對一個項目的編碼來說，靠一兩個人打天下如今是不可能了。別人的公司都是團隊，兩人智慧勝一人，這

37、頭還在靠一個天才支撐門面，實際上市場可就別人搶了去，那時候再天才也沒用了。編碼的時候講究技術公開，程序員不要藏著掖著，對大家沒好處， P M要想辦法調動大家創新思維的積極性，營造良好的技術討論氛圍，碰到技術難關的時候就容易攻破了。 ?有個問題需要單獨對還沒有 PM 覺悟的程序員說， 其實是在調研的時候就定了的， 就是使用什么樣的開發工具。沒有經驗的程序員往往會拿著 C+或者 JAVA的資格證書或者擁有一兩個開發工具的一些經驗而得意洋洋。其實老板和 PM根本不看重這個，他們關心的是使用什么樣的工具能盡快的達到目的。管你什么 C+，DELPHI，PB還是 JAVA，只要能做的出來， VFP都可以用

38、。我舉這個例子并非說不看中工具，而是提醒想轉型為PM的程序員，第一要把工具當作工具，而不要被工具套進去，鉆研一些一輩子都用不上的技術； 第二要掌握的并非是單獨的一個工具，而是流行的程序設計的思想， 以及在最短時間內掌握一門陌生工具的能力。只有建立了這樣的思維，才有可能轉為PM，否則一輩子都是技術工人，最多就是個技術總監。2. 變更 ?對任何項目，變更無可避免，無從逃避，只能去積極應對，這個應對應該是從需求分析就開始了。 對一個需求分析做的很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟 PM扯皮的幌子就越少。而需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子搞你一下是非常頭疼的事情，

39、往往要付出無謂的犧牲， 有時候甚至非常火大。 ?需求做的好，文檔清晰又有客戶簽字，那么后期客戶提出的變更就超出了合同的范圍， 需要另外收費。這個時候千萬不能手軟，并非要刻意賺取客戶的錢財， 而是不能養成客戶經常變更的習慣， 否則后患無窮，維護的成本會讓 PM吃不消。在客戶提出變更請求時， 要建立變更申請登記表和變更申請表， 并讓客戶簽字。當然，有時候一些不是非常關鍵的模塊 PM也不至于一點不講情面，該賣面子的時候還是要賣，尤其是當著對方領導的面，千萬要賣面子，但是也別賣的太干脆，不要讓他們得到的太容易。?需求做的不好，客戶抓住漏洞或者非常不講道理，麻煩就大了。有時候爭論會很厲害，到非常白熱化的

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