這是一篇舊文，最初是在2007年連載于一個EAM論壇，后來這個論壇整體賣給了erp100，所以文章最后在互聯網可見的位置是在bbs.erp100.com。可惜，在互聯網的浪潮下，傳統的軟件行業日漸式微，erp100也已經關閉了，現在只有在去網站時光機（Wayback Machine）才能找到過去的青蔥歲月了。

12年一輪回，把這個曾經的舊文原封不動的搬運回來，2007年那個時間段我主要做的是能源行業的項目，尤其是電力行業居多，所以文中基本都是以電力行業為項目背景的。由于當時是在論壇連載，所以上下文之間可能會有一些別的帖子中討論的內容的說明，非要想弄明白當時的語境的，可以用 Wayback Machine 搜索原貼 http://bbs.erp100.com/thread-59258-1-1.html 的快照。

懷念下過去的時光，順便審視下12年前的自己對項目管理的認識。

PM成長之路——文中的內容都能做到，你就是好PM！

前言

應浪跡天涯朋友的要求，在本帖中專題進行項目管理過程中有關于與各方協調問題的的討論，希望能對哪些由技術轉型為PM的朋友能有一些幫助。

在說項目協調問題的之前，有必要溫習下有關項目管理的一些基本知識，了解了這些基本的東西，應該有去理解項目協調工作都要做哪些事情。

項目的定義：項目是為完成某一獨特的產品和服務所做的一次性努力。

• 一次性——項目有明確的開始時間和結束時間。當項目目標已經實現，或因項目目標不能實現而項目被終止味著項目的結束。

• 獨特性——項目所創造的產品或服務與已有的相似產品或服務相比較，在有些方面有明顯的差別。項目要完前未曾作過的工作，所以它是獨特的。

項目管理的定義： 項目管理是在項目活動中運用知識、技能、工具和技術，以滿足和超過項目干系的需求和期望。項目管理就是把各種資源應用于項目，以實現項目的目標。

項目管理是一個綜合類的學科，涉及多種知識領域：

• 項目范圍管理
• 項目時間管理
• 項目成本管理
• 項目質量管理
• 項目人力資源管理
• 項目溝通管理
• 項目風險管理
• 項目采購管理
• 項目綜合管理

說明：
上述9個知識領域是《PMBOK Guide-V4版》之前的定義，在《PMBOK Guide-V5版》中最大的變化是從9個知識領域擴展為了10個，新增知識領域是“項目干系人管理”。
事實上，干系人管理相關的過程，在V5版之前是存在于“項目溝通管理”這個知識領域中的。V4到V5版本最重大的變化應該就是從項目溝通管理中拆分出項目干系人管理。一直對“干系人”管理這個工作非常重視，在2007年的原始連載中對于這個問題也有具體的說明，就個人而言，我認為PMBOK的這一做法是非常可取的。
萬一看此文的又正在備考PMP的，另外再啰嗦一句。在最新的V6版中，將“項目干系人管理”修改為了“項目相關方管理”。嗯，這樣寫顯得更高大上了，在具體的提法上，也做了微調，從：“識別”、“規劃”、“管理”、“控制”，調整為：“識別”、“規劃”、“管理”、“監督”。
事實上，項目相關方很多是你PM“控制”不了的，所以改成“監督”似乎是更科學的提法，但是，PM想要做好項目相關方的“監督”也不是那么容易的事情。這是一件非常考驗情商的事情，也是IT類項目執行過程中最難最不可控的一個環節，PMP考試歸PMP考試，真正項目管理實踐中還是要活學活用，千萬不要拘泥于經典，盡信書，等于無書。

項目具有明確的目標，且是一個一次性的活動過程，所以項目經理的任務就是去調度資源利用相應的管理成項目，滿足或者超過項目“干系人”對項目的預期和希望。

那么“項目干系人”就是項目經理在項目過程中始終要去關注的一些人，因為項目最終的成敗，項目的過程人有關系，甚至這些人就能決定一個項目的命運。

還有一點我們必需承認：只要有組織就有政治。哪怕組只要能夠稱為“組織”，那么這個組織中一定存在著政治。所以，項目經理在項目開始階段一定要識別項目能察覺干系人之間的v政治關系以及你執行這個項目的組織內的政治關系。當明確的找出了項目干系人并識的政治關系，那么項目經理就可以在這些人中間根據需要展開協調工作了。

這是項目協調的最重要的部分，也就是用戶協調工作。

我們必需承認在項目實施公司內部由于資源分配等問題，項目經理有必要也必需就這些問題在公司內部展作，這是項目協調中的內部協調工作。

在項目組內部對于任務分配、工作分工等問題，項目經理同樣要進行項目組內部協調工作，有時候，這個甚至比用戶協調工作更棘手、更難以操作。

項目啟動

在項目開始階段，一般我們都用過一次會議來明確項目的計劃等等東西。在這個會議中，同樣會成立一個“項目管理委員會”之類的臨時機構，這個機構的人員一般由雙方項目經理、高層領導等人員組成，主要目地就是有人能夠在項目出現關鍵問題的時候能夠商議和決策。不過話說回來，這個委員會一般都是虛無縹緲的，基本就是一個空架子，很少有項目真的靠這個機構來管理問題（雙方高層領導如果整天陷入項目中事務性的工作，這個項目恐怕也懸了。），基本還是靠雙方PM來協調，或者出現具體問題找分管領導協商解決。

不管怎樣，這個“委員會”之類的組織中的用戶，顯然都是這個項目的“干系人”，不是干系人我想他不會答應去委員會。那么這是PM們識別出來的第一批“干系人”。還有誰是“干系人”呢？一般來說，主任級別的用戶都是我忽略的，尤其是檢修、運行、經營、物資這幾個部門的一把手（不好意思，只能用電力做例子了。）

下面說下有關政治的問題。我們不能指望一個企業一團和氣，企業內部存在2個以上的“陣營”是司空見慣的。一企業內部分管你這個項目的領導都是一個副廠或者總工之類的領導。不管是誰管這個項目，作為PM你還是首先想清楚這個企業高層之間微妙的關系比較好。知道關你這個項目的領導，在那個陣營有哪些對手、和哪些人關系好哪些中層“是他的人”，這在PM日后進行項目運作和項目協調是很關鍵的。

作為廠級領導，即使看起來分管的是經營、生產或者是總工甚至是管后勤、三產的，并沒有進入“委員會”，作為最好把他們都列入“干系人”來管理比較好。

來，回頭總結下。
首先找到干系人，簡單的說對于電力項目來說，從廠長開始的廠級領導到關鍵部門的一把手，再加上用戶PM，是項目干系人。

第二步，快速弄清楚企業的政治環境。這事情說起來容易，真要弄清楚還真不好辦。因為這本來就是敏感的事愿意給你說清楚啊。我曾經在項目開始的時候去問這些問題，人家的回答：我們廠的事情，給你說三天三夜你清楚。

這里給大家說幾個技巧：

1、和用戶PM快速搞好關系。項目剛開始，大家沒有沖突只有美好的愿景，PM之間搞好關系這個是比較容易的關系好了，通過他的嘴慢慢了解一些信息。

2、在與中層聊天時可以拿同樣的問題都問一遍，從他們的答案中去找到暗示。

3、給高層匯報工作的時候，可以問“這事請要不要再給×總（×廠長）匯報下？”聽聽對方口氣。

4、問問項目的銷售經理，中標是找的誰幫忙的。這些人不用說將來都是可以幫助你的人。再問問他，投標對手都是誰。這些人不用說，你就時刻小心他們給你坑吧。

關于客戶協調的第一步，弄清對象、理清關系就說這么多吧。

項目開工

隨著項目的開工，PM會很快弄清楚項目干系人都是誰，企業的政治情況也大致了解了。那么首先要做的三個重要工作就是：

• 項目計劃的協調
• 需求調研的安排
• 基礎數據的采集

項目經理的項目協調工作從此就開始了。這個時候的協調工作還是比較簡單的，（原因明顯：沒有矛盾嘛）主要是道理的說服工作。說服用戶配合你的基礎數據采集這是一個大事，也是重要的事情。這個時候把道理、需求、日后用效果說清楚了，讓用戶有了對這工作的認識和不太大的期望（期望太高就要出事了！），可能會配合的好一點。PM最好能夠說服用戶成立臨時的脫產的數據采集小組（但是對于目前的新建電廠的人力情況看，這個基本沒指望，于老廠完全可以這么要求，至少要辦脫產。），這樣才能保證效率和數據的可用性。

對于需求調研，想對顧問們說句話：任何一個流程不要只聽一個負責任的描述和解釋，否則你就會面臨日后需求調可能性。舉個例子，對于物資流程，不能只聽負責物資的采購或者經營部門的領導和具體辦事人的需求，更要聽儲、檢修甚至總工、生產廠長、經營廠長的想法和要求。對于信息化這個工作，每個人的出發點、認識、目地都是的，做為顧問一個事情多問問多看看只有好處。

為了日后工作開展起來方便順利，建議PM利用需求調研的時間充分的和企業各個層面進行業務交流和個人交流（從解目前國內幾個EAM實施公司的情況看，PM貌似都沒有這么多時間做這個事情，但是，我仍然建議PM們花時間下去們認為“沒什么可以交流的”這些用戶們多吹吹牛。）。一方面可以協助顧問進行需求調研，一方面混個眼熟、套情，日后有事情了，起碼人家知道你是做什么的，叫什么。我做一個項目的時候，曾經用了一個月時間，每天杯子好茶葉，裝2包煙就四處游蕩去了。和我認為必要的人：干系人、關鍵用戶等去聊天，吹牛。對于需求不明確的地帶著顧問去，幫顧問問清楚了，我繼續吹牛。這些時間的浪費，保證了我在項目后期可以去直接協調用戶之間的問用戶PM協調不開的事情，我去游說一番都能搞定。回頭看看那時候抽的煙、浪費的時間是不是都賺回來了？

這就是我要說的客戶協調的第一方面：廣泛打交道，混個臉熟。在混臉熟的過程，這些人的脾氣、愛好、說話做事PM們應該都能摸透了。那么以后遇到事情去協調，改怎么說話、說什么話不就心中有數了？

當然了，這樣的泛泛之交不能解決所有問題，對于客戶協調的第二方面就是關注重點用戶。具體的做法還是多交流是對于這些人來說，不就是混眼熟這么低要求了。對于他們PM最重要的是撲捉到他們對于這個項目的真實看法。（一點不荒唐，表明支持，實際上不希望項目成功的人大有人在。）這些出于用戶內心的對于項目的觀點、看法，是P日后決定項目走向、在關鍵問題上做出判斷的重要依據。

我曾經就遇到這樣的事情：用戶直接建議我說，D經理，你還是做做領導的工作把項目驗收了算了。上面曾經要求上過一套系統，我們就隨便找了一家做了個程序，等上面來檢查，就開機讓看看畫面，里面連數據都沒有。我們不軟件，現在就挺好。就這樣的用戶心態，能配合你做好項目？可怕不。當然了，我還是可以再吹一個牛，上周和這目的用戶PM聊天的時候還提到這個部門，他說沒想到當年那么不配合的部門，現在用系統用的最好。我說我也沒想但是，用戶PM不知道我在他不知道的情況下做了多少工作。（當然，由于他們的存在，項目進度那是不樂觀的。）

有的放矢，總是不會錯的。

客戶協調的第三個層面就是和企業高層打交道了。這可能也是PM們最不知道怎么辦的事情。

和別的干系人打交道可時間戰術、人海戰術，慢慢耗，耗也能耗出結果來。但是，領導們絕對沒有時間陪你天天吹牛。和領導們的交流，是按“有事啟奏、無事退朝”的原則來辦。有事，不是說是點事情就要去他哪里問清楚，找領導就是要批量一次性解題。所以，見領導前提前充分準備是很必要的：準備文檔（文檔要簡潔、重點突出，不要太厚），準備時間（領忙，不要你好不容易進門了，人家3分鐘后有會，給你來一句：你放這吧，我回頭看看給你答復。），準備怎么（說話要講究藝術，和領導溝通尤其如此。我覺得……、我建議……、廠里最好要求……最后結果都可能不一樣的。）

再分享點心得吧。

• 見廠級領導，首先和廠辦主任（總經理工作部之類了）搞好關系，去他哪里打聽領導們的動向，讓他幫你預約下（要是預約了就要守時）。

• 提前準備好文檔，最好按照你能預估的結果來寫東西，談攏了讓領導直發……這多爽啊。根據要談的內容，考慮好先后順序，很多時候前面的事情沒有談攏，后面的事情就不要提了，提了也沒用。

• 順序弄明白了之后就開始擺沙盤吧，在腦袋里面設想你怎么提問題、要求，人家可能給你的答復，你再怎么討價……我堅信，沒有談判天才，只有有準備的談判天才。

好了，到現在，和三類用戶怎么打交道我們都明白了。下面就是遇到具體問題的具體協調手法了。

這里要插一句，PM們不要指望有事情了再去找誰誰誰溝通、協調，這基本都是很困難的。反正一個項目周期也不短也沒法預計以后要找誰，不如先浪費點時間下去。

項目日常管理

前面已經說清楚了PM進行客戶協調的最重要的東西，就是在問題發生之前和用戶多交流、多溝通。人與人之間有了一定的情感基礎，談起棘手的問題來能好一點。

隨著項目的深入展開，PM們面對的最多的問題大致有以下幾種：

• 進度計劃得不到執行，項目開始延期；
• 用戶理由很多，總是不配合工作；
• 需求變更；
• 資源不足，人手不夠；
• 長期出差，項目組成員開始煩躁；
• 用戶PM由于項目的種種問題，開始郁悶，將邪火發到項目組成員身上；
• PM身兼數職，無法全心進行項目管理，項目組成員開始各自為陣；

面對這些問題，PM們改怎么辦呢？一個問題一問題處理吧，還能怎么辦？

1、項目開始延期，這問題太普遍，普遍的大家都覺得正常。但是做為PM還是要分析，導致項目計劃延期的原因，在你的項目月報中要說清楚你的項目為什么延期吧？上面總結的2、3、4基本上都是項目延期的普遍原因。對于項劃延期問題，建議PM們和用戶PM做好溝通工作，屬于用戶方的問題要給他說清楚，必要的可以形成書面的東西給他。

2、這個問題最頭疼。人家每個人都貌似很忙，沒空配合你的事情，你怎么辦啊？常規方案，針對問題開項目協調通過會議解決這個問題。當然了，開會之前PM們需要做哪些事情，我在上一個帖子中對于開會有專門的說明，這里羅嗦。如果前期的吹牛工作做的比較好，那么這時候用戶PM通過官方手段無法協調的事情，你可以去試試看直接和用戶溝通下，說不定你就說服人家配合你了。第三個辦法，直接找廠領導，擺事實講道理，讓他來協調（找的領導要是“自己人”，找錯人了不要怪我出餿注意。）

3、需求變更，痛苦的事情。在這個帖子開頭的時候提過需求調研的過程中建議大家一個問題多問幾個人，就是為止大面積的需求變更。真的事情來了，也不要罵娘了，罵了也不能讓用戶不改啊。需求變更問題，是個很大的話題不好說清楚具體怎么操作，才能解決問題。說說我對于這個問題的幾個觀點吧。

A、面對需求變更，不要在第一時間發表任何看法。先把問題聽清楚，然后“站在用戶的角度去考慮為什么用戶要這求”。

B、從用戶角度考慮清楚為什么這么要求了，再回頭看看原來的需求是怎么提的，偏差在哪里，是需要配工作流還要客戶化程序還是技術上實現困難或者干脆就是不能實現。

C、有一個觀點大家可以試著理解（純粹個人觀點，不同意要么扔磚頭要么笑笑算了）：管理都是有出發點、管理段以及管理的目地的。其實每個業務流程就是為了實現管理目地的一種管理手段，那么對于需要變更的需求，我們從管理的本質上來分析問題。如果說現有的東西和管理的目地不沖突只是在手段上有差異，那么我們可以和用戶商個差異是否可以換第三種方案來實現，這樣用戶的需求能滿足，我的程序修改內容最少。

需要說明的是，這樣的處理方法一般都是在處理需要程序規模性的修改的時候采用的（咱當年是做國產自主開發產施的，這樣的事情太多，于是就自己找了一個處理這個矛盾的套路。），而且，如果決定和用戶去這樣研究問題，一定要保證你首先是一個合格的顧問——你要把用戶的需求、業務本質都吃透了，才能和用戶去研究變通的方案。

D、如果你站在用戶的角度分析了，得出的結論是修改，那么就去改吧；如果仍然覺得不需要修改，那么現在可以去商量這個問題了。記住，你分析改不改的理由千萬不要是：工作量、技術問題、人手不夠、以后再說……一定要站戶立場去分析問題，最后讓他自己得出你要的結論，這是最理想的結果。

4、內部協調的問題終于出現了，目前電力市場火爆EAM同樣火爆，基本每個公司都面臨人少項目多的問題，那么進行資源（人力資源）的爭奪不可避免。做為PM向上級領導爭取資源的時候，我的建議是：分析事實、計劃、進度標以及你爭取的資源完對成這個計劃實現你的目標的影響。

5、PM做為公司指定的“項目的總經理”以外，更是項目組的老大哥。在做好項目的同時，更要關心關心手下的兄弟我的觀點是，做為PM不是技術牛比就是顧問牛比，在項目組收入也應該是在前面的，那么就大方點，公司不報銷就請客吧（或者AA），沒事大家出去活動活動，放松下心情。做項目遠離家人、朋友而且天天加班很辛苦，如果PM法讓大家快樂起來，也是一件麻煩的事情。

6、用戶PM在項目的某個階段發邪火，PM們都遇到過吧。這個問題就一句話：有什么事情你給我說就好了，項目組弟們很辛苦了，再錯都不要再罵他們，有火對我來。

7、這是技術當家的PM最容易遇到的問題，隨著項目的深入，任務分配下去就開始各忙各的，做為PM也不過多去過最后問題發生了就遲了（想起來雪上情人的一個關于項目組人員辭職的問題，關于這個問題，他的失職再怎么說也分。）。不能說告誡，只能說建議各位技術出事并且同時在項目中做技術活的PM們，至少每天回宿舍要抽時時間和每個人溝通下，如果形成每日的宿舍項目例會那是更好不過了。

項目管理策略

前面說到了PM在項目過程中會遇到的協調的問題，以及簡單的處理方法。當然了，做為PM誰也不希望項目中天天都是需要協調的事情，都希望項目在一個正常的軌道上穩步前進。那么如何給項目一個正常的軌道呢？

可以考慮在項目開始階段做下面這些事情：

A、對于項目進度計劃的三級管理

三級管理是這樣一個模式：長期里程碑、重點工作計劃＋中期工作內容計劃＋短期具體操作計劃。

這樣的計劃是一一級的解釋與細化，這樣就可以將一個漫長的項目過程通過合理的切割與組織，變成可以操作與控制的過程。通過計劃的滾動編排，可以很容易發現項目存在的重點問題與急需解決影響進度的問題。

通過這樣一個由粗到細，再由細反饋到粗的項目計劃管理過程，做為項目高層管理者可以很輕松的得到有關項目進真實情況和存在問題。

對于三級計劃的周期個人建議：項目整體、月、周。

B、項目報告與項目例會制度

EAM項目周期不算太短的，那么PM們不要指望靠腦袋將項目中所有的事情都記在腦袋里面。通過階段的做為項目小方發布的文件，將項目中的進度、成果和問題進行記錄、發布是很重要的。

做為PM最重要的一個能力就是去“釋放”問題，否則，所有問題都壓在你身上，你再牛×你也會被壓垮。那么，在項始階段就和用戶明確項目例會制度吧，有事情在會議中說清楚。

建議：在正常情況下實施方項目組每周都有內部報告，發布對象就是雙方項目組。整個項目官方的報告每月一個，特殊時期（上線過程，需求過程等）可以每周一個官方的報告。

例會可以跟著報告走。但是為了配合順利，最好一周一次小規模的雙方項目組例會，每月的例會需要邀請雙方高層管理者（項目管理小組的領導）參加（現實的問題就是實施方的高層管理者會每月參加嗎？）。

C、需求管理策略

誰也不希望需求變化，更不希望同樣的一件事情，三個用戶給了你三個“必需按我的要求來修改”的需求。對于這種左他往右的需求，可能是PM和顧問們最頭疼的事情。很可能就是今天改過去明天該回來。

當項目確定了項目《需求報告》或者《項目解決方案》后，雙方項目經理可以坐下來明確一個可控、可追溯的需求方案，保證所有的需求變更都是“有人承擔責任的”。

沒有規矩不成方圓，在項目開始階段明確了計劃管理、工作管理和需求管理的方法，我想PM后期需要去協調的工作很多的。

項目驗收

前面說了項目開始要注意的東西，協調過程中的一些事情，以及如何給項目一個合理、有效的軌道讓用戶能夠配合實施方PM的工作，讓項目在友好和合作的氛圍中前進。隨著時間的推移和實施的深入，項目自然會到了需要準備驗收的時候。

今天就說說有關項目驗收的問題吧。

項目何時驗收、如何驗收這可能是PM們被直接領導、老板們問的最多的問題，也是很多PM們很頭疼的問題：用戶平時配合的挺好，怎么一說準備驗收了，什么都不好了，什么都要等等再說了……借口多的很，就是不配合你驗收。諸如此類的事情，在項目驗收過程都可能遇到。不驗收用戶不給錢，公司催死PM；要驗收用戶提了一堆問題，PM難死公司……面對驗收工作，PM們該如何展開操作呢？

從個人一貫對于項目驗收的理解來看，PM去操作項目驗收工作是沒有什么標準方法的。雖然項目驗收的標準程序很多，很多地方都能看到：各類驗收步驟、各類功能驗證、各類文檔、各類測試報告、各類手冊、功能清單……別的地方都能看到的東西，所以這些不是我想說的。有標準的東西都是可循的、可以量化的，這些東西只要花點時間下去，都能準備完成。真正帶給我們項目驗收的壓力的東西是那些非量化的東西：這個那個功能不符合要求、使用不方便；承諾的某某功能沒有實現；與合同、投標文件對比還有×××功能沒有實現（這些功能很可能是售前、銷售為了拿單子不管死活的寫上去的。）；系統才上線×個月問題還沒有暴露，再等×個月驗收也不遲……這些東西PM們該如何應對呢？

在繼續開始之前，要說明一個問題。

關于項目，我們可以去追求完美，但是考慮到給我們發工資的老板的心情，所以，在研究收這個問題的時候，讓我們先把做個完美的項目這個念頭扔到別的地方，重點去關心如何項目在大家都能接受的底線之上去驗收。

事實上，項目驗收應該從PM接到項目的第一天，從看招標文件、投標文件、技術協議那始準備。道理很簡單：PM之后做的所有工作就是要完成這個項目，所以從這天開始PM就目驗收而準備。

看招標文件、投標文件、技術協議不是去弄明白要做什么事情，而是要“清楚的知道那些求的東西、公司承諾的東西、合同里寫清楚的東西，在事實上是無法實現或者在成本分析這些東西是不劃算的”。這些東西PM要明確的把他們從這三份合同相關的文件中識別出來去和銷售經理、售前顧問聊聊，看看這些東西都是怎么跑到合同或者標書里面去的，那些去考慮回避的，那些是用戶很關心，需要去考慮實現的。

行了，弄清楚這些事情之后，組織好你的小組成員和顧問，把這些東西說清楚，考慮好需求調研的時候對這些問題采用何種方式去調研之后，可以著手準備項目啟動會（第一次設計聯絡會）了。

其實，做項目的過程，就是去將那三個文件（再羅嗦一次：招標文件、投標文件、技術協逐漸衰的過程，當PM所擔心的問題都“合理”的衰減了（合理是很重要的，有時候老板們一些“粗魯”的方解決問題，表面看暫時解決問題，事實上后遺癥很厲害。），那么項目以驗收了。但愿這個表述大家能理解。

PM如果能抓清楚影響項目未來發展和驗收的主要問題，那么就需要在前面講的協調、溝通（就是我說的吹牛過程，鑒于大家的理解有誤，我改正為協調、溝通）中一點一點去把握用這些問題的心態和想法，然后加以誘導和說服。感覺條件具備的時候去選擇一個合理的方式這些心中的石頭釋放掉。

有那些合理的方式呢？

會議顯然是首選了。需要考慮清楚的就是會議的主題是什么，不要傻傻的去開有關功能、需更為主題的會哦，這會嚇到用戶的。關于開會的問題前面也說了很多，就不多說了。需要注就是選好主題，然后把你想實現的事情合理的安排進去，并討論通過。

第二選擇就是個別溝通了。每個功能點總有核心用戶部門的，那么就去和這些部門的領導通、協調吧。

還有第三種好辦法嗎？

那就是希望用戶不要提這些問題了。但是誰能保證他現在不提，你準收的時候不提呢？裝傻，不是好辦法。還是主動去排雷比較好，免的炸的時候你很慘。

把那些麻煩的需求都合理的處理了，那么面對驗收我們還要做什么？

分步驗收，分模塊驗收是個比較好的策略。

古話說一口吃不成胖子嘛，那就慢慢吃吧。分步模塊驗收從用戶心理來說壓力相對較小，就是一個模塊，驗收了你也跑不了，給你簽字的可很大。當然了，事情都是兩面的。分模塊驗收是容易，那么需要考慮以下問題：

a、模塊驗收了，用戶來新的需求，做還是不做？

b、模塊驗收的功能顯然不會是三個文件規定的全部東西，如何保證在總體驗收的時候用戶你回頭算舊帳？

說個一家之言：做電力項目，只要錢沒拿到手之前，所有的簽字都是假的，千萬不要以為簽就萬事大吉了。曾經有PM向我說：怎么能這樣，原來都簽字了，現在怎么又變了，怎么簽都不算？我說：你怎么辦？去他辦公室哭能解決問題不？

c、簽字驗收的人，對于項目的最終驗收是否具備絕對的發言權？人家弄個副主任給你簽模收，等最后發飆的時候主任去，一句：模塊驗收的事情我不知道，我今天提的問題你們必到，要不我不簽字驗收，誰要驗收誰去簽字。能氣的你想把你的IBM扔過去。

不管怎樣，事情做的差不多了，項目也超期了，總是要驗收的。

上面那個兄弟說了，提前吹風是很重要的。這小風慢慢的吹，一個人一個人的吹，爭取在吹時候把問題都提前了解清楚，然后找合理的理由去說服吧。

現在能不能驗收了？估計還是比較懸吧？總有不好擺平的用戶的，跟你叫上勁了也不是什么的事情。那么就上下活動，團結可以團結的力量，判斷清楚問題和形勢后開個驗收預備會吧。

下面舉一個我實戰的例子。

你不給我驗收，那么我要求開個預備會“誠懇”并且“認真”的聽用戶的意見和問題，并給出解決問題的時間表，在這個時間表內，誰不配合、誰不能完成任務都要有相應的處理辦法。經利用中午吃飯的時間和電廠一把手聊天，除了沒說項目的事情，聊了很多話題，還記得有用數學是什么專業，能做什么；拉普拉斯方程；電網潮流計算；電廠主輔分離好不好；他們有沒有必要成立檢修公司……。一直聊到下午上班，然后跟到辦公室跟他談預備會的事情，要了他一句話：開會的時候我肯定最后發言，你說什么我強調什么，怎樣？
開會的時候，廠長還多說了一句話：“人家D經理在這邊很久了，也很辛苦，我認為他們的工作很有成績，今天人家也拿出最后的驗收計劃了，態度非常好。今天我還要說的就是，那個部門不配合××公司技術人員，導致計劃不能完成，到了時間你們那個主任不簽字，我來簽字驗收，驗收完了我再找你算帳。”聽了這話，心里那個爽啊。當天沒有加班，晚上喊小組兄弟們出去喝酒。

個人認為，預備會是個比較好的處理方法。行了，預備會也開了，問題都說清楚了，能不能了？

答案是還有可能出什么鬼問題導致用戶提出來不驗收，對于老PM，遇到這樣的問題不奇怪怎么辦呢？相信通過前期的溝通什么的，PM對用戶的心里底線應該都能把握了，而且前面做了這么多工作了。就差最后一點了，不解決不急死人啊？

備忘吧！我都做了這么多事情了，最后這一點你還擔心我不做？但是，說好的要驗收啊！總我給公司一個交代啊？而且，沒按時驗收，你（用戶PM）這不也算沒完成工作啊？要不咱一步，你給我驗收了，我驗收報告后面給你附個備忘錄，我答應你做的都寫里面去。

事情做到這份了，PM們項目驗收了沒有？

總結

通過一個項目從頭到尾整個過程的簡單解釋，希望新的PM及技術轉型的PM們能夠從中間得到點自己需要的東西。也算我沒有白花這么多時間去打字。

寫了不少，回頭再來提煉下：

• 項目開始階段，分析清楚合同相關文件很重要，從中間發現以后需要注意的“特殊”功能要求；
• 在項目開始階段和用戶明確項目的管理體系：報告、例會、需求變更等；
• 排一個比你覺得能實現的計劃周期壓縮20％的總體計劃；
• 根據自己的能力和優勢選擇一個理想的介入項目的方法：或者高調（這個不是太好玩）、或真、或者技術很好、或者理解行業需求……
• 開始階段，多和用戶溝通，不一定要有問題才去找用戶，電廠的主管們大多時間還是教多的接觸接觸是好事；
• 剛開始的項目報告一定要言之有物，能客觀反應問題（是用戶的就指出來，是自己的錯誤也寫上去），讓用戶領導覺得可以通過這樣的形式了解項目情況，并愿意參加例會；
• 滾動計劃一定要準確，不要滾來滾去，事情總完成不了，會導致用戶對于你計劃能力和做事的懷疑；
• 排雷工作早點做，不要等驗收前3個月才想起來；
• PM就是PM，不要再去做技術高手，對小組兄弟多些指導，少做點具體事情，多花點時間去項目整體的事情；
• 對于驗收，不要一根筋的去考慮，做多種方案準備，然后考慮清楚后再和用戶去談；
• 最后，關心項目組兄弟們的生活，人性化點。