喜馬拉雅音頻
http://m.ximalaya.com/album/37199907
第0章 PMP 答題套路總結
PMP 正式考試有 200 道試題而且都是情景題，和大家平時的模擬題還是非常類似的，題干中會列出一些項目
情況，然后問項目經(jīng)理應該怎么做？這里的怎么做有時也分幾種情況，比如現(xiàn)在應該怎么做？事先應該怎么
做？審題時這一定要看清楚。還有一些題干可能會比較長，實在讀不懂的話就看最后一句話，根據(jù)最后一句話
來做答。
關于如何使用此套路的個人小建議？
套路就是讀起來感覺很有道理，再去答題時就忘記了。只有錯幾次或者類似的題強化多做幾遍才能慢慢吸收。
小建議：
1)整理平時的模擬題，變更錯的多的就把變更的題單獨拿出來
2)問題解決錯的多的就把相關的題也拿出來，對著流程多去理解
3)然后再去刷兩遍，強化對流程、套路的理解
關于題干：
重點是情景題的題干，不要加戲，不要腦補太多場景
----------------------------------------------------------------------------------------
可以總結的套路有很多，但有時候太多了反而讓我們無法選擇，我們重點講以下 10 種情況：
1. 風險的處理流程，我們先來了解一下什么是風險，首先是沒有發(fā)生的，然后是具有不確定性。 當題干中出現(xiàn)“可能”，“也許”，“含糊不清”，“將”，“擔憂”，“擔心”等詞語時我們就需要考慮是否與風險相關。
結合選項根據(jù)風險的處理流程來做答，識別到了風險，
第一步先通過更新風險登記冊將風險記錄下來。
第二步分析影響，如定性，定量風險分析。
第三步制定風險應對策略。
第四步實施風險應對策略，也要注意殘余風險和次生風險。
第五步做好風險再評估以監(jiān)督是否有其他新風險等
2. 問題的處理流程和風險類似，發(fā)現(xiàn)問題之后，先記錄到問題日志中，然后分析問題，找解決方案，最后經(jīng)驗教訓總結，需要注意的問題日志包含的內容：
問題類型，問題提出者和提出時間，問題描述，問題優(yōu)先級，然后是最重要的由誰負責解決問題，目標解決日期，問題狀態(tài)，最終的解決情況。其實很多試題都可以歸類到問題處理，一定需要注意的是不能馬上實施解決方案，優(yōu)先按問題的處理流程來找合適的選項。
記錄問題-分析問題找根本原因-生成可能的解決方案-選擇最佳解決方案-執(zhí)行解決方案-驗證解決方案-經(jīng)驗教訓總結。
3. 團隊成員缺乏技能需要參加培訓，如果是組織缺乏某些技能，可能就需要找供應商了。和供應商之間的爭議，首選參考合同。
4. 審題時一定注意題干中提到的項目階段，比如項目剛剛開始，啟動，規(guī)劃階段，基準評審會議等。不同的階段處理問題的方式也是不同的。
5. 這里再提一下商業(yè)論證，PMBOK 第六版中有說是發(fā)起人需要制定商業(yè)論證，但也有說某些組織可能還要求項目經(jīng)理管理或協(xié)助項目的商業(yè)分析、商業(yè)論證的制定。所以項目經(jīng)理也是可以制定商業(yè)論證的。
6. 團隊成員沖突處理，假如意見分歧成為負面因素，應該首先由項目團隊成員負責解決；如果沖突升級，項目經(jīng)理應提供協(xié)助，促成滿意的解決方案，采用直接和合作的方式，盡早并且通常在私下處理沖突。如果破壞性沖突繼續(xù)存在，則可使用正式程序，包括采取懲戒措施。
7. 變更的處理流程說怎么重要都不為過，可能考試完出來就有一種感覺，怎么全是考變更啊，因為這部分的比重實在太大了。所以這部分必須復習好。
變更的流程
1）相關方提交 Issue, Create 變更請求（正式書面記錄到變更日志中）
2）PM 評估變更的影響
3）尋找解決方案
4）提交 Submit 變更請求給 CCB 批準
5）如果批準了更新項目管理計劃/項目文件 如果否決了更新變更日志
6）通知受變更影響的相關方
7）項目團隊執(zhí)行批準的變更
8）跟蹤確認變更的實施情況
8. 獲取資源的方式，首先是和職能經(jīng)理協(xié)商，然后是執(zhí)行組織中的其他項目管理團隊，最后是外部組織和供應商。
9. 不得不提一下敏捷，很可能是大家容易忽視的知識點?，F(xiàn)在的考試中敏捷相關的試題還是有幾道的，不同的試卷可能不太一樣，通常會有 5 道左右吧，（敏捷試題的常見關鍵詞：敏捷、迭代、Scrum、用戶故事、產品負責人、沖刺評審、回顧總結會議、每日站會）
提到敏捷必須說一下敏捷的宣言，總共是四條，
1.個體和互動高于流程和工具。
2.可工作的軟件高于詳盡的文檔。
3.客戶合作高于合同談判。
4.響應變化高于遵循計劃。
另外敏捷中常見的一些概念
每日站會用來同步大家的工作安排,通常不超過 15 分鐘，每個人講一下昨天做了什么，今天計劃做什么，遇到了什么問題。但每日站會不會深入討論問題，如有需要在每日站會后再安排一個會議來討論。
風險登記冊在敏捷項目里也沒有，通常是將風險信息展示在信息發(fā)射源上。信息發(fā)射源的常見形式：
用戶故事地圖、燃盡圖、燃起圖，通常展示在“交通要道”以增加曝光率，使得干系人可以快速了解項目狀態(tài)。迭代燃盡圖這類圖用于追蹤迭代未完項中尚待完成的工作。而燃起圖則展示完成的工作。
在敏捷項目里，項目經(jīng)理（或敏捷教練）主要工作側重于部署敏捷流程、移除敏捷障礙、促進溝通。
問題日志在敏捷項目里并不推薦，敏捷減少文檔更新工作，鼓勵通過面對面口頭溝通快速解決問題。一次迭代結束后，應在回顧總結會議上就剛剛結束的迭代總結經(jīng)驗教訓，避免類似情況在后續(xù)工作中重復發(fā)生。
敏捷項目中，產品范圍主要由產品負責人決定，工作量由團隊成員估算。敏捷項目的任何時間點，任何人都可以提出變更請求。產品負責人對其重要性和優(yōu)先級進行評估，并加入到產品代辦事項中。在迭代開始的計劃階段，團隊可以根據(jù)產品代辦列表中的優(yōu)先級判斷是否將其納入這次迭代。
敏捷變更管理沒有 CCB，但有變更控制程序。敏捷變更首先 PO（產品負責人）排列優(yōu)先級，確定對客戶有價值，然后與團隊商量，要求估算影響，在當前時間和人力的情況下能否工作。重點要和團隊達成一致和信息分享。
10. 收尾的流程，合同收尾 -- 財務收尾 -- 行政收尾（移交、收集記錄、審計、總結、歸檔）-- 吃飯安撫或慶祝
-- 解散團隊 -- 遣散團隊之前要執(zhí)行經(jīng)驗教訓總結和慶祝。
