第1講  程序員做項目管理的三個誤區(qū)

管理的誤區(qū)：1、事必躬親；2、追在別人屁股后面做監(jiān)工；3、拿著錘子，看哪里都是釘子

解決思路：

1、事必躬親，團隊長期發(fā)展，效率低下，自己也會越來越忙碌，瀕臨抓狂崩潰邊緣。

改變：想辦法影響他人把事情做好。

施加影響的三個層次：

（1）讓人知道要做（awareness）：學會授權，交代告知工作，知道要做。

（2）有動力做（desire）：講清楚為什么要做，為什么要現(xiàn)在做，獲取理解及認同，激發(fā)團隊的動力。

（3）有能力做（ability）：核心能力。（短期看，短期借調(diào)、內(nèi)部轉(zhuǎn)崗）（長期看，作為項目管理人員，要有意識地發(fā)現(xiàn)和投資團隊中有潛力的人，培訓幫助其發(fā)展）

2、趕鴨子上架，做監(jiān)工。

項目經(jīng)理，不是每天逐個人逐條事項的監(jiān)督，而是明確目標， 建立機制，并讓這個機制運轉(zhuǎn)起來，最終在項目組形成一種良性的秩序。

項目管理，最終是依靠流程和規(guī)則來約束大家的行為。當成熟的秩序在團隊中形成之后，從日?，嵤轮薪夥懦鰜淼捻椖拷?jīng)理，就可以集中精力去做愿景驅(qū)動、激勵團隊等更高層面的工作，真正做到變“趕”為“引”

3、完善改革，從項目和團隊當前的真實痛點出發(fā)，找到真正解決問題的方法和步驟。

首先，與項目中重要相關方加強溝通，理清前因后果。想想項目現(xiàn)階段到底最需要什么，對項目管理方法的成功推進至關重要。

反思：

在你的項目組中，時間、成本、質(zhì)量、范圍這幾個因素，到底哪個更重要？哪些是允許有一定調(diào)整空間的？

各個角色目前的痛點在哪兒？哪些是最現(xiàn)需要解決的？這些問題背后潛在的原因是什么 ？

團隊對于這個痛點的改進是否有真是需要？需求的迫切程度如何 ？

你的老板或項目發(fā)起人對于項目管理以及你本人的定位是怎樣的？關于這些問題與可能的改進，你是否與溝通過并達成了一致？

如果你打算引入新方法或工具，更適合用怎樣的路徑進行，是自上而下地全面推廣，還是自下而上一步步優(yōu)化呢？最有可能從哪個問題切入？

第2講  十大領域

整合管理：如何實現(xiàn)整體最優(yōu)？

1、干系人管理：如何管理干系人？（弄清楚哪些人是干系人；項目發(fā)起人對活動的預期效果是什么？比如增進團隊的協(xié)作，提升凝聚力等；各方的期望和述求？各方的影響？活動過程中的各類決定，誰來拍板？干系人要以怎么樣的方式參與？）

2、范圍管理：做什么？（確保圍繞著預期目標來設計相應的活動方案，然后進一步確定活動前、活動中、活動后分別要完成的具體工作）

3、進度管理：花多長時間？（規(guī)劃好階段性步驟，明確每個里程碑的目標成果和時間安排。）

如：第一階，啟動項目并確認概要方案設計；第二階段，規(guī)劃并落實人力和各項資源的投入；第三階段，確定具體的活動流程和詳細分工，完成活動前的各項準備工作；第四階段，做好活動當天現(xiàn)場的統(tǒng)籌和運作。

4、成本管理：花多大代價？（預算？全局視角去思考，如何更有效地管理項目的各項投入，以達到更加匹配目標的預期效果）5、質(zhì)量管理：達到什么要求？（確定成功的標準。現(xiàn)場參與人數(shù)、參與者滿意度、管理者的滿意度、對外傳播效果？以終為始，引入必要的流程和方法，以保障活動效果的達成）

6、資源管理：有多少內(nèi)部資源？（清楚內(nèi)部哪些資源可以使用。如：宣傳渠道、設計人員和經(jīng)費支持、哪些人可以作為支持活動志愿者？提供活動哪些必需品？）

7、采購管理：有多少還要買？（有哪些工作需要外部人員支持？經(jīng)費受限，是否可以通過交換資源的方式，來獲取更多的外部支持？）

8、溝通管理：如何管理溝通？（活動策劃團隊、執(zhí)行團隊分別通過什么方式進行項目溝通？與發(fā)起人和贊助方的溝通方式和頻率是怎樣的？你如何保持團隊內(nèi)外項目信息的高效傳遞，使用什么方式來同步進展？）

9、風險管理：如何應對風險？（提前做好系統(tǒng)性的風險識別，分等級制定應對策略。（如：天氣、場地、交通管制、贊助商經(jīng)費緊張、物料供應延期、公司內(nèi)外政策變化導致活動被喊停、業(yè)務壓力大導致兼職志愿者流失））

10、整合管理：如何實現(xiàn)整體最優(yōu)？（統(tǒng)籌全局，整合并協(xié)調(diào)各個環(huán)節(jié)的利益沖突和工作安排，在不斷變化的情境下，根據(jù)活動的目標“裁剪”初合適的過程、方法和工具，進行有效管理，從而達到全局的最優(yōu)效果）

第3講   五大過程組

PDCA循環(huán)，“戴明環(huán)”，規(guī)劃（plan），執(zhí)行（do），檢查（check），行動（act）

1、啟動過程組（千里之行，始于足下）

正式宣告一個新項目或新階段的開始，公開確認項目章程，包括明晰各方干系人的期望和訴求，設定愿望目標和重要里程碑，確定責任分工和溝通機制等。

2、規(guī)劃過程組（運籌帷幄，決勝千里）

把愿望目標轉(zhuǎn)化為可落地的行動方案和工作路線。

3、執(zhí)行過程組（言出必行，行之必果）

4、監(jiān)控過程組（審時度勢，沉著應變）

5、收尾過程組（慎終如始，則無敗事）

“趁熱”復盤！

互聯(lián)網(wǎng)項目管理存在的現(xiàn)象：項目與項目間的邊界相互交疊在一起，產(chǎn)品需求就如同海浪一樣，一波未平一波又起，大浪中夾雜小浪。整個產(chǎn)品的生命周期中不會停息，看不到哪里是盡頭，又哪來的啟動和收尾？

“保目標、助決策、提效能、促協(xié)作”

圍繞組織績效目標，定位核心的3~5件要事，即關鍵戰(zhàn)役，再把關鍵戰(zhàn)役進行規(guī)劃分解，拆到可交付可驗收的里程碑，最后落地到版本/迭代的工作安排中。

通過清晰而系統(tǒng)的反饋機制和平臺，把執(zhí)行中的進展狀態(tài)、變更、風險等集中呈現(xiàn)，以幫助管理者更好地進行優(yōu)化和調(diào)整。

提效能就是要去關注和消滅團隊中的低價值工作所引發(fā)的效能痛點。

促協(xié)作則是著眼于使用各種項目管理方法和工具，讓高價值工作者可以更好地合作。（比如，建立清晰有效的信息渠道和溝通機制，積極推動各角色達成共識，實現(xiàn)全局價值的最大化）

保目標、促決策是要打通從戰(zhàn)略到執(zhí)行的閉環(huán)，提效能、促協(xié)作則是打通上下游協(xié)同

第4講   識別項目中測四類干系人

1、“高利益-高權力”代表：項目發(fā)起人

2、“低利益-高權力”代表：職能經(jīng)理

3、“高利益-低權力”代表：項目組成員

4、“低利益-低權力”代表：外圍支持人員

深入了解干系人的核心述求（重點關注、預期等），約定好溝通頻率、方式和內(nèi)容，以便做好實時同步。

強烈的態(tài)度背后，一定反映了干系人對現(xiàn)狀的某種認知。只有真正地理解了對方的邏輯，才有可能進一步對其施加影響。

主導、支持（明確了解其期望和述求，有意識地創(chuàng)造更多的空間和機會，讓他們深度參與到這個項目的決策或創(chuàng)意環(huán)節(jié)，增強其主人翁意識）、中立、反對（建立信任，化解危機）

第5講  規(guī)劃：掃除計劃中的“延期地雷”

做計劃，是集體對焦的過程，是制定各個角色協(xié)同工作的基準。

雷區(qū)掃雷：

1、不夠具體（任務的集合）

給出時間節(jié)點，給出依據(jù)和來源，更有效地對焦。創(chuàng)建WBS，把項目工作按階段可交付成功分解成較小的、更易于管理的組成部分的過程。

2、不夠全面（只有任務列表，沒有識別關鍵資源和關鍵依賴，沒有考慮研發(fā)之外其他環(huán)節(jié)）

識別依賴并畫出關鍵路徑，即從目標角度對資源進行統(tǒng)籌思考。

3、不夠準確（定義理解不一致）

定義標準動作，定義完成標準。

常見時間節(jié)點標準：

需求/設計確認：執(zhí)行所需的需求稿或設計稿已經(jīng)完成，而且公開評審通過，團隊已經(jīng)準備好要編寫產(chǎn)品代碼了。或有些團隊會對需求稿或設計稿做一定的要求，比如把未處理的反饋意見數(shù)小于多少作為標準。

功能完成/提測：所有定義的功能都已經(jīng)完成（比如冒煙測試通過率高于90%），團隊已經(jīng)準備好將焦點轉(zhuǎn)移到質(zhì)量保證上，并將所有剩余問題都當做BUG來追蹤。一些質(zhì)量基礎比較好的團隊，也可以吧CI自動回歸用例集通過率、靜態(tài)代碼檢查分數(shù)、單元測試覆蓋率等，作為更加細節(jié)具體的完成標準。

里程碑完成：質(zhì)量已經(jīng)達到適當水平（如不存在P0及P1優(yōu)先級的bug），可以上線發(fā)布，或者可以開始下一個里程碑。

4、沒有共識

沒有達成共識的計劃，是不具備任何效力的，因此要達成共識并公開透明。周知成員

5、不夠即時

做計劃，謹慎的過程，但也是反復修正，漸進明細的過程，我們要對計劃進行持續(xù)地跟進與調(diào)整。更重要的是，每一次進行調(diào)整，都要確保項目中每個人知道當前的計劃是什么，調(diào)整計劃需要怎樣決策過程，都需要誰參與決策。

解決思路：五個標準動作

具體：對工作進行WBS分解

全面：識別依賴并畫出關鍵路徑

準確：盡早定義完成標準

共識：召開全員規(guī)劃會，對齊信息，達成共識；發(fā)郵件給干系人，正式告知。

即時：及時調(diào)整變更，并公開告知所有項目組成員

第6講  執(zhí)行：打造品質(zhì)，要從頭開始“閉環(huán)”

項目問題：需求和設計沒有經(jīng)過嚴格的把關，就匆忙投入開發(fā)；傳統(tǒng)研發(fā)的串聯(lián)的功能效果，只有等到上線才能看到和體驗到完整運行的產(chǎn)品；產(chǎn)品的提出，需要多輪的螺旋式迭代，不斷調(diào)整。

解決思路：構建系統(tǒng)能力，在產(chǎn)品研發(fā)整個過程中，建立起真正閉環(huán)反饋的產(chǎn)品驗證機制。

開環(huán)和閉環(huán)之間的關鍵差異，在于有沒有反饋環(huán)節(jié)，以及系統(tǒng)是否會根據(jù)反饋自動調(diào)節(jié)。

1、方案評審（OARP決策機制）

負責人（Owner）：負責給出方案，組織各方討論并推進做出最終的決定；

批準者（Approver）：最終批準者；

審核者（Reviewer）：負責人和批準者挑選出的審核人。審核者有負責對文檔進行討論分析，并提出反饋意見，負責人必須重視并給予回復；

參與者（Participant）：其他提供意見的人。參與者會收到文檔的相關信息，可以對相關問題作出反饋。

2、Bug Bash （BUG 大掃除）

Bug Bash ，最初來自微軟，是指在項目開發(fā)里程碑的末期（比如Beta版發(fā)布前），劃出一個專門的時間段，在這期間，所有參與項目的人員，集中全部精力一起來給項目找Bug，目的是從各個維度衡量和體驗產(chǎn)

品。

要點：

（1）時間：測試類的Bug Bash ，可以選擇在全面功能測試結(jié)束后，Bug趨于收斂的時間段開展；需求設計類的Bug Bash，一般會放在需求稿或設計稿完成后舉行。1~2H,提前排除所有干擾。

（2）地點：設立一個單獨的作戰(zhàn)室，鼓勵參與者自帶筆記本，讓他們盡可能集中精力做這一件事。同時，作戰(zhàn)室可以提供一些零食和飲料，讓活動更有氛圍；

（3）參與者：除了研發(fā)和測試，產(chǎn)品、設計、市場、運營、銷售等項目組不同角色的人群，都需要參與到這場活動中，這樣你就可以獲得更加豐富多維的視角；
現(xiàn)場安排：你可以把現(xiàn)場反饋的問題直接貼在白板上，或者通過電子白板，來滾動更新 Bug 或建議的排名情況。需要注意的是，營造互動的氛圍非常關鍵，如果因為空間受限，參與者做不到在同一個地點進行，你至少也要在通信群中實時更新排名情況的變化。
活動結(jié)束：在活動結(jié)束后，要直接公示 Bug 或建議數(shù)，現(xiàn)場給獎品，并發(fā)郵件通報全組。最后，在對 Bug 進行去重后，還要分類定級，確定哪些 Bug 是必須修的，哪些 Bug 是改了會更好的。另外，千萬不要忘記公示結(jié)果，明確修復計劃。
關于活動的組織方式，你可以加入更多游戲化的玩法，這些都是為了最大程度地調(diào)動團隊成員的參與熱情，讓問題在早期得到更好地暴露。你可以在一些重要版本中嘗試這樣的方法，與很多低效冗長的評審會相比，這個活動在避免返工方面，會有非常好的實戰(zhàn)效果。

3、冒煙用例評審

如果你是在完全沒有基礎的團隊中推行這個做法，可以先從測試人員記錄冒煙測試通過率開始。接著，你要收集相關數(shù)據(jù)，和你的團隊在回顧會上一起看看冒煙用例失敗所導致的后期返工成本，討論出一種更好的確保質(zhì)量的做法。在我直接管理的項目中，冒煙通過率的要求通常是 100%，你可以選擇從一個合適的起點開始，比如 80%，然后再一步步地逼近更好的提測質(zhì)量。

第7講  監(jiān)控：進展“巧”匯報，學會用數(shù)據(jù)說話

1、緊急匯報：直面問題有章法

緊急報告，是指在項目發(fā)生突發(fā)事件，或者提示重要風險狀態(tài)變化時的實時報告。

緊急報告模板：

（1）事件描述：購物車改造功能高延期風險；
（2）影響后果：由于此功能在項目的關鍵路徑上，很有可能會造成項目整體延期兩周；
（3）跟進分析：本期購物車改造功能，有部分調(diào)整涉及到底層訂單系統(tǒng)，里面有大量遺留代碼，已經(jīng)很久沒有人維護了。之前對此風險的評估不夠充分，改動風險很高，可能會影響全站訂單系統(tǒng)的穩(wěn)定性，具體影響仍需要詳細分析；
（4）響應措施：主程全力以赴做好技術評估，本周內(nèi)給出詳細任務評估時間表；與此同時，產(chǎn)品人員介入，調(diào)研規(guī)避老系統(tǒng)又能滿足需求的可行性，本周內(nèi)給出調(diào)研結(jié)論；
（5）所需支持：熟悉老系統(tǒng)的資深技術人員，以及紅牛一箱。
這份緊急報告提交以后，發(fā)起人第一時間就會關注到，項目組正面臨著非常棘手的問題，以及可能造成的影響和后果。同時，他也了解到，團隊正在試圖解決這個問題，目前的解決方案是什么，還需要什么樣的支持和幫助。當然，如果你能夠第一時間跟發(fā)起人當面溝通，效果會更好。

2、常規(guī)匯報：項目周報回答的三個問題

項目周報是向項目團隊和干系人溝通項目狀態(tài)的常用手段，要用簡要的方式呈現(xiàn)項目全貌，客觀地展示項目問題，推進問題解決。項目周報模版中，最必不可少的就是整體項目狀態(tài)評估、風險列表、項目概況及計劃變更情況。好的周報，應該讓大家對項目現(xiàn)狀的三個問題形成統(tǒng)一、清晰的整體認知。這份整體認知，可以讓平時扎在細節(jié)工作中的人，從全局視角來了解和看待整體，從而更好地完成自己的工作。
需要注意的是，一份周報的閱讀時間不應超過 5 分鐘。因此，在寫到進展和問題時，切忌事無巨細，只寫要點就夠了。周報不是為了表現(xiàn)工作量，更不是為了刷存在感，只說重點就夠了。
3、數(shù)據(jù)匯報：善用“透明”的力量

結(jié)合項目組中當前需要重點推進或改進的事項，選擇合適的數(shù)據(jù)和圖表去做“透明”。

如：jira中的圖表插件

第8講  收尾：項目復盤，小團隊也要持續(xù)改進

項目團隊有意識地向過去的行為經(jīng)驗學習。

決定復盤成功與否的關鍵，不在會議本身，而在于復盤會的一前一后兩個環(huán)節(jié)。認真做好一次復盤，每次復盤后聚焦一個改進點。

要點：

1、復盤會的基調(diào)設定：

反思，為找到問題的根源并改進而復盤

2、復盤會的會前準備：

梳理整個版本的歷程，包括項目或里程碑各項數(shù)據(jù)和信息、目標和達成結(jié)果、進度計劃、需求變更、質(zhì)量狀況等，這些客觀數(shù)據(jù)的總結(jié)。同時，還可以提前收集這個版本期間，團隊滿意度的問卷調(diào)查，為復盤會引入更多主觀的輸入?；蛞曨l

3、復盤會的簡易流程：

（3）在白板前逐條 review 大家的意見，共同發(fā)現(xiàn)問題，并有針對性地展開討論。

第9講  需求變更：化解程序員的“頭號噩夢”

 項目問題：“996”的元兇，之需求變更頻繁

解決思路： 

1、達成最小共識，變更時有代價的。（我們追求的是達成項目目標，而不是零變更）

約法三章：

第10講    風險管理：如何系統(tǒng)化應對風險？

項目問題：不確定的事件或條件，對項目目標造成影響

解決思路：系統(tǒng)化識別風險，根據(jù)風險概率和影響，召集項目成員完成風險登記冊及風險具體評估，制定相應的風險應對措施及應急預案，同時對冰山下的風險保持敏感。

 系統(tǒng)風險的識別：（識別出的風險越多，項目的風險越低）

風險識別的主體，應該包含 項目中的團隊成員在內(nèi)的各方干系人。組織中的每個層級，都必須有意識地積極識別，并有效管理風險。系統(tǒng)化的風險識別，是一個反復進行的過程，應該從構思階段開始，貫穿項目規(guī)劃和執(zhí)行的始終。

識別風險的主要輸出，即初始的風險登記冊。包括已識別的風險清單，以及潛在應對措施清單。對于已識別的每個風險，都要評估其概率和影響，并進行優(yōu)先排序。

冰山下的風險：

規(guī)避風險的原因：缺乏風險的溝通渠道；提出來也沒有用；老板會認為自己沒能力管好當前的項目

沒人反饋風險，不代表沒有風險。一個優(yōu)秀的項目經(jīng)理，必須是一個優(yōu)秀的“情報人員”，上至最高的項目發(fā)起人及組織得各層決策者。下至項目最邊緣的人群，比如外包、實習生、短期借調(diào)支持人員等，都要跟他們建立廣泛且深入的聯(lián)系。用一顆真誠交流的心，去關注項目組中的每個角色、每個成員的需求。理解他們的困難，愿意為他們提供發(fā)展的機會 ，幫助他們?nèi)カ@得更大的成功，僅此而已。

風險應對措施：對于發(fā)生概率很高的嚴重風險，一定要提前準備風險應對方案和危機應急預案。

在項目排期時，確保有相應的故障演練計劃，并且做好充分的準備。

通過周期性的風險審查，識別新的風險。

確定正確的風險觀：

（1）治未病，建立系統(tǒng)性保健機制。（事后不如事中控制，事中不如事前控制；致力于持續(xù)改善人與人之間的互動品質(zhì)，提升項目團隊的健康度；匿名的問卷收集或訪談，定期做一場坦誠布公的復盤會）

（2）積極管理致命風險。（挖掘出致命風險，把他們變成可見的，可談的；正視風險，不存僥幸心理；在項目的核心團隊中，周期性地梳理和同步風險狀態(tài)）

堅持在多個版本中反復使用，積累數(shù)據(jù)。

在互聯(lián)網(wǎng)領域，成功突圍者大多都是一路坎坷，從各種致命風險中爬出來的，堪稱九死一生。致命風險的存在，本身就是一種警醒。加速構建核心能力，不斷拓寬“護城河”，此案時最根本的應對之道。

第11講    質(zhì)量管理：一次把事情做對！

項目問題：產(chǎn)品完成質(zhì)量不好；bug多；技術債爆倉

解決思路：三方面入手。

1、質(zhì)量規(guī)劃，明確項目的質(zhì)量標準；

2、質(zhì)量分析，追根溯源，找到質(zhì)量差距的根本癥結(jié)；

3、質(zhì)量控制，在需求到發(fā)布的過程中，設置層層卡點來控制質(zhì)量。

關于技術債，定期積極主動還債。

關鍵要點：

質(zhì)量成本：事前防止失敗的一致性成本；事后處理失敗的非一致性成本。事后檢查處理的代價是最高的；預防高于檢查，預防錯誤的成本通常比在檢查中發(fā)現(xiàn)并糾正錯誤的成本低得多。

質(zhì)量規(guī)劃，明確標準。規(guī)劃質(zhì)量，是識別項目及產(chǎn)品的質(zhì)量要求和標準，并確定用哪些保障方法、改進措施來達到這些標準的過程。注意，在業(yè)務生命周期的不同階段，質(zhì)量標準應該是動態(tài)變化的。不同的項目對質(zhì)量的要求也相差甚遠，無法一概而論，因此，只能結(jié)合具體項目和項目階段的質(zhì)量訴求，對質(zhì)量的標準進行合理定義。聚焦項目的整體目標上，質(zhì)量作為目標的一部分，達到要求是最重要的，不需要追求質(zhì)量的無止境提升。質(zhì)量終究也是有代價的，是否夠用取決于項目目標和要求。

質(zhì)量分析，追根溯源。深入分析，定位問題，進而采取相應的措施進行改進和預防。

常用方法：

1、每月堅持開線上Bug分析會。召集產(chǎn)品、研發(fā)、測試，一期對過去一個月的線上問題，進行深入的根因分析，制定策略并推進落實。

2、持續(xù)進行內(nèi)部Bug分類。從不同維度分析Bug原因，可按照具體引入階段給Bug分類，比如需求不清、設計缺陷、邏輯錯誤、測試遺漏、變更引發(fā)的覆蓋升級、歷史遺留等，也可按照Bug類別分為功能問題、性能問題、界面問題、兼容性問題等。從數(shù)據(jù)統(tǒng)計上，就可以準確的知道，自己項目的質(zhì)量問題主要出在哪個環(huán)節(jié)，下一步要先規(guī)范代碼準入標準，還是加強需求評審， 以及哪些保障措施會更有效。

3、建立質(zhì)量大盤，拉通不同業(yè)務線或模塊的每月Bug趨勢，對齊千行代碼Bug率、Bug數(shù)/需求數(shù)的比率、Reopen Bug率等，對低于平均線下的業(yè)務線或模塊進行有針對性的原因分析。

質(zhì)量控制，層層卡點。

質(zhì)量控制及卡點行為，要結(jié)合項目質(zhì)量要求和團隊的質(zhì)量成熟度，一層一層地加強質(zhì)量把關和收口。

第12講   高效會議：項目中要開好哪些會？

項目問題：會多（項目經(jīng)理80%的時間都用在了溝通上，不是在開會，就是在開會的路上）；按框架開了所有的會，終覺流于形式，索然無味

解決思路：流水不腐戶樞不蠹，沒有什么東西是一成不變的，會議設計和流程需要根據(jù)項目各階段的情況做相應的調(diào)整。想清楚要開哪些會，不開哪些會，怎么把會開好。即：“斷舍離，堅持只開最有必要的會，開真正高效且產(chǎn)生決議的會（會而有議、議而有決，決而有行），做到借助會議做好群體溝通，從而讓大家看到有效的進展。”

 關鍵要點：（保障會議品質(zhì)）

1、明確會議邊界。（①明確會議主題、目的和參會人員范圍。②why what  how  ③兩確保：確保各部分的進展信息在會前統(tǒng)一提交，會議當場只說重要問題、風險及 需要支持的地方；確保會議當場嚴格圍繞主題開展，對偏離主題的討論，及時叫停！相關問題的主要決策人，對這個問題有責任的相關人員、負責執(zhí)行決議的人員是必須參與的）

2、建立會議規(guī)則。 （遲到紅包→拖堂紅包→輪流擔任“規(guī)則守護大使”→主持人判定違反會議規(guī)則者，成為下次會議的主持人）

3、做好會后跟進。（會后所有跟進事項，直接進任務系統(tǒng)，確保跟進到底）

第13講   故事案例（上）：新手上路，如何引入變化？

項目問題：發(fā)現(xiàn)問題，如何解決問題？

解決思路：選擇合適的時機，然后，找到因地制宜的解決方案，最后因人而異，采用不同的策略進行有效溝通?！疤鞎r地利人和”

關鍵要點：引入變化的發(fā)心。之所以要引入變化，不是因為你覺得這個方法好，解決了你的問題，而是要看團隊需要的是什么，干系人的痛點是什么。建立在信任的基礎上，站在對方的角度設身處地地思考問題。

“天時”即合適的時機。問題并不等同于時機，只有把問題和痛點關聯(lián)起來，才能形成一個好的時機。不能產(chǎn)生改進動力，只能說明，還沒有抓準痛點。

痛點，即必須及時解決的問題，包含著強烈的迫切感。判斷是否是痛點的標志，就是看這個問題，如果不解決，對方是否會很苦惱，很痛苦。

促發(fā)別人的行動，必須換位思考，去體會和抓住他的痛點。1、訪談法，直接問。2、觀察法。去觀察那些花他時間和精力最多，他反復強調(diào)卻又沒有很好 解決的問題，那些才是他真正的痛點。3、同理心和傾聽。變革早起，尋找早起支持者，圍繞著你想要引入的變化，擊中幾個重要干系人的痛點之后，時機到了。

引入變化的第二點“地利”，學會因地制宜。結(jié)合每個項目團隊的現(xiàn)狀，做好本地化的場景適配。創(chuàng)造一個最小阻力的落地方法，先快速地跑起來， 讓團隊感受到變化帶來的閉環(huán)成效。

“人和”。多聆聽彼此，充分理解，找到共同的出發(fā)點。在溝通時，你要因人而異，針對不同的人，采用不同的策略。判斷立場！把變化涉及到的干系人，按照角色和層級做個初始化分，思考下不同區(qū)域的人，會怎么看待這個變化帶給他的影響。找出更多積極因素。

在大范圍公布并引入變化之前，與關鍵角色進行一對一的溝通，最后，面向全員正式公開溝通。

例子：溝通延遲推行的每日站會變革。

第14講   故事案例（下）：小步快跑，小而美的敏捷

敏捷問題：簡單但并不好做（simple but not easy），掌握精髓？

敏捷的特點：小而美，體現(xiàn)在人、事、時間三個方面。1、人：拆分成小規(guī)模（5~7人）、跨職能的小團隊；2、事：拆分成一系列小而具體的交付物，按優(yōu)先級排序，增量交付；3、時間：拆分成固定大小的短迭代（1~4周），在每個迭代結(jié)束后，對可工作的產(chǎn)出進行演示。總體來說，就是用小團隊在小塊時間，做做出小塊的東西來，并且周期性地集成組裝。

常見痛點與解決思路：

1、發(fā)布時間不可控（快速地增量交付）

考慮實際背景，確定迭代周期；和相關方一塊做Sprint計劃及Review演示。

提早集成與測試，問題得以及時暴露，更快的反饋及應對；及時規(guī)避風險；快速響應變化，每個sprint都是潛在可交付的產(chǎn)品；

2、擺脫“接力綜合征”（從對抗走向協(xié)作）

寧愿選擇等待（每個人都等著上一環(huán)節(jié)的人把東西弄好送到自己面前來，才能開始工作）；角色間涇渭分明（每個人覺得，只要把自己分內(nèi)的事做完就行了。從而導致個角色之間有一定的對抗性，任何一件小事就可能造成沖突，最終大家都耗在那里，卻不能把焦點放在達成整體目標上）

雖然彼此分工，但作為一個team，有共同的sprint目標，相互協(xié)作，一起完成。“燃盡圖型項目進度模板”

3、需求理解不一致（面對面澄清及估算）

敏捷價值觀，“個體與交互>過程與工具”。

迭代計劃會思路：

（1）產(chǎn)品負責人向團隊和用戶代表，面對面地講解收集來的各方需求，最終明確需求的優(yōu)先級及驗證條件，也就是說，在迭代結(jié)束的Demo演示會上，我們要給用戶呈現(xiàn)什么。

（2）團隊估算。采用敏捷估算撲克的形式，由團隊成員共同估算結(jié)果，最后綜合得出這個迭代要交付哪些內(nèi)容。

團隊估算的過程，一個雙向互動的環(huán)節(jié)，可以幫助團隊和產(chǎn)品負責人共同加深對條目的理解。同時，產(chǎn)品負責人也會根據(jù)大家的反饋，及時修改條目，完善條目。

好處：需求探索更深入；估算結(jié)果更全面、細致；找到更優(yōu)的整體解決方案。

宗旨：圍繞項目中切實的痛點開展。

敏捷實踐的好處：

1、提升客戶體驗。

更低的延誤率；階段性可見的產(chǎn)出；更快的反饋、適應與調(diào)整

2、提升管理者體驗。

團隊自主運行，管理更輕松；變“趕”為“引”，為共同目標奮斗

3、提升團隊體驗

更高的生產(chǎn)力；更強的責任感、主人翁意識。

快速可靠交付，用戶價值驅(qū)動，持續(xù)自發(fā)改進。

第15講  工具方法回顧串講：手把手帶你高效管理

1、viso 甘特圖  里程碑圖

2、power

3、devops

“四步學習法”

 1、破除“魔”障

留心你的定義，對失敗的定義，對困難的定義，對問題的定義，對理想環(huán)境的定義......這些定義決定了你的體驗，以及你下一步的行動。別讓你的 定義， 限制了你的可能性。破除“魔”障，向前進。

如果你認為，只有在一線城市的所謂一線大公司，在沒有那么多復雜關系的“理想”環(huán)境里，才能開展工作，那么，你將永遠無法真正地開始。即便你有一天到了大廠，你對問題的錯誤定義，也會讓你不斷地看到各式各樣的問題，遭遇各種各樣的困難。

2、每次一小步

3、先找找“感覺”

學習某些知識時，產(chǎn)生了共鳴，接下來，就要多看你幾遍，多聽 幾遍，把那種事情已然成真的喜悅和滿足感，刻錄在心中。然后，試著和自己的經(jīng)驗相關聯(lián)，在大腦中想象自己已經(jīng)做到這些的樣子，越清晰越好。最后，把這個視覺化的影像記錄下來。

4、“足”量的刻意練習    

 通過行動，反復加深神經(jīng)系統(tǒng)中的凹痕，直到新的行為，鞏固成為新的模式。

學而時習之，不亦說乎。

第16講  向上溝通：你必須要注意的三個誤區(qū)

誤區(qū)1：所有問題，都自己扛!

邁過自己內(nèi)心的那道坎，主動大膽地發(fā)起溝通，是做好向上溝通的第一步。

不管通過什么途徑，我們必須時刻從大局出發(fā)，讓這些項目關鍵信息，及時有效地流動，保障及時有效地決策。

誤區(qū)2：只知道吐槽，不知道爭取

情景：當團隊和管理層之間關系緊張時，很多項目經(jīng)理會特別容易掉進一個誤區(qū)，那就是，盡自己的努力幫團隊解決問題，臟活累活都自己來?！袄虾萌恕保痢皧A心餅”

改變這種局面，就是把“夾心餅”變成“連接器”，成為高層干系人與團隊之間緊密聯(lián)系的紐帶。

作為項目經(jīng)理，當需要高層重視和支持的事件發(fā)生時，該出手時就得出手，引發(fā)高層關注，把團隊最一手的相關動態(tài)信息及時傳遞給他，爭取高層必要的支持，而不是跟著團隊一起吐槽。

誤區(qū)3：抓不住重點，給不出方案

“團隊現(xiàn)在加班很嚴重”“團隊任務不及時更新”“某某工作不主動，總是遲到”·······如果你只是這樣反應問題，只是說這里不好，那里不好，卻沒有告訴他，為什么要關注這個問題的話，你的意見不僅不會得到重視，甚至還會產(chǎn)生反效果。

高層干系人的時間往往很寶貴，所以，在溝通之前，做好 充分的準備，是必不可少的。你要反應的問題，與高層干系人的核心關注點是否相匹配，這是能否引起其關注并進一步行動的關鍵所在。在向高層干系人提問題的同時，一定要給他一個明確的“點”，讓他知道，為什么要關注這個問題。

適時地給出“行動點”，眼前的解決方案，針對提出的問題，列舉可能的解決方案！給出前進一小步的解決方案，給領導，也給自己，一個小小的行動暗示。

找到“核心關注點”；用數(shù)據(jù)和事實來作“論點”；給出一個小小的“行動點”

第17講  跨部門溝通：如何巧借力？怎么讓不歸你管的人積極配合你？

情景:項目中出現(xiàn)的沖突，“部門 墻”，跨部門溝通，直線上升的復雜度。不是“自己人”的困境。沖突的起源，始于“邊界”

應對措施：約法三章、先說清楚

1、建立君子協(xié)定

在合作前，跟對方建立合約，明確合作目標、合作事項、雙方各自的需求和責任、時間進度要求、風險及責任人。雙方責任人進行郵件確認，公開做出正式的承諾。

在剛開始合作時，建立穩(wěn)定的預期是關鍵，雙方責任及進度要求，必須要得到公開確認。

承諾越公開，越正式，日后對雙方的約束效力就越大。

2、建立機制

合作建立后，建立常規(guī)的溝通機制來維持推動。比如：項目信息開放共享，每周在固定的時間開碰頭會，雙方相關人員交流工作進展及風險情況。更進一步的話，還可以借助標準得任務管理和文檔管理工具，對項目任務和文檔做到統(tǒng)一的流程化管理，在過程中確保及時地跟進檢查。

確認是否存在“三不管”地帶？每個依賴任務的職責是否明確，責任是否具體到個人？

3、解決問題

通過周期檢查，及時發(fā)現(xiàn)問題。

“找他們領導”，王炸牌？！不到特別時刻，不要隨便拿出來用。在找領導之前，建議你自己先摸清楚狀況，盡快啟動風險應對機制，確定問題處理方案，比如改變方案，調(diào)整時間、增加資源、減少范圍等。

另外，你要把問題和相應的決議結(jié)果抄送給雙方的負責人，讓雙方清楚問題對整體項目的影響及調(diào)整方案。同時，你還要明確的是，今后要采取哪些預防錯是你，以避免問題的再次發(fā)生。

情景：兩邊領導達成正式約定，但不是每個牽涉進去的協(xié)作方都會立馬配合。

原因：這個部門的KPI早已定義好了，雙方約定確定，但對之前的KPI并無影響，故新增的工作，要額外投入人去做。因此，他們非常擔心，雖然增加了工作量，但產(chǎn)出卻不受領導的重視，類似這種會影響合作落地的根本機制問題，就需要引入雙方領導，來一起研究解決方案。

如，在雙方績效考核指標中，加入跨部門利益的指標，來強化這種目標和利益的捆綁，讓雙方真正把勁兒往一處使。

第18講  向下溝通（上）：無權無勢，他們不聽你的怎么辦？

第19講  向下溝通（下）：無權無勢，他們不聽你的怎么辦？

第20講  進階之路：項目經(jīng)理預備戰(zhàn)之PMP認證