互聯網產品管理屬于復雜的工程管理，因此對產品經理和項目經理的能力要求在逐年增加。

幾年前，我慣于單兵作戰，秉持著有活搶著做的觀念工作，一個人大包大攬什么都做，對于產品的管理基本上依賴對自我的管理來完成，結果并不理想。后來我有機會擔任產品總監后，才逐漸形成了最適合自己和團隊的產品管理方法，并非說有權限了才能實施這些方法，而是這些方法只有在一個完整的環境中才能更好地開展。

因此，以下的內容或許更多地面向那些正在從事產品管理工作的同仁，也部分解答了有些朋友私信我的關于產品工作中為何總是容易碰壁的原因。

一、什么是產品管理？

產品管理工作嚴格說是產品經理工作的一項重要內容，在有些團隊中，也被稱之為項目管理，國內對這兩個概念并不會嚴格區分，所以有些公司會有項目經理和產品經理，而另外一些公司只有產品經理。

產品管理的概念范圍實際上是小于項目管理的，但繼承了項目管理的一部分屬性，其中有最為關鍵的三個特點：

1. 獨特性：有時也被稱為一次性，每個項目和項目管理的過程都存在差異性，都不一樣。哪怕相同的需求，但是不同的人參與，不同時期的外部環境不同都會帶來變化。
2. 臨時性：項目都有明確的開始時間和結束時間，開始時間和結束時間所持續的時間稱為項目的周期或工期，項目的臨時性不意味著項目周期短，另外項目是臨時的，但是項目的交付成果有的卻是永久的。
3. 漸進明細：項目相關方對項目的要求/產品特征以及管理要素的認識是一個漸進的過程。

產品的管理工作，其定義簡單，但由于環境復雜多樣，組織的管理意識層次不齊，特別在創業型企業中，想要養成良好的產品管理習慣和成體系的流程困難重重。這也是許多產品新手經常感到困惑的原因，工作確實繁忙，每天都做了很多事情，但更多的狀態是不知道下一步該做什么。

二、組織環境決定管理方式

大部分項目失敗是從源頭開始的，創業者最愛說的一句話是：這個點子特別好，一定能成功！我相信好點子和創新是一個產品成功的開始，但這絕對不是最大的影響因素，反而往往是看起來不起眼的人事關系/組織架構影響了產品的發展方向。

為了偷懶，直接挪用了項目管理中的組織結構對項目的影響示意圖，對于互聯網產品類型的項目，其實同樣適用。

對于一般的創業型公司，系統型組織結構最為常見，這是受資源可用性影響的，老板往往就是“產品經理“兼”項目經理”，因為資金有限，很難在前期招攬到優秀的管理人才，所以凡事親力親為，發現問題也常常是看到誰就分配給誰，沒有額外精力去進行產品管理工作。當然，這也極大程度地增加了項目失敗的風險。

更成熟的單一業務公司中，職能型組織結構偏多，因此身處其中的產品經理會經常覺得，部門之間的矛盾好像非常多，多到難以化解，要調用資源時往往是互不買賬。于是就有產品經理覺得，自己的能力沒有問題，主要是公司氛圍太差勁了，其實是沒有看明白自己的位置和所處的組織結構。

對于業務更為廣泛的公司而言，往往按照項目導向或者強矩陣來開展工作，而這些項目成長起來后，甚至可以脫離母體生存，形成新的公司。這類組織結構下的產品經理會有兩個選項，一個是承擔起整個的產品管理壓力，另一個是公司另外安排項目經理，產品經理為其提供對于商業論述和產品設計方案等方面的可靠輸出。

其他還有一些組織結構，都有各自的特點，如果常常覺得自己的工作有阻力，我建議各位產品工作者從了解公司的組織結構開始，從頭了解自己工作的意義。當然，正如前文所述，也經常存在公司本身忽視組織結構重要性而導致分工不當的場景，理論都是完美的，但執行起來卻是錯漏百出，那就需要單獨進行分析和判斷，不在此處贅述。

三、管理工作的生命周期

在管理領域，通常認為好的產品項目管理模式，是成體系/可進化/約定俗成的。根據國際PMI的標準，我們將項目管理分為五個過程十大領域。

五大過程組分別是：啟動/規劃/執行/監控/收尾。

十大領域分別是：整合管理/范圍管理/時間管理/成本管理/質量管理/資源管理/溝通管理/風險管理/采購管理/干系人管理。

在不同的過程階段，產品的管理者需要針對各個知識領域做各種各樣的工作，從上面的表中可以看出，規劃過程組的工作是遠遠多于其他過程組的，這由績效成本曲線決定：計劃越周密，在執行/監控/收尾過程組中產生的風險成本就越少。

四、產品管理流程

在我的定義中，更希望將產品經理和項目經理的職能界限分開討論，但在產品管理工作過程中，我們也常常發現，產品經理很大程度上承擔了一部分項目經理的職能。但在接下去的討論中，我仍然將其嚴格分開說明。

互聯網產品管理屬于復雜的工程管理，因此對產品經理和項目經理的能力要求在逐年增加，這些要求集中體現在對風險和資源成本的判斷上。

我們常常說互聯網產品經理是越老越吃香，那是因為隨著經驗的累積，從業者對于不同知識領域的考慮維度越來越細致，真正能夠做到運籌帷幄決勝千里之外。而初級的產品工作者，在這些方面很難做到面面俱到。

系統性地學習產品管理流程，在我看來，其實是從業者的第一課，也是漫長職業生涯中一直需要反復驗證的課題。

1. 制定項目章程

在制定項目章程之前，我們有一些必須要做的工作，那就是對我們將要做的產品進行商業論證，這往往是整個高層團隊去決策的事情，其中包括對產品在宏觀價值上的定義，對資金流的預估和測算，對市場的預測和判斷。在很多公司，這個環節往往會被遺漏掉，項目在啟動前如果未能經過全局性的判斷，在后期執行過程中以及完成項目后有極大的可能出現紕漏。

制定項目章程的過程，就是一個定義產品目標的過程，項目章程中包含以下幾個最重要的信息：

1. 產品的目的；
2. 由誰發起；
3. 授權由誰管理；
4. 產品描述；
5. 產品的高水平要求（難點）；
6. 總預算是多少；
7. 啟動風險有哪些；
8. 里程碑；
9. 基本驗收標準；
10. 管理人的授權范圍以及反饋制度；
11. 發起人的書面簽字授權。

項目章程的重要性在于，保證一個產品的啟動具有其合理性與合法性，而非“拍腦門”的產物，產品經理常常會在項目章程制訂前做充分的市場調研和競品調研，這就是商業論證的一部分。而一旦經過商業論證后，公司高層決定啟動項目，那么就會由發起人委派產品經理或者項目經理進行接下去的一系列為達到目標而進行的工作。

2. 識別干系人

識別干系人，通俗地說，就是找到和這個項目相關的所有人，可能是利益相關方，也可能是發起人，也可能是某個資源，也可能是客戶。當我們在做具體的產品規劃前，第一件事情不是急于動手寫PRD，而是找到在這個產品中，我們需要考慮哪些人對產品的影響，而他們對產品的看法有時候往往會影響后續的實施。

應該有不少產品經理面對過這種窘境，產品都即將上線了，這個時候被某個上級指責說做的有問題，和他想的不一樣。還有一些時候，產品做著做著，就多出了一些需求，上線時間一拖再拖。這些問題產生的根源就是沒有在項目初期做好干系人的識別，導致在規劃階段沒有將這些干系人的影響考慮在內，從而產生不必要的內部管理成本。

3. 創建WBS

項目章程確定后，項目經理召集干系人開項目啟動會，并且在會后開始進行范圍管理相關的工作。范圍管理中的收集需求，定義范圍等等，就是產品經理最為熟悉的工作——撰寫產品需求文檔，這個各有各的標準和習慣，因此著重講一講創建WBS。

WBS全稱為Work Breakdown Structure，即工作結構分解，把項目按階段可交付成果將項目工作分解成較小的，更易于管理的組成部分的過程。一個宏觀的任務，被一塊一塊地分割成彼此獨立互不干擾的小任務，產品經理尤其要注重對這種結構式思維的鍛煉，才能在設計產品時同時兼顧創新性和可行性。

大家看到上面這個案例會覺得很熟悉，這不就是我們常常畫的思維導圖嗎？沒錯，這就是創建WBS的輸出文件，但不同于一般的思維導圖天馬行空隨意涂鴉，WBS在制作時有幾個明確的規定：

• 包含關系：分支上下100%包含；
• 不可再分：最底層相對獨立不可再分，最小可交付成果；
• 信息透明：分解到可以充分估算完成該成果所需的時間/費用/資源等；
• 獨立責任：分解到可安排一個責任者。

因此我們可以說，當創建WBS的工作完成時，我們已經知道產品的范圍邊界在哪里，做什么和不做什么得到了解釋。

4. 制定進度計劃

產品管理者與開發人員往往在排期二字上產生分歧，一邊覺得交付時間太晚，一邊覺得開發時間不夠，如何合理制定進度計劃是解決這個矛盾的關鍵點。在WBS的基礎上加上對活動資源和順序的規定，就能夠制定出進度計劃，一般我們會使用一些工具和方法，比如說Omniplan和Project。

上圖所示的甘特圖就是非常典型的用于顯示進度計劃的技術，左側是層級分解的任務列表，右側是可視化的時間區間，組合成了包含任務定義/開始時間/結束時間/持續時間/任務優先級/資源約束在內的進度計劃，而開發人員只需要估算具體子任務的持續時間，就可以計算出整體的排期。

制定進度計劃的核心在于估算活動資源和排列活動順序，估算活動資源的方法有很多，比如：三點估算法等等，這里就不展開來講，有興趣的朋友可以百度或者私聊我咨詢。排列活動順序的方法主要是關鍵鏈法和關鍵路徑法，活動之間往往由關聯性，活動A完成后才能繼續活動B，活動B和活動C之間存在資源競爭關系，因此不能同步進行。只有充分考慮了這些制約因素，才能夠制定出合理可行的進度計劃。

5. 制定預算

身邊有產品朋友總是和我抱怨，不明白為什么產品經理還需要在做完方案之后參與制定預算，他們都覺得這是財務的工作，這就是工作中的常見誤區。制定預算的工作，不參與具體業務執行的財務人員往往無法獲得第一手信息。

通常情況下，產品經理將根據投入的資源和預期的回報來評估這個項目是否值得去做，他才是最了解預算的人，因此這項任務落在產品經理頭上并不奇怪。

預算和進度計劃一樣，是通過各項活動所需要的子預算組合得到的，主要包括項目本身需要的成本（人力時間成本/采購成本等等）和管理需要的成本。前者是通過活動使用計算得到，而管理所需要的成本往往是項目成本的10%到15%。

因此我們的預算，在不考慮各種干擾因素或者不可控因素的情況下，是總體成本的110%到115%左右。當項目中遇到了不可預測的風險時，就需要動用這多出來的部分來應對。

6. 實施整體變更控制

由于篇幅有限，資源管理/溝通管理/風險管理/采購管理/干系人管理中的大部分內容就不在這一篇文章中一一去講，如果有需要可以私下溝通。當然，如果問的人多也許會考慮另外花點時間寫一篇來說明一些細節。

重點想要說的是如何應對變更。

我們監控產品的開發實施過程，有時候突然發現一些預料之外的事情，比如前面提到的，未將核心干系人的意見納入到產品中，或者說發現了一些新的風險將打亂原先的計劃，這些都是隨時可能發生的事情。

在實施整體變更流程之前，首先要做的事情是了解需要變更的原因和變更可能帶來的影響。這些影響可能包括進度/質量/資源/成本/采購方/干系人等所有我們前面提及的知識領域，這要求產品經理或者項目經理召集各位在這個領域的專家以及團隊成員一起來協助評估變更的影響范圍。

按照正規的流程，我們有以下步驟：

1. 有人提出變更申請；
2. 產品經理/項目經理召集小組開會討論評估變更；
3. 將評估結果匯報給需求變更控制委員會；
4. 根據需求變更控制委員會的決議實施變更并記錄變更過程；
5. 更新問題日志。

這里有兩個新詞匯：一個是需求變更控制委員會，一個是問題日志。

需求變更控制委員會往往是一個由公司高層組成的團隊，該團隊中的成員有承擔需求變更帶來的影響的能力，在有些公司，它就是老板一個人乾綱獨斷，而在更大規模的公司中，可能是股東或者董事會來決策。它由哪些人組成并不是最重要的，最重要的是這個團隊將負責根據產品經理提交上來的需求變更及評估報告來判斷是否允許通過變更。

我和多個公司打過交道，發現越是不注重變更控制流程的團隊，其團隊氛圍和項目執行結果往往越差，這是有道理的，如果在規劃階段沒有很好的定義好產品需要做的事情，反復變更需求時又不按照標準的變更控制流程走，每個人都會下意識地認為制定計劃是沒有意義的，只有盡可能讓需求變更不那么隨意，才能反向彰顯出產品管理計劃的重要性。

問題日志是用于記錄產品管理過程中出現的問題的，一旦出現了變更，往往意味著原先的規劃是存在一定問題的，將問題記錄下來，才有可能在今后的管理工作中提前規避掉。

總之，實施變更控制流程是整個產品管理環節中，經常被忽略但又極為重要的環節之一，掌握了這個技巧，產品經理的在應對問題上的能力將會有長足的進步，這遠不是一個“原型”經理能做的事情。

7. 結束項目或階段

雖然很多環節都跳過了沒有講，但是結束項目或階段這個環節，仍然沒有辦法草草地一筆帶過。

我們做事情常說一句話：有始有終。這在產品管理工作中同樣如此。

產品上線了，組織一場結案會議，講一講項目中遇到的問題，對項目的成果進行匯報，提醒大家各自在工作中表現得出色或者不足的部分，給工作畫一個階段性的句號。當然，還可以在會后組織一場小小的團建來慶祝項目收尾。

在產品管理過程中需要那么多的技巧和工具，管理者依靠發起人的授權開始了整個項目，并在項目過程中與成員們磨合出默契，而在結束項目的過程中，通過回顧和展望往往能夠碰撞出更多的情感。

尾記

產品管理是由方法和工具指導的藝術，單純依靠人格魅力獲得產品成功的案例至今我還沒有看到過，反而是善用產品管理方法和流程但不拘泥于其中的團隊創造出無與倫比的價值。

互聯網大公司之所以能夠源源不斷地產出高質量的產品，其根本原因就在于對產品管理流程的合理運用與控制，大公司出來的創業者容易成功的原因也在于此。而中小型公司必須意識到，想要在市場中立足，就需要充分理解產品管理方法，并根據自身公司的實際情況來制定出適用的流程來。

而身為產品管理工作者，經驗的積累是一部分，借鑒好的方法和理論來降低走彎路的可能性也是非常重要的，希望本文中分享的這套成體系的產品管理方法可以幫助到大家。

實踐出真知，也希望大家通過實踐不斷自我驗證，在產品職業生涯上越走越順利，敬謝支持！

本文由 @路遙 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。