項目管理中的「危機公關」

7 人贊了文章

隨著近些年來信息科技和互聯網技術的迅猛發展，越來越多的「危機公關」事件被公之於眾並被廣大民眾所關注。這些「危機」大到國家層面的重大事故處理，也可以小至某某明星的「八卦醜聞」，還有諸如「神鋼」造假、汽車斷軸召回，某某餐飲公司食品衛生等等涵蓋了生活中的方方面面，而如何進行「危機公關」已然成為了一個成功的企業（個人）所必修的課程。在項目管理中，也需要對時時出現的「危機」問題進行「公關」，作為項目經理若處置不當往往會造成團隊在突發情況下產生混亂、延誤解決問題的時機、蔓延問題的影響範圍、造成客戶的不滿甚至導致整個項目的失敗。正所謂不怕有問題，怕的是沒有應對的解決方法。本文旨在針對技術研發類的項目，結合筆者的項目管理經驗，對如何進行項目中的「危機公關」進行探討。

在技術開發類的項目中，遇到的問題大致可分為研發中發生的技術錯誤、供應商物料的品質問題、製造生成過程中的工藝流程、質量管控問題、客戶端發現的使用問題以及產品投入市場後的突髮狀況等。這些危機涵蓋了項目中的各個環節，但處理這些問題都有著共通的思路可循，總體來說可以分為四個方面：

1. 根因分析（Root Cause Analysis）

2. 風險評估（Risk Assessment）

3. 圍堵（緩解）機制（Containment/Mitigation）

4. 糾正措施（Corrective Action）

常見的誤區是遇到問題只關注於1根因分析和4糾正措施，而忽略了其他兩點，這麼做或許能夠得到一定程度的處理方案，但從項目的層面來說其實並沒有把整個問題解決了。作為項目經理除了技術上的措施，還需要關注客戶層面的需求以及產品的成功交付。只有把這4個方面都做到位了，才能稱得上真正度過了危機。下面就這4個方面進行一一介紹：

1. 根因分析（Root Cause Analysis）

根因即根本原因，發生了問題首當其衝就是要找出原因，這是解決問題的第一步。根本原因也是其他所有分析和相關措施的起點，就好比是船舵，只有方向找對了才會達到目標。根因分析的重要性不言而喻，但在實際分析根因的過程中，作為項目經理有以下幾個注意事項：

a) 根因分析只是起點，而不是最終目標

危機公關的目的是解決問題，換句話說就是要有方案。根因的確定只是制定相關方案的基礎，最終客戶和相關干係人所關心的往往不在於根因的細節，而是如何解決問題的細節。

在項目執行過程中，筆者有時會遇到這樣一些供應商，他們在出了質量問題後會相當認真且細緻地分析原因，和你每天開一次會彙報所進行的實驗、測試的進展，報告也寫得相當詳細，能夠把根因梳理歸納到極致。但問其怎麼解決，卻拿不出一份有目標、有時間點、落實到具體負責人的計劃。作為甲方來說，這樣折騰下來，除了了解乙方的技術細節和工作態度之外，對於解決實際問題沒有絲毫的幫助。

同樣在執行自己項目的時候，需要項目經理自身對根因分析有一個正確的定位，並引導項目團隊合理地有限度地進行根因分析。

b) 要把握住大方向

問題往往是突發的，時常需要項目經理能夠在一個極短的時間內給出答覆。有限的時間決定了一時半會不可能遍歷所有可能的根因進行一一排查，只有把握住大方向，從大到小進行分析。

舉個例子，有一款產品在客戶使用時發生故障，需要找出根因。分析時可以遵循如下順序：

i. 客戶操作錯誤or產品自身問題

ii. 若是產品自身問題，那麼是批次缺陷or設計錯誤

iii. 若是設計錯誤，那麼是軟體問題or硬體問題

iv. 若是硬體問題，那麼是用料不當or設計考慮不足

……依此類推

這樣做的好處是每一步有了結論之後都可以說是對客戶有了一定的交代。同時在定位了大方向後，一方面可以讓團隊著手於該範圍內的分析，更重要的另一方面是項目經理可以根據已經劃分出的範圍開始考慮相應的對策，進行風險評估和制定圍堵措施，這些和根因分析可以並行進行。

c) 彙報根因要謹慎

發生突發問題的時候，上至高級領導、客戶，下至團隊成員往往都是處於神經緊繃的狀態，用「風聲鶴唳草木皆兵」來形容也不為過。在這種氛圍中，項目經理切忌發布未經確定或落實的消息，尤其是反反覆覆變來變去的「結論」。否則，會給干係人留下對於項目團隊「不成熟」、「沒有經驗」、「水平不高不專業」 的看法，同時也對解決問題無益。干係人對於根因的迫切知曉的需求是客觀存在的，在多方面的壓力下，項目經理與其發布不確定的結果，還不如實事求是彙報分析的進展、已經掌握的大方向以及接下來具體的分析計劃（要有時間點）。只有項目經理自己穩住了，才能抓住危機處理的主動權。

2. 風險評估（Risk Assessment）

如果說根因分析是項目危機公關的基點，那麼對於風險的評估就是決定事件影響範圍的依據。作為項目經理，不僅要知曉發生問題的根因，還需要清楚地了解其波及的範圍，而只有知道了影響的範圍，才能採取相應的對策。風險評估的結果往往決定了項目、自身企業乃至客戶的政策走向，同樣的問題在不同的風險定義下會有著截然不同甚至完全相反的對策，因此對於風險的評估也是危機公關的一個重要方面，而這點往往被很多項目經理所忽視。

對於技術開發類的項目，有以下幾個要點可循：

a) 定義好風險的嚴重等級

一般來講，問題的嚴重程度從輕到重按如下順序：

尚處於研發階段時發生 < 小規模試生產（NPI）時發生 < 投產時發生 < 客戶端發現 < 客戶投入市場後發生

同樣的問題，越在項目後段發現，意味著其影響越是嚴重，項目經理也必須花更多的時間和精力來處理除了技術解決方案之外的溝通、決策等問題。

b) 定義清楚波及範圍

在項目的執行過程中需要養成記錄變更的良好習慣，實體產品的BOM和相關配置都要有記錄，可以通過序列號（SN）追溯相關信息，軟體也要有版本號（ver）以及對應的發布說明（Release Note）。這樣一旦出了問題就可以清楚地知道哪些批次的產品存在風險，對於已經發貨的產品也能通過查詢記錄來告知客戶影響範圍以便於進一步的決策。

這裡筆者有一個經驗——風險的評估不一定非要等到根因分析完全結束之後才開始。危機的出現是突發的，解決問題速度越快越能避免影響範圍的擴大，也能減少相應的損失。而根因的分析很多時候是需要相當長的時間才能有一個明確的答案，在此情況下只要有了根因大方向的判斷就可以開始風險的評估。

例如，某產品在生產過程中發現有缺陷，經初步分析發現所有缺陷都發生在使用第二供應商的元器件的產品中。那麼在確定「第二供應商」這個大方向後就可以進行風險評估了，若已經向客戶發貨100個該產品，可以通過生產記錄和SN排查得出這100個中有多少使用了第二供應商的元器件從而存在失效風險（如40個），這時就可以告知客戶建議暫時隔離這批次40個產品等待進一步的措施而其餘的60個可以正常使用，並要求產線在根因清楚並有解決方案以前全部切換至第一供應商（圍堵機制）。與此同時項目團隊進行進一步的根因分析再確定第二供應商的問題到底在哪裡，而這40個中又到底有多少個真正有問題。

這樣分步來處理其實也是止損的一個過程，問題既然發生了項目經理就有義務去減少額外的損失，在這個例子中定義好波及範圍至少能保證第一供應商的產品能正常發貨，不至於影響生產，而若等到最終根因完全分析出來在做評估，可能已經停產好幾天了。

c) 向客戶公布風險評估的結果前需得到各方面認可

由於風險評估的結果直接影響客戶的處理政策，其中牽扯到各方的利益，在向客戶公布具體數字前需和相關干係人進行討論並達成統一意見。換句話說，最終風險評估的結果不單單是一個技術上的統計，而要結合方方面面的因素，是一個權衡多方意見的結果，最少也需要得到市場、銷售、售後的首肯並統一口徑。這也是項目經理的一種自我保護的方式。

3. 圍堵（緩解）機制（Containment/Mitigation）

在項目管理的危機公關中，圍堵機制和糾正措施是解決方案的兩個不同的方面，也是「公關」是否成功的最直接呈現。它們的區別在於，糾正措施是最終根除問題的解決方法，而圍堵機制是為了防止影響範圍擴大而採取的行動。

例如在汽車斷軸事件中，召回市面上所有受影響的汽車——這是圍堵機制，而在新的產品中採用新的結構或材料進行改進來消除斷軸的隱患——這是糾正措施。

被很多項目經理所忽略的是，圍堵機制和糾正措施有著同等的重要性，問題越晚被發現圍堵機制的重要性越高，尤其在客戶端發現的問題往往需要投入絕大多數的資源來制定圍堵機制。而和糾正措施不同的是，圍堵機制通常會受到多方面的限制，因為產品一旦出貨後主動權便不在自己的手中。在限制條件下想辦法滿足客戶的需求並防止問題擴散，這相當考驗項目團隊的綜合能力。

筆者曾經接手過一個項目研發一款產品，在該產品正式投產並廣泛投放網路後發現了一個缺陷，此缺陷有一定的風險會導致網路中斷。經過根因分析發現是由於產品中某一元器件短路造成，糾正措施不難，在以後產品中採用絕緣材料並改進電路板焊接工藝即可完全規避短路的風險。但在和客戶的討論中主要的關注點卻在於如何制定圍堵措施——即已經投放網路的產品怎麼處理。客戶的特殊要求是第一不接受退換貨，即無法返修，第二必須有措施保證即便發生問題網路仍舊要保持最低限度運行不能中斷，第三，任何對於該產品的措施（操作）必須是線上進行，即不能斷網。客戶的意圖其實很明顯——不想驚動他的客戶，要保證網路正常運行，不想讓此產品的缺陷演變成斷網事故並暴露出來。最後，項目組花了很多的精力才制定了一個可行的圍堵機制，那些有問題的產品先靠此圍堵機制保證低效率運行，等網路定期維護的時候再進行撤換。

從這個例子筆者得到了兩條寶貴的經驗：

1.圍堵機制往往比糾正措施更複雜更關鍵，

2.有問題一定要儘早發現。

在制定圍堵機制的時候有以下幾點經驗可供參考：

a) 機制的制定不要只關注於己方項目組內部

尤其對於已經量產並發貨的產品（包括軟體），圍堵機制就不單單是一個技術層面的方案，是一個需要結合項目成本、時間以及客戶需求的綜合考量。說白了，就是技術方案必須在成本和時間上行得通，也必須滿足客戶的各種限制條件。

b) 項目經理需要給予相關干係人簡單明確的指示

圍堵機制說到底就是止損措施，也就是搶時間搶金錢。項目經理在危機情況下必須把握住主動權，建立威信，敢於承擔責任。簡單明確、思路清晰的指示是最直接的手段，背後的動機可以回頭再探討，但當下首先要做的不是進行技術上的解釋和討論，而是要採取緊急措施防止危機蔓延、控制影響。

c) 盡量避免採取召回措施（recall）

召回在各行各業都是相當嚴重的事故，不管最後能否解決問題，召回本身的成本很多項目都負擔不起，重則還會影響企業的資金鏈。在和客戶的談判中要有自我保護的意識，也要懂得客戶也不想得罪客戶的客戶的心理，召回是萬不得已的最後一步。

4. 糾正措施（Corrective Action）

糾正措施即是規避問題的方案，和圍堵機制的不同點在於糾正措施著眼於長期的更正計劃，而不是處理當下已經產生的損失。一般來講優先順序和緊急程度沒有圍堵機制那麼高，但嚴格來說圍堵機制只是止損並不解決問題，最終能不能擺平危機還是要看糾正措施，也是「危機公關」的最後一個步驟。

具體如何計劃和實施糾正措施筆者這裡不詳細敘述了，每個行業和企業都有自己的文化和套路，項目中具體越到的問題也千差萬別。這裡還是站在項目經理的角度總結一下幾條經驗：

a) 要學會思路轉換

解決問題並不是說只有消除根因這一條路可走，有時候控制誘因，不讓根因發展成表象的問題也是一個可選的方法。

這裡筆者也舉一個案例，有一款產品有電磁輻射的要求，在做相關測試的時候發現有一些頻率超過標準，需要解決方案。這時有兩條路和選，第一是排查產品所有的電路，找出輻射源，重新設計產品，報廢現有庫存，停止生產直到用新的設計替換；第二條路是設計屏蔽罩，雖然輻射源還在，但可以屏蔽到產品內部不至於泄漏，這樣做不用重新設計，不影響生產，屏蔽罩設計好後加在現有產品內即可。顯而易見筆者團隊最後選了第二種解決方案。

項目都是在有限的時間，有限的資源下進行，項目的目的是交付滿足客戶需求的產品，而非設計一款十全十美毫無瑕疵的藝術品。

b) 糾正措施實施的同時要管控好變更

變更在PMP中是一個重要知識點，在危機公關中也不可忽視。糾正措施的進行必然會帶來產品的變更，無論是硬體還是軟體，都要做好記錄，尤其注意區分好批次。對於生產中的產品，還要注意定義切換時間點（cut-off time）。

c) 要站在項目的角度去解決問題而非純技術角度

技術的方案當然是解決問題的首選，但同時也不要忘了存在其他的途徑。技術上難以解決或許在商務上並不是大問題，商務上的讓步或戰略的調整都可以是「解決」問題的方法。多和相關干係人探討，多去了解客戶的心理，對於項目經理解決問題都會有所啟發和幫助。

以上就是項目管理中「危機公關」的4個方面。除此以外，項目經理在同相關干係人，尤其是和客戶的溝通中要注意措辭以及對待整個危機的態度。出了問題要實事求是，不能一概否定己方的錯誤逃避責任，也不能學日本東電那樣兩手一攤表示無能為力任由事態發展。當然日本企業的「躬」匠精神還是要借鑒的，而項目經理就是那個有義務出來鞠躬道歉安撫人心並安排後事的負責人，要敢於承認錯誤承擔責任，這樣才能凝結團隊把事情擺平了。成功的「危機公關」也會是項目經理展現自己能力的舞台。最後筆者用一個比喻來作為此篇的結語。

項目就像是行駛在大海中的輪船，項目經理就是船長，項目團隊成員是船上的水手而客戶則是船上的遊客。這艘船在途中發現漏水了產生了危機。通過調查發現船底破了個洞導致漏水——這是根因分析；船長和水手們根據經驗和理論計算判斷漏水只波及了某幾個船艙並不會導致整艘船沉沒——這是風險評估；船長下令隔離漏水的船艙，安撫遊客並繼續航行——這是圍堵機制；安全回來後對船身進行維修並加固——這是糾正措施。

也祝大家在各自項目經理的崗位上都能夠揚帆遠航！

作者：黃晉卿

推薦閱讀：