背景案例

在剛剛結束的專案中，從開始到釋出上線，全程伴隨著多個高風險，每個模組的技術方案，都涉及到多個團隊的溝通協調。在專案管理成本極高的情況下，如何推進並完成專案的如期上線，成為一個棘手的問題。

本文不再累述專案管理各階段任務和經典管理方法，更多地是從成本管理與協調溝通的角度，總結一些軟技能的落地方法。

deadline反推里程碑

在資源充足的情況下，我們看一下deadline與專案釋出風險的關係：

專案時間越短，釋出風險越高；但專案時間拉的很長，釋出風險也同樣極高，因為在這個過程中，業務的變化、需求的變化、相關係統的改造與升級、大促的風險都會接踵而至。

在deadline確認之後，PM需要根據需求內容，反推專案的核心裡程碑，確認每個核心里程碑的deadline。無奈的是，越是緊急的需求，里程碑的設定越沒有彈性，專案的風險越大，下圖是某個高風險多角色專案deadline反推的里程碑，完全沒有任何彈性：

為了保證核心里程碑的推進，高風險的專案還需要拆解出重要里程碑，讓各方都能感知到專案進度與里程碑的推進成本。
舉個簡單的例子，在技術方案評審里程碑下面，我們至少需要圈定資源與產出技術方案，那麼資源圈定里程碑與技術方案設計里程碑就必須明確給出deadline。

里程碑細化的好處不僅僅是將專案進度透明、風險及時更近，而且是動態推算成本的好工具，是PM管理專案的金鑰匙。

收斂不確定性

很多高風險的專案在初期可能風險很低，但是需求的不確定性、業務決策的搖擺，往往導致專案預期很差，甚至發生大面積的不可用。

為了避免這種情況出現，就需要PM在專案整個過程中強控並收斂不確定性，下圖是需求收斂情況與專案完成質量之間的關係圖：

需求越發散，釋出質量越低；需求越收斂，釋出質量越高。但是，絕大部分專案很難在專案伊始做到絕對收斂，細微的需求變更總是在所難免，尤其是網際網路公司的專案。因此會有一個需求收斂的【拐點】，當收斂到一定地步的時候，釋出質量的提高與需求收斂程度已經沒有關係，且需求本身也很難進一步收斂，我個人喜歡稱之為【收斂疲憊】。

作為PM，應該儘可能保證讓所有不確定性都收斂在技術方案評審結束之前，且高風險專案尤其需要注意3次收斂：

1.PRD階段，保證子需求粒度下的需求收斂；
2.技術方案階段，保證子模組粒度下的方案收斂；
3.日常測試階段，保證所有開發實現細節的需求收斂。

技術主動推動專案

一般情況下，是需求驅動專案、專案反哺業務，但很多高風險高優先順序的需求，往往需要技術主動推動專案，以更大的責任感更多的精力投入到專案管理中。
這裡不得不提到另一個問題：技術何時投入一個專案？
在業務型開發團隊中，PM需要在MRD階段開始介入並瞭解整個專案，儘可能把控每個業務細節，協助運營同學做業務決策，幫助產品同學梳理產品規則與專案規劃。

下圖是PM投入時間與專案可控程度的關係圖：

在實際管理的過程中，PM將精力過多地投入到管理中，會容易陷入需求細節而忽略全域性考慮，對專案可控力度反而不利。

拋開一般的推動列表，高風險專案中還額外需要特別推動幾點：

1. 業務架構與方向不清晰的時候，需要協助業務決策並推動輸出；
2. 產品框架不清晰，產品模組化較為模糊；
3. 需求投入產出比較低，業務方案被挑戰；
4. 技術方案出入較大，多方協同難以達成一致；
5. 領域邊界不清晰，各個模組的業務邊界模糊。
   對於以上問題，PM可能不是最合適的問題解決者，但一定是最合適的推動協調者。

透明與協同

高風險專案的一個典型特徵是所有人所有角色之間都不可或缺地參與到專案中，且彼此之間風險共擔。
讓所有人知道你在做什麼，有什麼風險，應對策略是什麼，推進到怎樣的進度了，是高風險專案必須做到的。我們來看下面幾張圖：

• 專案透明度與風險的關係

我們發現專案透明度越高，風險就越低，直到最後維持一個不為零的基本線上。這說明，透明是多麼地重要！

很多人雖然很清楚這一點，卻往往在溝通的時候，忽略一些關鍵角色。有幾個典型的小例子：

1. 技術方案溝通清楚後，僅通知方案涉及人員，並沒有通知專案組其他模組的核心技術同學、測試同學、系統聯調同學，導致後期重複溝通，並遺漏實現細節；
2. 產品同學與合作伙伴溝通產品方案後，僅通知產品與業務方，並沒有與技術同學溝通也沒有同步最新進展，導致後期產品對接不匹配，臨時調整產品方案；
3. 技術同學將產品釋出上線之後，僅內部通知，並沒有通知業務方釋出內容，導致運營同學對線上功能模糊不清，業務需求容易斷層。

• 專案協同情況與風險的關係

高風險的專案往往需要投入大量的精力協調溝通，協同情況越好，專案風險越低，最終會維持在一個不為零的基本線上。這說明，協同是多麼地重要！協同除了需要具備“不要臉”的特質，還需要良好的溝通能力，對PM的軟技能絕對是一個挑戰。

• 專案透明度與專案協同成本的關係

過猶不及。過渡地追求各方透明，會極大地增加協同成本，導致專案整體成本增加，甚至威脅到釋出上線。優秀的PM，會適度地將專案資訊輸出透明，使協同成本控制在一個適當的範圍內，不至於疲於開會、失去里程碑。

設定核心里程碑的底線

協同的過程中，必然會遇到需求不收斂的情況，這就需要我們依據底線進行判斷與決策。不同於里程碑內容，專案的底線並不是用於推進專案，而是為了說不，從而控制風險。

一般情況下，核心里程碑的底線包括時間底線、內容範圍的底線、資源底線等。在專案成本可控的前提下，合理利用底線，能夠最大力度幫助PM控制風險，保障專案上線。
事實上，我們經常使用這個原則，舉個簡單的例子：不完成冒煙用例，絕不接受需求提測；在某個時間點之前不完成PRD評審，不保障需求內容釋出上線。

承擔更多

與專案組其他成員不同，PM必須主動承擔更多，並時刻保持清醒的頭腦，避免被髮布時間衝昏頭腦。

在高風險的專案中，存在較多的非技術困難，比如好的技術方案因為時間成本而不適合自己的專案、嚴苛的測試流程可能需要多通路並行提測、非常多的溝通會議且與會人員涉及多團隊多角色。好的PM會適當控制非技術困難的問題，儘可能通過協調的方式將結論透明給各方，而不是全員出動、全員面對。

高風險專案中，PM與組員一起面對核心困難並解決困難，能夠極大提高團隊士氣與整體激情。這在專案的開發、提測階段是有利的，但需要特別注意的是，激情太高反而會降低整體質量，尤其是在測試階段，容易遺漏細節。

寫在最後的

從立項開始到整體交付之前，在整個專案的生命週期內，PM是唯一全知全能的介面人，因此作為高風險專案的PM：

專案的任何環節的任何問題，PM都必須主動承擔、面對、解決，不論它是技術問題、產品問題、業務問題還是其他問題；
專案的任何方案與產出，PM都必須清楚知曉，不論它是產品方案、技術方案、測試方案還是相關的其他專案的方案；
專案的任何協同透明，PM都必須一站到底、責無旁貸，不論是溝通、協調、計劃還是配合共建開發。