成功的專案經理人需要具備的7種軟實力

你想要當PM(Project Manager: 專案經理人) 嗎?

這篇文章用約6000字告訴你PM應該具備的七種軟實力。
時間是發生在西元2012年四月，我開始了科技業PM的生涯，剛開始的六個月是很辛苦的撞牆期，處於專案進度和品質嚴重落後的情況，試著找出原因，提出解決方法。
當時大約每兩個月就會收到PM的離職信或聽到某某PM離職了，我不禁問自己，這就是我要的?
經過五年的歷練，從自己和別人失敗和成功的經驗，發現存活比較久的PM，不是依照PMP書上寫的照本宣科，而是具備數種關鍵的能力，有效運用來管理專案。
底下逐一來說明我觀察整理出來的這七種軟實力(Priority，Root Cause Analysis, Overview, Justification, Extensive Accountability, Conclusion First and Trust)。

• P: Priority ranking⟶了解專案和處理事情的優先順序，抓大放小

如果同時負責好幾個不同客戶的專案，必須知道哪一個專案對於公司的優先順序是最高的，在資源不足和時間有限的狀況，確保工程師是火力集中在最優先的案子。
怎麼樣知道專案的優先順序呢? 透過出貨量的預估(forcast)，量產的時間以及主管關心的程度，可以作為參考的依據。
比如之前負責手機的旗艦機種專案(HTC M9, M10)，目標客戶橫跨歐亞澳美非五大洲，開會慣例都是以北美四大電信商專案(T-Mobile, AT&T, Verizon, Sprint)的進度先報告，拉丁美洲的專案都是放在最後面或是省略不報，原因就是從訂單的出貨量來看，拉丁美洲的出貨量不大，上市時間也晚，要增加能見度和銷售量就還是以北美為主。

如果負責是單一的客戶，也要知道這一個專案在整體的優先順序如何。如果優先順序低，要不到資源是很正常的。建議列出這個專案最需要處理的項目或問題(風險高的部分)，相關資源釋放出來後，優先解決，其餘風險低的部分就和溝通客戶往後延或不處理。
優先順序高，就要確保資源有到位，問題有即時的被處理。

另外在處理專案的大小事時，確定處理的優先順序也是很重要的，
比如下面這些事情發生時，通常是優先要解決的問題。
1. 工廠試產或量產發生問題，造成產線停線
2. 工程團隊沒有足夠的機器做測試與開發
3. 出貨的機器發生異常，產生大量退貨
4. 老闆或客戶決定要更改軟體或硬體某些功能
5. 軟體編譯發生build break 或是軟體更新失敗，燒完後系統遇到極度不穩定的現象(例如不斷重新開機)
6. 硬體生產缺料或硬體有問題

過去執行專案有發生過一個狀況，就是工程師去客戶實驗室做測試，申請的來賓識別證過期，負責實驗室的PM卻沒有及時發現，發現後已經太晚，造成測試無法持續進行。
作為一個稱職的PM，這樣的狀況是要避免的。

• R: Root Cause Analysis (Lesson learned)⟶找出治本之道，自我學習成長

如何避免在專案中重新犯同樣的錯誤? 答案就是要做經驗傳承(Lesson learned)。
如何做好經驗傳承? 就是針對遇到的問題，執行根本原因分析 (Root Cause Analysis)。
比如手機過熱一直是造成消費者退貨的前三大主因，但根本原因是甚麼呢?
是消費者使用不當嗎?
是特定的機器才會發生嗎?
是硬體設計不良嗎?
是在哪一種使用情境下造成的? 充電的狀態下還是更新軟件的時候?
是太多軟體在執行造成系統CPU過載嗎?
是甚麼原因出貨前的測試沒有遇到?
透過這些問題得到的相關資訊，找出根本原因後在現有的產品做出調整。
例如是針對特定耗電的應用程式做限制，犧牲效能避免過熱。
在新的產品則要針對之前沒有考慮過的使用者情境，增加測試範疇(Test coverage)。
設計時要考慮如何layout 和設計有最好的散熱效果。

另外PM要有不斷學習新知的動機與能力，不為自己設限。
比如在系統廠做軟體相關的專案管理，可能也要了解工廠的流程。
做實驗室樣品測試的送樣，也需要知道如何更新軟件和確認軟體版本。
依比例來分，80%專注在你熟悉的部分，花20%去了解你會和相關部門討論會遇到的知識和流程，之後在跨部門開會討論一個議題時，你聽得懂對方說的是甚麼也可以提出讓人信服的建議來主導這個議題。

• O: Overview⟶見樹又見林，總是要有Plan B: 如果原先計畫行不通的備案是甚麼?

有句話說，「Planning is everything. Plans are nothing」計劃本身不算什麼，但訂定計劃卻很重要。
PM 像是作戰的指揮官，要擬定作戰計畫，計畫會因實際的狀況改變，如何迅速的產生新的作戰計畫，就是PM的本事。
比方說工程師 跟你說下周一會完成這件事情，但下周一他跳票了，又再說要花三天的時間，結果又跳票了，這時候就要了解真正的原因是甚麼然後提出替代的方案。
比如說這個RD經驗值不夠，就要通知他的主管看是否找更有經驗的工程師來協助他。
或是工程師根本沒有時間處理這件事情，他只是為了應付你給出一個時間，那就要跟部門主管溝通換別人來處理這件事情。
在專案執行過程，常會發生工程師過分承諾("over-promise")的狀況，PM除了自己要抓buffer，更要對於常常跳票的工程師，要評估目前執行的人選是否夠qualify? 有沒有其他外在因素攔阻?
PM要非常清楚，專案目前的大方向和狀況是甚麼，如果為了一棵樹，而放棄了整座森林，是不行的。
了解最後的底線在哪裡，然後採取不同的方式來解決問題，如果無法如期解決問題，要提前發出警訊，讓主管知道，尋求幫助(call help)。

• J:  Justification⟶提出合理正當的要求，但因應臨時或突如其來的改變

工程師在執行專案時，非常不喜歡被要求一個不在原先計畫的需求，尤其是不合理的要求，資訊又不清不楚。
比如是以下的要求，讓人聽到了或看到信就很火大。

要求(一)「因為老闆說這個張背景圖會讓字看不清楚，所以要改成另外一張，今天下班前要交出來」

要求(二)「原本下周五要demo 的新功能被客戶要求pull in，下周一就要完成，因此周末需要趕工」
要求(三)「工廠現在停線，因為產線恢復原廠設置後，無法正常開機，請馬上到工廠on-site support」

即使最後溝通後或是採取某些手段讓工程師配合，一次兩次之後，很容易造成強烈的反彈。
為什麼要這麼做? 做這件事情的正當性為何?
如果不這麼做，會產生甚麼樣的後果?
無法說服對方，專案就會窒礙難行。

以剛才舉出的要求(一)為例，改一張圖並不困難而且是老闆的要求， 但是你知道工程師正在處理另外一件專案更重要的事情，而且老闆的要求改圖很可能會一改再改。
因此你可以跟老闆說，這裡有好幾張背景圖，可否請老闆決定要套用哪一張或哪幾張看效果，工程師正在處理專案中客人反應三方通話無法成功的問題，因此預計明天提供套用的圖檔。
通常老闆的反應有下面三種:
1. 接受你的建議
2. 勉強接受，但是心理不開心，對你念了一下
3. 不接受，直接找工程師的主管要求馬上改

即使發生第三種結果，你也盡到居間協調的緩衝。
PM甚麼時候該堅持，甚麼時候要妥協，是一種智慧，沒有標準答案。
面對各種怨言或情緒性的攻擊，需要自我調適和保持彈性，接受改變。

• E: Extensive Accountability⟶當責的態度和行為:不是只出一張嘴，只發highlight 信

當責(accountability)是把事情做對，做好，那甚麼是廣泛地當責(Extensive Accountability)?
簡單來說，就是你不只是對單一的利害關係人當責，而是對於多個利害關係人當責。
不只是對老闆交代，回應客戶，也帶領整個團隊。
為整個專案的成敗負責，是當責的具體表現。
不過這邊要說明，當責也不能無限上綱，要知道自己的權責與界限。
在大公司中，因為有太多部門參與在同一個專案，常發生別的部門的疏忽犯錯造成另一個部門的拖累，或是因市場萎縮或客戶不滿意產品，專案被取消，這些並不是執行專案的PM造成的，所以不需要為此感到愧疚自責。
PM能做的是凝聚共識，通知相關的主管與部門，居間協調，大家一起幫忙解決，事後請犯錯的部門做出lesson learned。
如果還沒事先溝通清楚，就發一封highlight信發出來給所有相關部門要大家快點解決，其實很容易產生誤解和防衛的行為。
越是發生緊急和的狀況和重大問題，PM越是要淡定，冷靜沉著的把問題抽絲剝繭，不逃避也不過度反應，掌握專案的節奏，按部就班的處理。

• C: Conclusion First⟶先講結論，再講原因和細節

PM 的工作內容90%以上都是在做溝通，無論是透過口頭報告，電子郵件，電話通知或開會討論，都是溝通的方法之一。
溝通有兩個重點，第一就是要有效率，第二是避免誤解。要如何做到呢? 就是要先講結論，再講原因和細節。

新聞報導是一個很好的例子。比方說報導運動比賽的結果，
下面內容，會在文章一開始就出現的呢?
(1) 6月12日晚上，金州勇士隊以129對120擊敗克里蘭騎士隊


(2) 在7戰4勝制總冠軍賽中以3比1領先的勇士，第5戰首節小幅落後騎士，次節在最多領先17分情況下，反以71比60，在上半場領先11分。易籃再戰，騎士加強防守壓制勇士進攻，單節打出33比27攻勢，讓勇士前3節只以98比93領先；末節騎士一度將落後追到3分差，但勇士拉高防守強度，騎士不斷發生失誤，勇士也持續累積領先分數，最終勇士以129比120擊敗騎士，拿下本季總冠軍。答案是第一個，顯而易見，第二個敘述一直到文章的最後一句話，才知道比賽的結果，想直接知道結果的讀者，在第二個陳述花了不必要的時間閱讀比賽的過程與細節。

對於老闆來說，結論是重點中的重點，
專案中設定的目標完成了多少，預計甚麼時候完成，有甚麼要highlight的，是甚麼原因造成延遲，需要老闆提供甚麼協助，在專案報告中一開始就要說清楚。
下面舉兩個例子:
(1) 專案A 是黃燈狀態，下星期一進入軟體Beta 階段，測試進行了90%，預計這周五完成測試。發現的問題critical issue 有三條，目標是週四build code 前要解決。
(2) 專案B 是紅燈狀態，客戶回報送樣的機器有瑕疵，更新軟體後會不斷重新開機，目前在我們這裡嘗試復現，也同時請客人提供log 做分析，今天下班前會回報最新的除錯進度。

另外值得一提的是，對於不同的專案利害關係人用不同的方式報告專案狀況，同樣一件事情，需要選擇最合適的溝通方式，幫助對方了解。


舉例:
穩定度測試MTBF (Mean Time Between Failure) 的標準是1000 個小時，但現在只達到100個小時。客戶或高階主管對於這些數字是無法解讀出使用上的真正情況。
所以換成下面這一種說法，就會比較容易理解，
目前穩定度的標準是四十天不會出現系統當機，現在測試結果約五天會遇到一次。

大部分的人的習慣還是會先講細節，再講結論，因此PM溝通時一定要確保有得到出結論或是下一步的行動方案，才不會產生無效的溝通。

• T: Trust⟶建立團隊願意互相談承弱點為基礎的信任感 (Vulnerability-Based Trust)

這個是專案成功的最重要的因素，大部分的情況，很少專案團隊可以達到互相坦承弱點的程度，但彼此信任是讓團隊成功運作的必要因素。
我引用Table Group 管理顧問公司的創辦人之一Patrick Lencioni 解釋兩種不同的信任感。
其一是 "Predictive trust"，因為長期合作產生的默契，可以預期對方的行為模式並互相配合。
其二是 "Vulnerability-Based Trust"，是在彼此信任的氛圍下，願意在情感上敞開最真實的一面，互相幫忙。比如
「不好意思，之前的決定是錯的，你是對的」
「這個你要求的，我不是很擅長，我可以找誰一起幫忙?」
「真開心，我們又解決了一個棘手的問題」
「你剛剛的發言讓我感到很受傷」
要做到第一種信任並不困難，但要做到第二種信任就需要勇於去嘗試。

我參與的第一個專案時進度嚴重落後，發現團隊中各做各的，雖然有制定流程，卻成效不彰。答應給客人的軟體，發生了問題，RD 馬上修改了一版，測試工程師又測出別的問題，來來回回就造成交付軟體時間的延遲。
我觀察了三個月也在此期間不斷溝通協調，但並沒有明顯改善。
終於我鼓起勇氣，把團隊成員聚集起來，告訴他們我所看到的狀況，
我跟團隊說這個產品我也才接觸了幾個月，我不是很懂技術的層面，但如果這樣下去，專案會繼續delay 下去，然後我提出了怎樣改善的方法:

RD 要做self-test，確保check-in code 沒有side effect
Code freeze 後不要在隨意進code, 如果發生issue 要一起討論，
如果必須re-build，我負責和客人溝通新的時程或是減少測試的範疇來確保如期release
New feature/function 要先做測試
.......

這只是第一步，改變並非在一夕之間發生，後來又經過不斷的磨合得到了一個好的結果，
在半年後產品測試的pass rate 由60% 提升到95%。

越是龐大的組織，越容易發生資訊不公開透明的情況，PM可能接收到部分的訊息不完整，可能會做出錯誤的判斷或無法做出決定。
PM能做的就是透過相關部門得到最關鍵的資訊，建立一個系統來讓團隊主動回報狀況。
要做到完全或全部的人在工作上做到坦承弱點的信任，是很困難的事情，但值得一試，而第一步就是從PM自己開始做起。

結論:

最後分享我在做第一個專案一個小故事，讓我知道專案的成敗其實是人。

當時客戶要求的一項新功能遲遲沒有完成，開會時工程師總是說下一個軟體版本會完成，
來來回回經過了半年，測試總是一測就不過，
就在即將要release新的軟體時，這個工程師這時突然消失了一個禮拜，電話都無法接通，RD 主管這時才決定把這個功能交給其他人做，兩個星期內就完成了。

半年和兩個星期，差距是五個半月啊!
的確有時候PM必須扮黑臉，要設停損點，當時應該要在跳票兩次以後就要和主管發出警訊了。
用一句話來說明PM的核心工作，就是確保對的人在對的時間做對的事情和把事情做對。
這七種軟實力(Priority，Root Cause Analysis, Overview, Justification, Extensive Flexiblity, Conclusion First and Trust)，讓專案經理人可以使命必達的完成PROJECT 。
想做PM的你，準備好了嗎?