原標題：PMP有哪些知識點可以遷移到產品領域

最近完成了PMP的學習和考試，三個月的學習和連續四個小時的考試，回想起來真是欲仙欲死。項目管理和產品領域的關聯度很大，知識點多多少少有重疊的領域，就連它們的縮寫都是PM。

那么在PMP的知識點里，有哪些值得我們（產品汪）學習實踐呢？

首先，簡單介紹下啥是PMP。

PMP指的是項目管理專業人士資格認證。它是由美國項目管理協會（Project Management Institute(簡稱PMI)）發起的，嚴格評估項目管理人員知識技能是否具有高品質的資格認證考試。

PMP包括五大過程組、十大知識領域和49個過程。

01

商業論證和制定項目章程

PMP啟動項目的第一步，不管項目多大、多緊急，永遠都是商業論證和制定項目章程。

商業論證簡單來說，就是分析項目在經濟利益上是否有利可圖。方便高層判斷是否要做這個事。商業論證其實有點類似于產品領域的BRD文檔（商業需求文檔），目的都是判斷公司干這個事情，是不是有利可圖。

換一個文藝點的說法：商業論證的結論是項目或產品的初心。

商業論證可行后，下一步制定項目章程。項目章程是項目的綱領性文件，其中明確描述了項目和公司戰略之間的關系，確立項目的正式地位，同時描述了項目的目標、高層級的需求、期望和風險。

項目章程也是后續項目經理行使權力、進行項目管理的依據，可以說是項目經理的尚方寶劍。商業論證和項目章程在產品領域比較少見，很多都是老板說干就直接干了，很多人可能還會覺得這兩個東西是浪費時間。

但是，商業論證和項目章程對于產品來說也是很有借鑒意義的，因為可以讓我們從戰略大局的角度來認識這個產品，這有助于我們后期不跑偏。

特別是當我們陷入迷茫的時候，商業論證可以堅定我們的信心，而項目章程可以為我們指引方向。

我們不必非要有這兩份文件，但是商業論證和項目章程的全局思維方式，是我們必不可少的。

02

啟動大會與需求評審

PMP在項目啟動時，有一個有意思的會議，英文叫kick-off meeting，中文叫法很多，有的叫開踢會議、有的叫啟動大會。

啟動大會的目的，主要是召集項目團隊成員以及各個相關方，傳達項目背景和目標等信息，澄清項目相關問題，與團隊和相關方就項目目標、項目計劃等達成共識，為團隊灌輸信心，并獲得相關方的承諾。

在產品工作中，啟動大會比較少見，不過有點類似于我們的需求評審會。很多同學在需求評審的時候，多數都只是關注于如何將需求傳達給開發同學，但這其實只是需求評審會的一部分。

一開始就陷入細節的需求評審會很容易被噴得體無完膚，我們其實可以參考PMP啟動大會的目標。傳達本次版本迭代的背景和目標，目的是告訴開發同學，這次迭代為什么要做？做了以后能帶來什么價值？

另外，當團隊開始關注目標以后，有時候集思廣益可以給你帶來意想不到的驚喜。澄清功能需求的相關問題，這一點是大家關注最多的，不用多說。

就本次迭代的目標、迭代計劃等信息達成共識。達成共識才能勁往一處使，一個人心甘情愿才能最大限度發揮主動性。

03

識別風險

產品經理在工作中，最頭疼的問題，就是項目延期。項目延期的原因有很多，但是比較常見的有兩個：不斷的需求變更或發生了風險。

PMP是如何解決風險問題的呢？

首先，PMP將風險分為三類：

已知-已知風險：發生概率已知，造成的影響和后果已知，例如人員不夠；

已知-未知風險：發生概率未知，造成的影響已知或發生概率已知，造成的影響未知。例如有核心團隊成員離職的風險；

未知-未知風險：發生的概率和造成的影響都未知，例如突然的政策變化或者新政策發布。

前兩個風險都是可以也必須是要提前識別的，識別風險的常用方法有：

• 經驗教訓知識庫：參考類似項目遇到的一些風險；

• 頭腦風暴：組織團隊成員腦暴可能遇到的風險；

• 專家判斷：請有經驗的專家分析可能存在的風險；

• SWOT分析或PERT分析：針對大方向的風險識別。

第三種風險因為是未知的，沒辦法做到提前識別，所以需要未雨綢繆，預留一點的資源專門用來處理這些未知-未知風險。

值得一提的是，在PMP中未知-未知風險的預留資源成為管理儲備，是不計算在項目預算里的。風險識別成功以后，需要對風險進行定性和定量分析，然后制定相應的風險應對措施。

風險應對措施一般有5種：

風險規避：指的是有風險就不去碰它，繞道走，最極端的風險規避措施就是關閉整個項目；

風險轉移：指的是將風險轉嫁給他人，例如買保險，外包有風險的部分給第三方等；

風險減輕：指的是采取措施減輕風險發生的概率或減輕風險發生后造成的影響，例如加強測試，找更靠譜的供應商等；

風險接受：指的是碰運氣，只留了應對的資源，不采取任何其他措施；

風險上報：指的是超出項目經理范圍內的風險需要上報，例如國家政策發布。

制定完成風險應對措施后，最后需要將風險的詳細信息記錄在風險登記冊中，并且需要定期對風險進行審查，剔除已發生/已過期的風險，新增新識別的風險。

通過事先識別風險，事中監控風險，事后總結三步，可以有效的降低風險發生的概率以及風險發生后造成的影響。

04

如何評估工時

產品經理常常因為不能準確評估工時而被開發忽悠，被老板嫌棄。如何能有效評估工時呢？PMP提供了幾個方法：

1. 類比估算

適用于成熟的常見的項目，通過和類似的項目進行比較，就可以大致評估出工時。比如對于類似登錄模塊搭建這樣常見的通用功能，就可以參考以往的經驗。

2. 三點估算

三點估算是一種自下而上的估算方法，使用三點估算的前提是已經完成了對整個項目需求的細化拆解。

三點估算的三點指的是，最可能時間、最樂觀時間、最悲觀時間，也就是說，針對一個特定的任務，你需要問程序猿小哥三個問題：

產品汪：完成這個功能，你最可能需要多久？

——程序猿小哥：5天吧。

產品汪：那最樂觀時間呢？

——程序猿小哥：3天。

產品汪：那最悲觀時間呢？

——程序猿小哥：最悲觀的話，那我要考慮所有悲觀因素，13天吧。

得到三點時間以后，通過三點估算的公式，你就能得出這個程序猿小哥完成整個功能的期望時間：三點估算公式：μ =（最樂觀時間+4*最可能時間+最悲觀時間）/6。

上面的例子，使用該公式可以得出，程序猿小哥完成這個功能的期望時間是6天。

3. 參數估算

參數估算有點類似現在的機器學習，都是利用歷史數據和項目參數，使用某種算法來計算項目所需要的時間。

例如，將項目的功能點數*每個功能點的平均工時，參數估算的準確度取決于參數模型的成熟度和基礎歷史數據的準確性。

雖然在產品工作中一般都是研發同學估算所需工時，但是產品經理如果對工時有一套自己的估算方法，就不容易被忽悠，而且在對工時提出異議時，也能有理有據。

05

如何控制需求變更

產品工作中不可避免的問題之一就是需求變更。

需求變更和Bug一樣是我們想避免但是卻避免不了的，需求變更控制不好很可能會影響項目工期。而且頻繁的項目變更，會打擊團隊的士氣，同時也會影響產品經理和程序猿同學的關系，不利于建立信任關系。

并且，頻繁的需求變更會帶來另外一個問題：變著變著就忘記最后的結論是啥了！

因為頻繁變更，有時候忙起來就會忘記更新需求文檔，到最后驗收的時候，產品自己都忘了最后的結論是啥，就容易造成扯皮，大家各執一詞。

如果你倒霉一點，很可能還會遇到一個尷尬的事，老板經常會問這樣的問題：“這個地方為啥是這么設計的，我記得當時不是這么說的啊？”

這個時候，如果你當時沒有記錄的話，就會一臉懵逼……飛天大鍋穩穩的扛在了身上。PMP中對于需求變更的控制非常嚴格，有一套完整的變更流程：

項目經理對于不影響基準，包括時間基準、成本基準，的變更可以自己做決定，但是一旦涉及到基準的變更，就需要提交給變更控制委員會進行批準。

變更控制委員會的人員是由項目的各個關鍵相關方組成的，由高層領導、項目經理、研發負責人、客戶代表等多個利益方組成。

所以經過他們審批批準的需求變更，大家都是知情和認可的。這樣的流程能極大程度控制變更的數量，也能保證變更的質量，同時能起到及時知會各方的作用。

變更關鍵的一點是，不管變更有沒有被批準，都需要記錄到變更日志，親身經歷的血淚史證明，這真的是個好習慣！！

變更日志內容至少要包括以下四項：

當時發生的問題

提交的變更和提交人

需要變更的原因

變更被批準或被駁回的原因

這些內容方便對變更進行追溯，也可以在下次遇到類似問題的時候照搬作業，還是后面總結經驗教訓的素材，可以沉淀為組織資產，一箭三雕~

06

如何進行溝通

項目經理和產品經理，有一個最大的共同之處：很多時候都需要溝通，不是在開會，就是在開會的路上。

PMP總結了導致溝通不暢的九大原因：

我們在日常溝通的時候要注意規避這些不利的因素，在溝通時要注意簡潔清晰，詳略得當。

什么時候應該詳細，什么時候要簡潔，我們可以參考下橋哈里窗格：

橋哈里窗格分為四個象限：

1. 你知道，我知道：開放區

處于這個區域，說明是一些共同常識，這部分的溝通可以盡量簡潔，比如生活常識，通用公理，行業通用術語這種。

2. 你知道，我不知道：盲目區

這是屬于我的知識盲區，這種情況下，你就要盡量詳細的給我描述背景，傳遞我理解這件事所需要的背景或者知識。

認知理論上有一個現象專門對這個進行了描述：知識的詛咒，對于我們知道的東西，往往認為這很簡單，對方也肯定知道。但你要知道隔行如隔山。

3. 你不知道，我知道：隱秘區

這是我的秘密，屬于我個人獨有的知識。適當開放自己的隱秘區，可以增進彼此的關系。

36個問題幫助你找到女朋友，這36個問題本質上就是逐步開放彼此的隱秘區。這也是為什么樂于分享的人，人緣都比較好。

4. 你不知道，我也不知道：未知區

未知區是機會，需要我們共同探索的知識領域。

07

如何管理相關方

你有沒有遇到過這樣的情況：

“需求明明已經和老板對過了，然后我也已經在拼命推動開發。但是在驗收收尾的時候，某業務副總說這個不行，然后要重新來；開發那邊責怪我沒有事先對清楚需求，導致現在面臨加班通宵的局面，但是我也很冤啊。”

還有這種：

“這個需求你跟誰對的，我怎么不知道？”

“我們當時不是這么說的啊，以后這種涉及我的跟我對一下。”

“后端改了有通知到前端嗎？我們前端不知道啊，而且測試也沒有測出來……”

歷史總是驚人的相似，工作中這樣的事情經常發生。這可能是因為，你沒有做好相關方的管理。

需求你只和領導對了，但是卻沒有通知到潛在的相關方，導致需求不符合要求，重做；需求你自己寫完了，認為天衣無縫，于是直接提給了開發，但是哪里知道根本就是理解錯了，重做。

相關方，簡單來說就是跟你做這個項目或者需求有任意聯系的人。比如說你負責的是某業務后臺的搭建項目，那么相關的人就至少有：你的領導、該業務負責人、該業務核心人員（實際使用你后臺干活的）、開發人員、測試人員、設計人員。

如何識別這些相關方呢？

可以從是否參與項目與所受影響兩個維度來區分。

也可以按照相關方類型來區分：

比如：上游供應商、下游客戶、中間有老板、領導、開發團隊、測試團隊、設計團隊、運營團隊、業務團隊等。

將相關方識別出來之后，那么哪些相關方是需要我們重點關注，哪些相關方是無關緊要的呢？

畢竟我們的精力是有限，必須把我們80%的精力用在關鍵的20%的人身上，才能保證效率最大化。否則面面俱到只會把自己累死，吃力且不討好。

08

項目收尾經驗教訓

復盤很重要！復盤很重要！復盤很重要！

重要的事說三遍~復盤對公司和個人來說，是一個雙贏的事。

對于公司來說，復盤沉淀下來的經驗教訓是公司寶貴的組織資產，可以提高團隊的能力，可以為以后類似的項目提供參考，可以盡快讓新人成長起來等等。

對于個人來說，復盤才能帶來最大的提升。項目的結束不是真正的結束，復盤沉淀以后才是真正的結束，從項目中汲取沉淀經驗，才能提高自己的能力。

復盤在網上有很多模板，重要不是要找一個完美的模板，而是要動起來，要真正地開始復盤。

簡單介紹一個我使用的復盤方法：

以上就是我總結的PMP中可以遷移到產品工作中的一些方法，歡迎交流~

↘好文推薦：

“百億補貼”真的能拯救一切嗎？

美團外賣?|?離線數據倉庫建設實踐

以叮咚買菜為例，看生鮮電商的春天是否已經到來？

點個“在看”吧

總結

以上是生活随笔為你收集整理的产品经理学PMP，有必要吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。