從銷售視角看瀑布式IT專案管理

前言

鄙人是來自IT行業的銷售，4年整合商大客戶銷售一線經驗，1年銷售副總經驗。因整合商身份，我參與過大大小小的專案有數十個，深感專案管理之魅力與價值之大。自學了一些專案管理方面知識、技能，以補充自身短板，朝著成為更高價值的複合型IT人才努力。

在認真研讀了專案經理及產品經理類的一些經典書籍後（大多偏向實踐類），有一些粗淺的體會與心得想要記錄下來，一方面是鞏固、梳理自己的知識體系，另一方面也是藉此投石問路、拋磚引玉，希望能得到看到此文的同行一些精彩見解。

此文鄙人將著重從自身的經驗、見識出發，講述兩個方面內容，分別是：一、瀑布式專案管理的全流程最佳實踐；二、技術以外的問題用商務來解決。

一、專案管理最佳實踐

1。1瀑布式管理常見知識要點

專案管理有5大過程組、9大知識域，共計42個管理過程，基本完全涵蓋了我們專案管理過程的方方面面。

5大過程組按照邏輯順序分別是：啟動、規劃、執行、監控和收尾。其中規劃和執行是相互交織的，規劃邏輯在前，執行邏輯在後。但是執行過程會因為實際情況而不斷地修正規劃，所以它們首尾相連。而監控恰恰就是規劃與執行這兩個過程聯絡、轉化的紐帶。下圖展示了管理過程組的關係：

圖1-1管理過程組關係

9大知識域是由《專案管理知識體系指南》一書中總結，分別是範圍（S）、時間（T）、質量（Q）、成本（C）、溝通（C）、採購（P）、風險（R）、人力資源（H）、整合（I），都是專案經理需要實際掌握的知識點，在專案中會頻繁地遇到。具體如下圖：

圖1-2專案管理的知識域

把5個過程組和9個知識域理解為橫縱座標的話，就會得到一個專案管理過程的框架矩陣，如下表：

圖1-3 管理框架矩陣

這42個過程是前人總結的“招式”，是概念性的說明，可以幫助專案經理和準專案經理歸納總結實踐的經驗，形成知識的體系。

1。2我理解的最佳實踐

站在前人的肩膀上，我們能看得更高、更遠、更清晰。在實際的專案中，尤其複雜的專案，PM往往會手忙腳亂不知千頭萬緒從何開始。即便對照著上表的管理框架矩陣，或許也還是會覺得很難做到貼近實戰指導。自己如果整理一套PM最佳實踐，可以套用在常規IT專案上就可做到胸中有丘壑。讓自己知道從進駐專案組的第一天起就知道

應該做什麼，用什麼工具做，做到什麼程度

才算合格。

我自己對IT專案瀑布式管理過程整理了一份思維導圖，主要參考《IT專案經理成長手記》一書，以及自己全程參與的各類專案經驗總結而來。把42個過程雜糅進5大過程組，依據時間邏輯順序遞進，具體如下：

圖1-4瀑布式專案管理最佳實踐思維導圖

1。2。1啟動過程組

PM的專案管理生命週期從進駐專案組開始算起，即啟動期。

圖1-5啟動過程組思維導圖

這個時間段特指專案剛剛完成合同簽約或即將簽約，專案組進駐的初始階段。這個時候需要PM做的事情主要有4件，都是圍繞著“規矩”進行。無規矩不成方圓，專案啟動階段不要忙著開工，而是先把規矩立下，不然很容易越忙越亂。

好的開始是成功的一半，這4件大事分別是：

管理計劃

、

工作思路

、

啟動會

和

培訓

。

1、管理計劃是把專案組的權責利、資訊傳遞和交付等要求做了規定；

2、工作思路是為下一個階段“規劃”做鋪墊，把專案和產品範圍、工作量、資源配置做一個粗略的評估。另外也要和開發經理或者架構師，商議好開發團隊之後的開發模板、樣例，統一度量衡。還有一個最重要的事就是初期拜訪一下客戶，把相關的客戶領導能見的都見，不論職級大小，一方面是拜山頭，另一方也是提前與相關客戶溝通PM的準備工作是否符合客戶的預期。

3、啟動會就相當於網際網路公司產品流程召開的Kick off，是一個重要的里程碑。啟動會的目的有幾點，包括確定里程碑、提振士氣、明確整個專案的工作方向、方式和方法，再有就是獲得客戶與公司高層領導的表態支援。啟動會的會議紀要就是里程碑的交付物，形成雙方落到紙上的第一份成果。

4、啟動會後馬上開展專案組內的全員培訓，把透過的各項文件材料在組內傳達、學習、落實。

1。2。2規劃過程組

啟動的過程順利完成後，PM馬上開始著手規劃過程組的工作，詳見圖1-6。

圖1-6規劃過程組思維導圖

這個時期重點考慮的是

範圍

、

進度

、

資源

和

預算

。這4項內容的敲定是層層遞進、逐步推導的過程，順序對了則事半功倍。

1、範圍指的是完成《範圍說明書》，並估算工期和理清依賴關係。這3件事湊在一起是有道理的，因為範圍說明書中重點包含了WBS，WBS+依賴關係可得活動清單，而活動清單+工期可得網路圖（後面會用到）。另外，《範圍說明書》並不是單純專案組內自己看的，最重要的價值是拿出來和客戶商議並得到認可，可以單獨做確認，也可以與之後的《需求規格說明書》一起做確認。這個步驟怎麼強調都不過分，許多專案後期失敗都是因為需求範圍界定不明，客戶與專案組之間扯皮延誤了工期、耗費了人力物力反而通不過驗收，兩敗俱傷。

2、明確了範圍後，就可以根據專案總工期要求去製作進度計劃。其中涉及兩張圖：網路圖和甘特圖。網路圖的初稿一定是很容易理想化的，我們需要透過計算來驗證是否合理，透過判斷“關鍵路徑”的TS是否小於0即可得知。一般可透過最佳化依賴關係、預估工期和風險餘量來得到網路圖v2。0版本，接著便可以推匯出進度計劃表（即甘特圖）。

3、有了進度計劃表v1。0（甘特圖），PM就清楚每一項任務在何時開展與結束。對照著甘特圖，PM與架構師、開發經理、測試經理等各小組負責人共同敲定每項任務需要的人手，資源配置表v1。0就呼之欲出了。再進一步，把每個崗位職級分類統計就得到分類資源配置表v1。0。根據分類資源配置表，PM還可以反過來驗證網路圖是否最優，最佳化後可得網路圖v3。0、進度計劃表v2。0、資源配置表v2。0、分類配置表v2。0。

4、最後是明確預算，作為專案實施的基線。根據分類配置表可得人力成本，再加上合同涉及的各項支出可得總成本預算（即成本預算表）。

5、另外補充說明，PM需要時刻把握專案的即時狀態，還需要做好掙值分析（在“監控過程組”需要用到）。掙值分析的資料來源於PV（計劃價值）、AC（實際成本）、EV（掙值價值），AC和EV都可以在進度計劃表敲定後（即至少是v2。0版本），每週的中層計劃、底層計劃報告裡得到真實資料。有了這些資料後，就可以實時生成SPI（進度績效指標）與CPI（成本績效指標）動態監控進度績效與成本績效。

6、中層計劃指的是專案組以周為單位，以小組為執行團體把進度任務分解。最好在每週五下午召開，PM和各個小組負責人必須參與，進行回顧分析並分配新任務。各小組獨立完成周報，彙總至PM處形成整體週報。

7、底層計劃是中層計劃的再細化，在每一個小組內獨立進行，PM不干涉。以天為時間單位，任務責任落實到個人。每個工作日的早上第一件事就是召開晨會（我個人偏向採用敏捷的站立晨會，15分鐘即可），晨會內容在白板上清晰體現、定時更新、簡單明瞭。

1。2。3執行過程組

規劃相當於地圖和作戰計劃，拿著地圖和作戰計劃的PM知道該如何指揮團隊去執行任務。整個執行階段遵照瀑布流程，從

需求（調研）

、

設計

、

開發

、

測試

層層遞進。

圖1-7執行過程組思維導圖

1、需求階段明確的產出物是《需求分析報告》與《需求概要說明書》，前者是後者的輸入，後者是前者的輸出，由PM牽頭團隊集體完成。在一些專案上會省略分析報告，直接編寫說明書。不論是否省略，前期在規劃過程組中編制的《範圍說明書》應該作為組成部分。最後形成的《需求規格說明書》一定要組織正式的需求評審會議，客戶方、我方甚至第三方專家共同出席，正式透過確認後才能進入設計階段。我見過有些專案失敗的原因就在此，要麼是沒有得到客戶確認驗收不透過，要麼是召開得太遲而延誤了大量工期和人力物力。

2、設計階段的里程碑式交付物包括《概要設計說明書》《詳細設計說明書》，主要由開發經理或設計團隊牽頭負責。可以在專案組內部組織評審，但也要足夠重視和正式，把開發的風險降低。

3、開發和測試階段一般都由開發經理、測試經理帶領各自團隊開展，PM這個時候主要關注SPI、CPI的管理和重點難點問題的解決上。細節部分不用置身其中，精力要放在對內協調資源支援開發團隊和測試團隊，對外及時與客戶通氣交流。

4、另外測試部分工作在監控過程組展開說明，PM配合質量經理完成監控。

1。2。4監控過程組

圖1-8監控過程組思維導圖

監控過程組在規劃、執行的過程中始終進行，直到專案驗收透過並移交。監控關注的物件其實就是

風險

、

質量

、

進度

和

成本

。換句話講，其實就是風險在S（範圍）T（時間）Q（質量）C（成本）這4個要素間的擾動。

圖1-9 S-TQC的關係

1。2。4。1風險的監控管理

專案都會存在風險，而且絕對不止一個。所以風險的管理步驟是：

識別

、

分析

、

計劃

和

監控

。

1、首先PM在風險發生前就應當識別風險的種類，提前預判。風險的來源一般有技術、管理、組織和外部。技術風險一般指採用技術難度過高，超出專案組能力。管理風險則是指專案管理原則使用不當，計劃草率或者資源排程不合理等等。組織風險一般指內部對目標沒打成一致，客戶不重視等。外部風險值不可預測的一些政策變化、外部環境變化等等；

2、風險分析分三個維度來看——可能性、影響及時間距離。可能性和影響都是定性地判斷，可以根據中公司或組織的《可能性等級表》《影響等級表》將定性分析轉化為定量等級，對應《風險等級表》得出定量結果。時間距離指的是距離風險發生預計時間，需要每隔一段時間重新判斷一次風險。

3、風險計劃一般有四種辦法——規避、轉移、弱化、接受。通常的做法是PM根據之前分析得到的風險等級，來對應採納這四種辦法。致命風險必須要盡全力規避、轉移，中等以上風險可以弱化，小微風險隨機應變接受即可。

4、風險監控就是監視風險的狀態，檢查風險的計劃是否有效，以及持續監控新風險關注舊風險。

1。2。4。2質量的監控管理

質量的監控一般指質量控制、質量保證兩種途徑，質量控制指的是控制專案的結果按照預期，質量保證指的是確保質量相關活動合乎標準、制度。

所以質量控制就包括

測試

、

缺陷跟蹤

、

配置管理

。這部分的管理需要專人，即質量經理。如果團隊配置不夠健全，也儘量在質量這塊安排專員，因為缺陷跟蹤、配置管理都需要花費大量的精力和時間。PM從旁輔助，配合質量經理。

1、測試是執行過程組的一部分，除了單元測試是交給開發人員來做，其餘的由測試團隊負責。在測試的後期如系統測試、效能測試期間，往往因為臨近驗收所以時間緊任務重，測試、開發人員和客戶甚至會“捉對廝殺”。這樣的看似節省時間，改bug速度快，但很容易自亂陣腳把測試工作搞成一盤散沙。質量經理和PM要盯緊缺陷跟蹤過程，這一步驟儘量不要省略；

圖1-10軟體測試V型圖

2、缺陷跟蹤是貫穿在整個監控過程組的，從缺陷發現開始直到缺陷確定結果（無論是完成更正還是延遲處理都是結果）。缺陷源於發現活動，如各類評審、測試和審計。跟蹤的過程依據《缺陷跟蹤記錄表》，其間涉及專案組多個角色，包括缺陷發現者、協調者、分配者和修改者。最後質量經理要把所有缺陷記錄做整理、分析，已改進缺陷修正的效率、準確度；

3、配置管理是持續性工作，不能簡單理解成專案文件的處理，務必要專人在專門的伺服器用專門的軟體做配置管理。從專案啟動時就有準備工作，執行階段有日常工作，最後到專案收尾階段還有結束工作。最好具體由質量經理來指導專人處理，涉及較多的工具操作。

質量保證則一般包含

評審

、

審計

和

變更控制

。

1、評審在執行階段會發生，需求評審、設計評審都很正式，因為前期越嚴格後期問題就越少。程式碼和TC評審以專人走查的方式進行即可，儘量安排經驗豐富成員；

2、審計多為大型IT公司職能部門組織牽頭，包括對預算、進度以及各項流程進行審計；

3、變更控制要著重強調的是它的原則性，即它的目的是為了讓專案可控，而不是為了阻撓專案變更。有時會在專案上遇到客戶或者我方自己人不理解，變更的過程為什麼這麼複雜或者艱難，那是因為如果變更可以隨意進行的那麼專案會非常容易脫離既定的規劃，導致專案4要素失控。

1。2。3收尾過程組

這一個過程組相對來說比較簡單，但也是建立在前面幾個過程的紮實推進基礎上才行。總體有：試執行、培訓、驗收和移交。ToB的IT專案試執行一般多為3個月居多，期間可以準備好培訓的文件材料並完成對客戶相關人員的培訓工作。驗收一般分為初驗和終驗，初驗通過後試執行，接著沒問題的話終驗。最後是進行移交工作，這個在質量監控時配置管理的工作價值就凸顯出來了。把配置管理的結束工作做好，即可順利完成移交。

二、巧用商務資源

2。1商務資源有哪些

專案管理事無鉅細，PM都要操心，所以有時難免會陷入其中。又因為專案經理很多都是技術出身，習慣了用技術性思維考慮問題。這種思維模式有優勢也有劣勢，優勢就是能夠更清晰地理解技術性難點，給予團隊技術上的關鍵指引。劣勢就是專案管理過程更多的難題其實是在於技術以外，再用技術性思維難免捉襟見肘。

在本文的這一章節中，鄙人將以親身經歷或見聞來分享一下專案經理遇到的難題如果巧用商務資源的話，許多都將迎刃而解。商務在新華字典裡的解釋是：商業上的事務。在我們接觸的專案中一般特指運用企業級、事業部級資源的相關活動，都屬於商務範疇。所以按我理解，當我們說到專案上的商務資源，應該包括這些類別：

銷售資源

、

採購資源

、

事業部資源

、

公司資源

以及

友商資源

。

這種分類方式是我根據實踐總結的，並不一定科學，但實用好記。根據資源的協調者來定義，比如銷售資源就是指公司的銷售經理、KA等能協調的資源。所有這些資源都是透過各種手段，來達到“搞定”專案、“擺平”問題的目的。

2。2技術以外的問題

PM在專案管理的實操過程中，有一些常見的棘手問題：包括需求範圍界定、需求變更、外部風險、組織風險、專案監理。這是我認為大部分To B專案都多多少少會碰到的問題大類，而且往往都會讓專案經理抓耳撓腮、頭疼不已但又一籌莫展。在我以前整合商銷售生涯中，這些問題我都碰到過，接下來一節我對應講講如何用商務資源解決。

2。3四兩撥千斤

2。3。1需求範圍界定

需求範圍界定

常見問題有：

1、專案已經接近尾聲了，客戶提出意見說我們做的不是他們想要的，怎麼辦？

2、PM知道要界定範圍，但是客戶不配合，不是很想參與確定範圍怎麼辦？

3、客戶參與了需求範圍界定，但是我們與客戶意見分歧很大，不肯簽字怎麼辦？

2。3。1。1問題1

第一，專案經理首先要明確客戶為什麼這麼提，

提出的依據是什麼

？如果根據合同、招標檔案、需求規格說明書等都能顯示，我們的專案建設內容不符合要求的話，那麼這個問題就出在自身，請趕快補救。

如果補救起來時間不足，或者遠遠超出成本改怎麼辦？這個時候要請出銷售資源、事業部資源幫忙。一方面讓銷售向客戶說情，寬限時間or降低標準，另一方面向部門領導甚至更高級別領導請罪求更多的資源支援。事後挨板子是免不了的，前期專案管理不到位釀成專案損失，PM要負第一責任。

第二，如果客戶提出的並沒有依據，也應該第一時間向客戶瞭解清楚為什麼有此異議，而不是冷漠拒絕。搞清楚原因，再恰當應對，可以提升PM在客戶心中的地位。

比方說以前我的某個口岸的專案，其中一個使用者單位是遊艇協會，提出了合同要求之外的需求，我們合同之內的反而不是他們需要的。這個時候專案組當然可以簡單地拒絕，因為需求說明書已經寫明瞭。但是PM當時並沒有這麼做，而是瞭解清楚原來問題是出在前期調研不仔細，把需求弄錯了。PM和我提前分析了更改這個需求不會影響驗收的功能項，增加的一點工作量可以承受。

從商務角度我當時建議在驗收時增加這一份使用者體驗報告，所以我們決定給他們更換這個需求，於是我們向業主單位彙報提出了這點並得到認可。最後反而因為我們的這個舉動，在後期驗收時遊艇協會給了相當大的超預期支援。

2。3。1。2問題2

瞭解清楚為什麼客戶不願意配合，或許是因為不想承擔責任，或許是因為PM找錯了客戶對接人，或許是因為客戶不想看到分歧等等。初來乍到的PM很難做到熟悉客戶內部的真實情況，及時向銷售或者瞭解客戶狀況的前輩打聽資訊。有了預判後，再和客戶1對1的瞭解想法，印證真實原因再對症下藥。

我以前經手的某個專案上，PM及團隊都比較不擅長溝通，客戶對接人當時出於某些政治原因，並不過多過問。所以專案的需求範圍界定做得很模糊，專案組東拼西湊做了需求分析，但一直閉門造車沒有申請需求評審，直到半年後才被客戶高層發現與預期嚴重不符被叫停。我當時作為商務被調去救火，公司的相關領導也多次出面溝通，與專案組通力合作重新界定了需求範圍才挽回專案損失。

需求範圍的界定從來都不是PM自己一個人的戰鬥，所以請積極地拉上銷售一起推進，許多模糊需求客戶不肯退讓，但可能會賣客戶經理或者部門領導的面子而放鬆許多。技術上、實施上的大改動，可能只需要商務上的一點小變動就能消除。

2。3。1。3問題3

首先明確一個共識，有分歧並不可怕，所以不要回避分歧。讓客戶直接簽字，都會容易有畏懼心理。PM要收集好客戶情報，最好請銷售一起幫忙找出分歧的原因所在。把大家都認可的部分先敲定下來簽字，剩下分歧嚴重的單獨討論。一般分歧都是來自於合同的模糊地帶，可能是雙方故意留下的，也有可能是單方面設下的，或者大家都沒想到。如果是雙方故意留下的，那麼請銷售資源幫忙解決，會很容易與客戶達成共識。

需求分歧的部分往往對應著不同的客戶干係人，所以比較好的方式是先與客戶私下溝通，大量的溝通會打好基礎。分歧一定要有個結果，就算不能形成共識也要留下努力促成和諧共識的痕跡，客戶也會看在眼中多出一份體諒。

分歧可能是零和遊戲，也有可能是雙贏或者雙輸。這又是仁者見仁智者見智的另一個話題了，此處不展開。

2。3。2需求變更

2。3。2。1問題1

需求變更的常見問題是專案做到一半，客戶突然提出要增加需求，怎麼辦？

我的建議是搞清幾個問題再做決定：什麼樣的需求？為什麼要增加？符不符合我們的利益？用什麼樣的資源能最優解？還是拿例項來說明：

17年時，我的一個專案上客戶提出要臨時增加某批GPS終端裝置的通訊功能，我們作為專案的整合商會增加開發工作量（導致專案超期的巨大工作量）和預算。PM在分析了新增需求的依據後發現這是個繞不開的問題，是設計標裡預留的坑。所以他第一時間找了銷售資源，也就是我來幫忙處理這個棘手問題。根據監控過程組的風險計劃知識我們都知道，既然這個風險沒辦法規避，就只能採用轉移、弱化或者接受的方式。

在這個問題上，我們找出了問題的源頭——GPS裝置供貨商。於是透過

銷售資源、採購資源、事業部資源

共同向友商施加影響，成功地將問題物歸原主轉移了出去。由供貨商負責解決新增的開發，我方採購SIM卡和一年的流量費，最後只用幾千元就成功地解決了一個很大的風險。

2。3。3外部風險

外部風險的常見問題有：

1、介面方不願意提供介面詳細設計文件，只給一些簡陋的需求文件和介面標準，裡面甚至還有描述很多是錯的，怎麼辦？

2、XX出臺了XX新政策和標準，系統要增加新需求怎麼辦？

3、專案早期調研時有疏漏，沒考慮到未來要和XX單位對接。現在要對接，XX單位不配合怎麼辦？

2。3。3。1問題1

我們可以請客戶方出馬幫忙協調，但是切記不要找錯人，並不是每一位客戶都有能力和麵子協調競爭對手的。找準客戶干係人，對介面方施加影響是最簡單的辦法。

當介面方與我們形成競爭關係時，就會自然地牴觸。所以另一種方式是把競爭對手變成合作方，

透過銷售資源、事業部資源或者採購資源

與介面方談判，找合作的切入點，

把1個專案上的衝突轉變成N個專案上的合作

。

2。3。3。2問題2

碰到這樣的政策性新增需求，有幾種方案可以選擇。第一是協調客戶增加預算，把功能補上；第二種把新需求延遲到下一期專案建設，取決於政策要求的上線時間與驗收時間是否符合；第三種是做需求替換，把新需求替換掉老需求，已經建好的部分可能會浪費了。這種犧牲是無奈的，但可以爭取換來一些客戶的資源傾斜。此時拉上銷售，運作得好的話可以為事業部甚至公司帶來一些超預期的資源回報。

2。3。3。3問題3

與新的單位對接介面，一般有兩種解決思路：不花錢與花錢。不花錢的方法需要客戶方支援，幫忙協調新單位介面。

花錢的辦法我舉個真實案例，以前經手的某專案就碰到要和B單位對接介面，客戶方A單位在專案規劃中也沒有預料到，所以對接時相當被動。B單位並不買客戶方A單位的賬，但又必須要對接，否則驗收不了。而B單位又是ZF單位，我們想花錢購買介面都做不到。於是我方動用了許多商務資源，包括事業部領導們也花了大精力協調，找到了B單位的某個服務商C單位，以合作的方式解決了介面對接的問題。（省略其中機密資訊）

2。3。4組織風險

組織風險的常見問題有：客戶單位即將面臨組織調整，客戶開始響應緩慢，專案推進不利怎麼辦？

面對這種客戶組織機構調整的情況，要以不變應萬變。不論上層建築如何更替，專案總是要完成的，尤其政府、事業單位的專案是受到監管的，不能耽誤。所以在組織架構調整完畢之前，PM應當把專案進度推進到下一個里程碑節點前，做好各項彙報材料準備。一旦組織調整完畢，PM先非正式彙報，讓新到任領導心裡有數、增加認可。隨後立刻

協調公司領導、事業部領導做里程碑彙報，一舉突破專案進展的瓶頸。

2。3。5專案監理的常見問題有：

1、專案監理總是找我們問題，一到評審上就挑我們毛病，許多問題都通不過怎麼辦？

2、監理總是和客戶聯合起來給我們施壓，要求我們多做很多東西怎麼辦？

2。3。5。1問題1+2

專案監理的角色是專案的監督者，是平衡的第三方。我見過許多承建單位會對監理帶有抗拒和排斥的心理，這首先是不對的。監理並不是天然地站在承建方對立面，我們可以與他們透過共同利益聯絡在一起。專案的驗收透過就是共同利益，所以評審上挑刺，要麼是確實做得太差，要麼就是沒有提前通氣。

PM可以獨自與監理構建良好的合作關係，搞不定時可以試試銷售資源或者事業部資源。監理如果時常施壓要求做很多東西，PM就要反思一下是不是在關係處理上有不到位的地方，得罪了對方。我曾經見過不少PM與監理勢如水火的關係，其實都是非常不應該的。

2。4橫看成嶺側成峰

2。1-2。3章節我寫的比較多都是實際操作層面的內容（受限於篇幅和時間精力也只能粗略舉例），但專案管理中遇到的問題往往千人千面，單純模仿套路可能效果並不一定最好。在這一節，我分享一些作為一名成績尚可的前大客戶經理的

客戶管理心得

，偏重於道的層面（雖然我本人也還沒完全達到這個層次）

在To B專案中，客戶管理私以為是在專案管理過程中佔據了50%以上甚至更多的重要性。客戶管理是一種技能，就像PM對專案管理42個過程的掌握一樣都是有跡可循的。做好了客戶管理，面對同樣一個問題時PM會感受到

“橫看成嶺側成峰”

的境界。

我發現Top sales與PM對待同一個問題的解決思路有顯著的差異。不得不承認，這種差異很多時候決定了結果的巨大差異。Sales man也會有不好的思維方式，我們取其精華去其糟粕。

一、首先是心態。專案組成員看待客戶往往會有生疏感，對待高級別一些的客戶領導還會有緊張感、距離感。這都是人之常情，但也使得PM天然地不願意與客戶中高層領導接觸。於是乎，我們不難發現很多專案上的通病就是，客戶中高層對專案組的實施進展不瞭解，對成果認可度普遍偏低。人們總是會對自己陌生的事務，天然地牴觸或戒備。

所以PM要做好心理建設，不要只把自己侷限在一個小專案裡，認為自己只能和某科長、某工程師打交道，只和他們平級。要把自己當做anyone，上得廟堂下得草堂。

建立了這種心態後，專案中遇到問題時就不會第一反應是畏難、躲避或者掩蓋問題。很多問題一開始都是小問題，但是專案經理不及時反饋溝通，不喜歡與客戶交流尋求支援或者探討解決方案。PM許多都是一肩挑問題的敢擔當之人，但喜歡閉門造車，問題反而容易越弄越大。

二、接著是日常關係的處理。心態平和了後，我們對待客戶、監理以及友商要像對待朋友般溫暖和自然。不要單純把關係等價成上下級，或者監督與被監督，甲方與乙方。日常關係的處理是必要的，一說到搞關係很多人會排斥和牴觸。

當然我們對PM處理關係的能力要求不會這麼苛刻，但適當的“會來事”還是必要的。休息時間沒事就和客戶聊聊家常，偶爾約客戶干係人喝茶吃飯談談心，節假日及時送上祝福等等。私以為在To B專案中，PM應該把60%以上的時間用在對外聯絡、溝通上，剩下的時間才是與專案組成員協作。但很多專案中，PM甚至會把80%的用在自己團隊內部，我認為是不提倡的。

三、最後是技術以外的知識儲備。我以前在整合商時做KA時，對KA的一個要求是“通才”。在專案實施期間，PM也應該是一個通才。尤其整合商的專案，涉及的資訊系統往往很多樣化，PM會有機會接觸到銷售、售前、合同談判、採購、招聘、團隊建設、售後等等多項事宜。所以PM首先要對自己公司內部的各項流程瞭如指掌，才能在客戶現場有底氣和信心拍胸脯。

其次PM對於身處行業的前沿知識、新聞熱點最好要熟悉，對於客戶單位的行業訊息、政策新聞、績效考核等等也要儲備知識。這既是我們PM與客戶交流的談資，也是對客戶行動的預判，能幫助我們提前規避風險、保障順利交付。

參考文獻

【1】潘東，韓秋泉。IT專案經理成長手記【M】。 北京：機械工業出版社，2013。

【2】王如龍，鄧子云，羅鐵青。IT專案管理——從理論上到實踐【M】。北京：清華大學出版社，2008。

【3】美國專案管理協會。專案管理知識體系指南【M】。第4版。王勇，張斌，譯。 北京：電子工業出版社，2009。

【4】哈羅德·柯茲納。專案管理最佳實踐方法【M】。第2版。宋笛帆，黃詩雨，譯。 北京：電子工業出版社，2011。