本文將從 Project 軟件的獨特視角，強調(diào)產(chǎn)品經(jīng)理需要的項目管理相關思想及其關聯(lián)知識。

在網(wǎng)上流傳著這樣一份騰訊產(chǎn)品經(jīng)理能力模型，暫且不論其真假，但不難發(fā)現(xiàn)做一名合格的產(chǎn)品經(jīng)理需要非常綜合的各項專業(yè)能力。

而在能力模型中有一項很重要的能力就是項目管理能力，它能在產(chǎn)品的整個生命周期中，幫助 PMer 進行產(chǎn)品迭代的規(guī)劃、各類資源的整合以及生產(chǎn)進度的把控。

在日常工作中，大部分企業(yè)或團隊都會選擇一些協(xié)同軟件來進行產(chǎn)品/項目的管理。但在更專業(yè)的項目管理領域，項目經(jīng)理們普遍采用 Microsoft 出品的 Project 軟件來進行這項工作。

本文將從 Project 軟件設計的獨特視角，強調(diào)產(chǎn)品經(jīng)理需要的項目管理相關思想及其關聯(lián)知識。至于 Project 的強大功能及其使用方式，不在本文的討論范疇中。

一、三個原則

1. 越快越好

在 Project 中，每一個項目的開始都需要建立項目信息，主要填寫的是項目開始日期以及日程排定方式。其中日程排定方式提供兩個選項：以項目開始日期或以項目完成日期。

當切換兩個選項時，Project 會給予用戶相應的提示：選擇項目開始日期時會提示所有任務越快開始越好，相反選擇項目結束日期時會提示所有任務越慢開始越好。

為什么會有這樣的提示呢？先設想以下兩個場景：

1. 老板制定產(chǎn)品迭代計劃，要求從今天起 3 個月內(nèi)完成產(chǎn)品 2.0 版本的迭代
2. 老板制定產(chǎn)品迭代計劃，要求 10 月 1 日完成產(chǎn)品 2.0 版本的迭代

盡管兩個場景都是對產(chǎn)品迭代時間的要求，但在第一個場景中老板規(guī)定的是開始時間和預算時長，而第二個場景老板規(guī)定的則是完成時間。

很顯然在日期排定時，第一個場景肯定是以項目開始日期為標準，在 3 個月內(nèi)越快完成越好；而第二個場景肯定是以項目完成日期為標準，只要能在最后期限前完成即可。

那么問題又來了，為什么在 Project 中以項目完成日期為標準時需要越慢越好呢？其實這就對應了項目管理中兩個重要的原則：

1. 越快越好原則(ASAP)：項目中所有的任務都越早開始越好
2. 越晚越好原則(ALAP)：在不延誤其他項目任務的情況下任務越晚開始越好

實際上，大部分的產(chǎn)品迭代或項目管理計劃都會以 ASAP 為標準，因為在有限的預算工期內(nèi)當然越快越好。但是仍然會有部分產(chǎn)品/項目內(nèi)容與時間具有明確的關聯(lián)性，此時就會采用 ALAP 為標準。

舉個簡單例子來幫助理解，如下圖某產(chǎn)品在 8 月 1 日制定一個 2.0 的版本迭代計劃，迭代目標是慶祝國慶特別版本，所以需要在 10 月 1 日當天完成上線。

計劃中有三個任務：工期 30 天的開發(fā)任務、工期 10 天的測試任務以及工期 1 天的上線任務。

按照 ALAP 的原則，開發(fā)從 8 月 1 日可以開始，但此時在不延誤 10 月 1 日完成上線的情況下，測試可以晚幾天再開始。而開發(fā)和測試任務之間存在一些空白時間，稱之為窗口時間，作用主要是用來提供緩沖、規(guī)避風險，下文會再次提到這個概念。

也就是說，不論是 ASAP 還是 ALAP 都有具體的使用場景。但需要注意的是，兩者都不適用某些任務需要在特定日期開始的情形。仍然以上述例子說明，測試任務如果規(guī)定必須 9 月 10 日開始，此時就違背了 ALAP 原則。

事實上，不論是在 Project 中還是在日常真實工作中，我們都建議選擇 ASAP 即越快開始越好原則。原因是 ALAP 原則會帶來一個非常麻煩的問題，也就是臭名遠揚的帕金森定律。

帕金森定律在項目管理上強調(diào)的是：任何任務都會拖延，直到所有可用的時間用完為止。

這里舉一個不恰當?shù)锥睦印髮W生復習效率圖(案例來源：酸梅干超人)，非常形象的描述了這一定律：

而 ALAP 原則允許任務越晚開始越好，導致一切任務都存在拖延的可能性。所以在項目管理中，為了避免帕金森定律，我們首先要遵守第一原則——越快越好原則。

在日常產(chǎn)品迭代中，最常見的方法就是利用越好越好原則，按照研發(fā)團隊真實情況順推產(chǎn)品研發(fā)進度排期。假如順推后的完成時間早于計劃截止時間，則可順利進行；假如順推后的完成時間超過了計劃截止時間，此時就應該進行相應的風險處理。

例如利用常見的壓縮工期方法，對關鍵路徑上的任務進行壓縮處理，直到達到計劃要求。下文也會著重闡述如何應對風險，這里暫不展開。

2. SMART 原則

大部分產(chǎn)品/項目新人都會存在一個誤區(qū)：在使用 Project 管理產(chǎn)品/項目時，最基本也最核心的操作其實并不是利用甘特圖等工具或視圖來管理進度，而是利用 Project 內(nèi)置的 275 個預置列來設定好項目目標、分解各級任務以及各任務間的關系。

如下圖案例，通過對任務名稱、工期、開始時間、完成時間、前置任務這 5 個預置列的創(chuàng)建，我們很容易也很清晰的梳理了整個迭代計劃明確的任務內(nèi)容、任務期限以及各個任務的關聯(lián)情況。

基于對任務基本項的設置，Project 會自動生成任務的甘特圖，為后續(xù)的進度管理提供強大的工具支撐。也就是說 Project 的核心仍然在于對各目標任務的管理，這恰好就是目標管理中 SMART 原則的核心思想。

對于 SMART 原則，這里簡單描述為：目標必須是明確的、可衡量的、可實現(xiàn)的、具備相關性的以及有明確期限的。

而該原則映射到項目管理中，仍然具備可實施性：計劃/項目/任務必須是明確的、可以有具體的成果來衡量的、是可以實現(xiàn)的、相互間具備關聯(lián)性的以及具有時間限制的。

其中 Project 預置列中的前置任務，主要用來設置任務間的依賴關系，它是對關聯(lián)性最佳的實踐：

總結來說，在產(chǎn)品/項目管理中為了更好的完成產(chǎn)品/項目最終目標，我們應該遵守第二原則——SMART 原則。

3. 黃金三角原則

盡管 Project 的定位是一款優(yōu)秀的項目進度管理工具，但它仍然提供了強大的資源管理和成本管理功能。

在進度管理中，通過各任務的分解與規(guī)劃，可以完成項目范圍及時間的設定；而資源管理和成本管理則約束了整個項目所使用到的人力資源與材料或工時成本。

從日常使用 Project 進行管理工作時不難看出：

• 任務越多，成本越大，時間越長
• 成本有限的情況下，需要縮短工期或減少任務
• 時間一定的情況下，需要增加成本或減少任務

一旦出現(xiàn)這樣的情況，在 Project 的狀態(tài)列中都會給予相應的告警提示。例如上方的案例，可以直觀的看出實際成本比預期成本要高，此時就不得不推遲或取消某個任務來控制成本。但推遲或取消某任務后又會影響整體計劃的目標結果。

在項目管理專業(yè)領域中，這種情況就對應了由范圍、時間和成本組成的黃金三角形。在這個三角形中，不論對哪一邊的調(diào)整都會影響另外兩邊。

如果我們想要高質(zhì)量的完成一項產(chǎn)品/項目計劃，就一定要考慮到這三者的平衡。不僅要保證范圍符合既定目標，同時也要保證時間與成本符合項目要求。也就是說，我們應當遵守第三原則——黃金三角原則。

二、兩個思維

1. 基準思維

除了 1.2 節(jié)中提到的使用誤區(qū)外，還有一個新手常犯的錯誤：他們在所有任務分解與資源安排等基礎工作結束后，直接就進入項目開始階段。盡管他們每天會根據(jù)實際情況更新進度，但遇到異常情況也沒辦法進行分析判斷或控制措施，直到計劃遭遇不可逆轉(zhuǎn)的整體延期才意識到項目失敗。

出現(xiàn)這樣的問題，是因為沒有利用好 Project 的一項重要功能——設置基線。

基線顧名思義就是基準線，它是在項目計劃完成初期用來保存任務分解結構、工期安排與資源分配情況的一個重要工具。原則上，基線不會隨意變更，如果有變更按照 PMI 的規(guī)定必須要走嚴格的變更控制流程。

它的作用在于，當項目真正啟動后保證項目各方面嚴格按照初始計劃進行，同時在出現(xiàn)偏差情況時提供鮮明的提示和明確的分析思路，防止一些可能的風險導致項目整體失控。

通常使用基線時分為四個步驟：

1. 設置基線：當計劃按照既定的安排確定后，以此為標準設置基線；
2. 記錄進度：每天根據(jù)實際項目進展情況記錄真實數(shù)據(jù)，供與基線比較；
3. 分析偏差：如果實際進展與基線出現(xiàn)較大的偏差時，根據(jù)記錄數(shù)據(jù)分析根本原因
4. 糾偏措施：通過分析明確原因后，針對性的進行糾正措施，保證項目回到正軌

值得強調(diào)的是，項目實際情況與基準有偏差是一個很常見的現(xiàn)象，重要的并不是防止偏差的出現(xiàn)，而是如何利用基準思維去規(guī)范、約束和糾正項目計劃，保證項目順利完成，這才是我們要掌握的核心思想。

這里還要補充一點，基準思維不僅僅可以運用在項目管理領域，其他各個行業(yè)或環(huán)節(jié)中都可以靈活運用。比如在需求分析環(huán)節(jié)，可以設置需求基準，保證后期在需求變更時有一個標準參照，防止需求出現(xiàn)大的范圍偏差。除此之外還有產(chǎn)品基準、測試基準等等。

2. 風險思維

從 2.1 節(jié)繼續(xù)延展，通過基準思維我們可以對偏差進行分析。從分析過程和結果中，往往可以識別到項目整體上的一些風險，從而針對性的進行預判風險和處理風險等應對方案。

這就要求，我們需要具備風險思維。它是幫助產(chǎn)品/項目管理者們分析風險、規(guī)劃方案以及處理風險的最佳工具。

其實在項目管理專業(yè)領域，風險管理是一個大的命題，例如 PMI 的風險管理流程足夠完善和健全，但過于繁瑣，不太適用大多數(shù)實際場景。如何預防進度失控以及如何糾正進度失控場景，才是大部分產(chǎn)品/項目管理者們關心的問題。

回顧 1.1 節(jié)，提到的兩個概念。第一個是越慢開始越好原則，該原則在樂觀情況時會出現(xiàn)一些窗口時間，來提供任務間的緩沖，但在悲觀情況下會帶來帕金森定律。

那么如何既能有緩沖時間又能克服帕金森定律呢？方法就是使用關鍵鏈法。

關鍵鏈法強調(diào)的是，所有任務都要遵循越快越好原則，以最快速度完成，但要在任務路徑的末端設置好項目的緩沖時間。其實說白了就是在項目初始排班時，就應該考慮到延期風險，來主動設置緩沖時間來預防。

那么也存在少數(shù)工期極為緊張的情況，即使按照越快越好原則，仍然會導致項目超過預期截止時間，此時就是提到的第二個概念壓縮工期。

壓縮工期主要是壓縮關鍵路徑上的任務，至于什么是關鍵路徑，下文詳細說明。其實壓縮無非就是三個常用方法：

1. 減少任務：適當縮減或砍掉造成延期原因的任務，可納入后期迭代計劃中
2. 增加資源：適當增加人力資源，合理均攤工作量，協(xié)同快速完成任務
3. 多方并行：本來按計劃執(zhí)行的任務，允許并行執(zhí)行，減少任務間等待時間

這就是本文強調(diào)的風險思維中兩個重要概念——工期緩沖和工期壓縮，也正是解決如何預防進度失控以及如何糾正進度失控的核心。

三、三個工具

1. 甘特圖

Project 中最核心的視圖莫過于甘特圖，就連 Project 的 Logo 中都帶有甘特圖的樣式。

甘特圖是一種表達項目進度與時間之間關系的圖形，其畫法和圖形元素并不是本文重點。需要強調(diào)的是，基于上述的三個原則和兩個思維，再配合使用甘特圖，能非常便捷高效的進行項目進度管理工作。

例如基于越快越好和 SMART 原則，甘特圖可以展示每個任務間的緊前緊后關系；基于基準思維和風險思維，甘特圖可以直觀的展示進度偏差，提高識別風險的效率。

可以說甘特圖不僅僅是 Project 的核心功能，更是項目進度管理的必備工具。

2. 資源日歷

從上述內(nèi)容可以明確的知道，Project 的核心功能其實就是進度管理。那么在工期的設置和任務的排班上，日歷功能必不可少。

在 Project 中，不僅僅可以直接選擇標準雙休日歷，還可以在標準日歷的基礎上設置更多例如法定節(jié)假日、6天工作制或大小周交替等等不同類型的日歷，完全可以滿足我們?nèi)粘９ぷ髦谐霈F(xiàn)的各種場景需求。

不僅如此，Project 在日歷功能上還充分考慮了工時類資源的可用性。具體體現(xiàn)在我們可以給不同的工時類資源設置不同的工作日歷，最大程度的保證在項目排期時資源是可用的。

這里可能很多人會有疑惑，為什么需要考慮資源可用？

設想這樣的場景：一個工時類資源例如開發(fā)工程師，數(shù)量有限而且只能在特定時間可用。如果將其中一個開發(fā)工程師在同一時間段內(nèi)分配兩個或兩個以上的任務，就會造成他的過度分配。此時就需要通過資源優(yōu)化技術來保證資源分配的合理性，例如常見的資源平衡方法。

而 Project 提供的資源日歷不僅限制了資源的可用范圍，而且在資源分配后提供了不同的視圖供我們參考。例如下圖的資源使用情況非常清晰的告知產(chǎn)品/項目管理者資源分配出現(xiàn)了異常：

所以說我們不僅要會使用資源日歷，還要充分理解其背后運用的相關原理，這樣在使用的時候就會有明確的功能目的。

3. 關鍵路徑

在日常產(chǎn)品/項目管理工作中，有一個很常見的場景：當整體項目計劃排定后，管理者會在計劃中標注好哪些任務至關重要或者哪些任務不能出現(xiàn)延誤。

這個場景在 Project 中可以很方便快捷地用突出顯示功能來直接顯示整體計劃中的關鍵任務路線。而在項目管理領域，這種方法其實叫關鍵路徑。

至于關鍵路徑的專業(yè)定義、計算和查找方式，并不是本文的重點。這里我們可以簡單通俗的理解成，如果項目整體計劃中有一條任務路徑發(fā)生延期，必然導致項目的整體延期，那么這條路徑就是關鍵路徑。

例如從上圖一個簡單的迭代計劃中可以看到，五個任務中 APP 接口對接任務一定要在后臺接口開發(fā)任務和 APP 頁面開發(fā)任務結束后開始，但是后臺接口開發(fā)任務完成時，APP 頁面開發(fā)任務仍未結束，此時后臺接口開發(fā)任務有 2 天的窗口時間。

如果后臺接口開發(fā)任務發(fā)生了 2 天以內(nèi)的延期，其實并不會造成項目整體延期。但假如 APP 頁面開發(fā)任務延期了，則必然會導致項目整體延期，因為它并沒有窗口時間。同理 APP 接口對接、測試以及上線任務都屬于關鍵路徑。

學會使用關鍵路徑方法的意義在于，既能告知團隊成員計劃包含的風險來提前做好預防應對方案（風險思維），也能給未來項目正式開展后提供明確的參考基線（基線思維）。

總結

至此本文已近尾聲，正如文章開篇所說，做一個好的產(chǎn)品/項目管理者，不僅需要一個好的工具，更需要掌握項目管理的核心思想，也就是本文提出的 323 法則——三個原則、兩個思維和三個工具。

需要補充說明的是，本文拋棄了大多數(shù)文章或書籍使用的大段理論闡述方式，而是從 Project 軟件出發(fā)，運用真實使用案例來引出其功能設計背后蘊含的項目管理思想，這樣能讓我們更容易地去理解，同時也能給產(chǎn)品/項目管理新人們帶來一些實際的工作思路。

本文從選題到完稿時間接近一個月，由于項目管理體系之龐大，導致本文一度超過萬字。但為保證文章的高度可讀性和實用性，在審稿時刪減了半數(shù)內(nèi)容。這也是為什么文章很多地方看起來避重就輕的原因，例如并沒有介紹關鍵路徑具體的計算方式，也沒有說明資源平衡的專業(yè)方法。

但也正因這樣的不完美，才有持續(xù)學習的動力，既要是 Product Manager 更要是 Project Manager。

本文由 @ iamxiarui 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議