在不少公司，其實產品經理也需要做項目管理的工作（畢竟沒有設置專門的產品崗）。那具體怎么做呢？本文作者分享了項目管理的三個核心動作：啟動、推進和復盤，希望能幫到大家。

項目管理的核心在于三個關鍵動作：啟動、推進和復盤。這三個步驟貫穿項目始終，幫助團隊明確目標、統一行動，并從經驗中學習成長。

1. 啟動：項目的生命起點。它涉及目標方向的共識。在團隊內部明確告知項目目標，確保每個人都理解并認同目標。
2. 推進：流程和方法的共識，確保團隊在執行過程中達成對流程和方法的共識，確保各項工作順利進行。
3. 復盤：團隊問題的共識。對項目過程中遇到的問題進行總結，將問題轉化為經驗，幫助團隊在未來的工作中更加高效。團隊需要通過項目來不斷磨合，適應彼此的工作方式。

01 準備一場高質量的項目啟動會

目的是為了達成項目目標與方向的共識。在啟動會上，需要詳細講解以下五個要點：

1.為什么要做——背景：解釋項目發起的背景和必要性，包括市場環境、用戶需求等，，讓團隊成員明白項目的緊迫性和重要性。
2.具體怎么做——規劃：詳細介紹項目的實施步驟和時間表，確保每個人都知道自己的職責和任務。
3.有誰參與——人員：明確團隊成員及其角色，確保每個人都了解自己的責任和任務分配。
4.協作方式——流程：規定項目的協作流程和溝通機制，確保團隊成員能夠高效協作。
5.馬上做什么——執行：確定啟動會后的立即行動計劃，確保每個人都知道接下來要做什么。

對于大項目，啟動會是必不可少的，而對于小項目，可以根據實際情況決定是否召開。無論大小，啟動會都應該簡潔明了，且內容充實。

成熟業務的項目啟動會

對于成熟的業務項目，啟動會的目的主要是為了獲得共識。需要注意以下幾點：

1. 生動講解：大家做成熟項目有時候很麻木，覺得很重要或者不重要。所以要有理有據，聲情并茂，讓團隊成員感受到項目的緊迫性和重要性。
2. 清晰規劃：明確項目的里程碑和驗證標準，確保項目目標可量化、可衡量，有助于團隊成員理解項目的關鍵節點。
3. 詳盡資源：列出項目所需的所有資源和支持方，并通過郵件等形式進行確認。并確保所有相關方都清楚各自的角色和責任。
4. 重塑協作：如果原有的工作方式存在問題，需要重新調整團隊協作方式，增強團隊凝聚力。例如，可以通過定期的茶話會等方式加強團隊成員之間的溝通和信任。

從0到1的項目啟動會

相比于成熟產品的啟動會，時間可能會很長，有時候2小時-5小時，因為大家對于這個項目的認可度很低，有很多的質疑點。

對于從0到1的新項目，啟動會的核心目的是讓團隊成員意識到項目的獨特價值和緊迫性。需要注意以下幾點：

1. 詳細闡述背景：花費大量時間闡述項目背景，包括用戶痛點、市場機會、競爭優勢等，讓團隊成員理解項目的必要性。項目前期變化很快是非常正常的，團隊成員可能不這么認為，就會覺得很痛苦，要做好大家的心態安撫。
2. 明確協作方式：新團隊尤其需要明確協作方式，確保團隊成員能夠協同工作。明確的協作方式有助于團隊成員更好地配合。
3. 提前準備QA：提前準備常見問題的答案，減少團隊成員的疑慮。準備好正能量的內容，減少負面的信息，確保團隊成員對項目的信心。

02 Scrum敏捷開發：如何構建高效的協作機制

在快速變化的商業環境中，敏捷開發方法因其靈活性和響應速度而受到歡迎。

Scrum作為一種敏捷框架，通過一系列的儀式活動來促進團隊內部的有效協作，特別強調會議制度的作用，以優化團隊協作，提高項目交付的質量和速度。

迭代計劃會（2周1次）：設定清晰目標

Scrum框架中的關鍵部分，旨在為接下來的迭代周期設定明確的目標。

這種會議相較于傳統的單月迭代方式更為高效，例如美團采用了雙周迭代會議，這種方法通過提高業務迭代效率，顯著提升了業務產出。

一個月內完成兩個版本的交付，使得每年可以交付多達20-24個版本。同時也合理化了人力資源的分配，保證了各個角色的持續產出，使得版本交付周期縮短至5.5周。

在會議之前，Product Owner需要準備一份按優先級排序的需求列表，這份列表應該已經過評審或與研發團隊達成一致。

• 上半場：通常由測試人員對需求進行講解，以確保所有團隊成員對需求有共同的理解。同時，研發和測試共同預估工時、確定需求的優先級達成 Sprint Backlog(已評審的內容)。
• 下半場：開始sprint、進行子任務拆解和排期，明確Sprint的需求范圍和優先級，確定發布版本的內容和時間節點，鼓勵團隊做出合理的承諾。

需要注意的是：

1）子任務是否被充分拆分，涵蓋開發、聯調、測試準備、自測等各項任務？

2）每個研發人員的排期是否既充實又不沖突？

迭代評審會/成果展示會（2周1次）：提升團隊成就感

通常由研發或測試人員展示上一個Sprint發布的內容。

這種會議有助于提升團隊成員的成就感，特別是當有數據總結時，更能直觀地看到工作的成效。如果有運營職能的同事參與，效果會更好，因為他們可以從市場反饋的角度提供有價值的見解。

迭代回顧會/總結得失/(2周1次)：持續改進

團隊成員共同反思過去Sprint的表現，討論成功之處和需要改進的地方。產品、研發和測試團隊都會在這個環節中發表自己的感言，這對于促進團隊的成長和持續改進至關重要。

每日站會（1天1次）：同步具體進度和困難

一個至關重要的儀式，它不僅幫助團隊了解項目的具體進度和困難，還能夠有效地避免拖延現象。由于團隊成員在日常工作中可能會遇到各種問題，有些成員可能因為害羞或擔心批評而不愿意在團隊中分享這些問題，因此每日站會提供了一個安全的環境，讓大家可以公開討論遇到的障礙。

執行的步驟可參考：

1）確定站立會時間和地點、參會人員

首先，確定站立會的具體時間和地點，并通知所有參會人員。一旦時間確定，所有成員都應在規定時間內到場。若有成員因特殊原因無法參加，需提前告知，并將自己的工作進度和計劃反饋給Scrum Master。

2）會前準備

每位參會者應在會議開始前10分鐘更新項目管理工具（如Jira、飛書項目、teambition等工具）上的需求、子任務和缺陷狀態，準備好會議上的發言內容。主要內容包括：

• 更新需求、子任務、缺陷的狀態流轉
• 填寫子任務工時
• 添加新的需求或子任務
• 移除當前Sprint中的需求或子任務

3）會議進行中

1. Scrum Master先確定參會人員是否全部到齊，到齊后宣布站會開始。

2. Scrum Master 審查線上BUG情況。

3. Scrum Master從右往左遍歷面板上的需求，每個需求讓相關人陳述進度和計劃、遇到的問題。

4. 參與人開始表述需求和任務的進度和計劃，同時，參與人自行移動和更新面板，包括需求、子任務狀態變更，新增需求等，同時更新需求、子任務的狀態標識。

5. 在參與者都發言完畢后，Scrum Master先詢問對于這個需求大家是否還有需要補充和不明確的地方。

6. Scrum Master需要向參與者確認需求、子任務的發布上線時間和風險情況，并引導參與者思考是否能按時完成需求的發布上線。

7. 重復執行步驟3-6，直至面板上所有需求全部討論完畢。

8. Scrum Master詢問眾人是否還有沒有在面板上的事項需要說明。

9. Scrum Master對進度和站立會的執行進行總結。

注意事項：

1. 準時參加，不遲到。

2. 不要超出限制時間（站立會時間15min）。

3. 不要討論技術問題。

4. 不要轉變會議話題。

5. 不要在沒有準備的情況下參加。

6. Scrum Master 不要替團隊成員移動任務卡片，不要替團隊更新燃盡圖。

7. 團隊成員不要向 Scrum Master 或管理層人員報告。

8. 如果不能出席會議，需要通知團隊，并找一名代表參加或提前同步進度。

9. 有需求置換需要當場填寫需求/子任務，并貼在面板上。

陳述規范：

針對特定需求，陳述格式如下：

1. 今天的工作完成情況，如果沒有完成，原因是什么？

2. 明天的目標是什么？是否有可能遇到困難，需要誰的幫助？
對于晨會，則改為：

1. 昨天的工作完成情況，如果沒有完成，原因是什么？

2. 今天的目標是什么？是否有可能遇到困難，需要誰的幫助？

成長期的團隊可以通過Scrum Master提問的方式，形成固定的匯報模式，避免討論，培養良好的習慣。而在成熟的團隊中，每個成員應按照固定的模式進行匯報。任何需要深入討論的問題都應在站會后由Leader協調或成員間私下解決。

對應的線上看板使用：

看板分為多個泳道，每個泳道代表不同的工作狀態，如：

• 未開始：產品經理、研發leader認為有價值的需求，隨時可以進入需求設計階段的需求；
• 產品設計中：正在進行需求設計的需求（包括UI、UE）；
• 評審中：等待評審的需求。
• 待開發：需求已經設計完成，并且在迭代會上通過需求評審的需求；
• 開發中-需求：迭代會確定本迭代需要完成的需求；
• 開發中-TC：需求的測試用例編寫子任務；
• 開發中-前端：需求的前端開發子任務；
• 開發中-后端：需求的后端開發子任務，包括AI\BI任務；
• 開發中-其他：需求的其他角色開發子任務；
• 待測試：已完成開發的子任務和已完成聯調、自測的需求；
• 測試中：測試中的需求；
• 待產品驗收：等待產品確認的需求
• 待上線：等待發布的測試通過的需求
• 已完成/已上線：發布完成的需求和子任務；

不同角色關注不同的泳道，如：

1. 產品經理：主要關注【未開始】、【產品設計中】、【評審中】、【待開發】

2. 研發人員：主要關注【開發中】、【待測試】

3. 測試人員：主要關注【開發中】、【測試中】、【待產品驗收】、【待上線】、【已完成/已上線】

線下的物理看板說明：

使用不同顏色的貼紙區分不同類型的任務：

1. 需求：使用粉紅色貼紙，需要標明需求概述、預計發布時間

2. TC任務：使用黃色貼紙，需要標明任務概述和負責人、預計結束時間

3. 前端任務：使用綠色貼紙，需要標明任務概述和負責人、預計結束時間

4. 后端任務：使用藍色貼紙，需要標明任務概述和負責人、預計結束時間

5. 客戶端或者其他角色的任務：使用棕色貼紙，需要標明任務概述和負責人、預計結束時間

狀態標識說明：

1. 旗幟：用以標識需求的風險狀態，紅色表示進度落后預期，黃色表示進度正常

2. 勾叉：用以標識子任務的風險狀態，叉表示進度落后預期，勾表示進度正常

線上bug review：快速響應與修復

在敏捷開發中，Bug管理和會議效率是確保項目順利推進的關鍵因素。接下來，我們來探討如何通過優化線上Bug Review和其他會議流程來提升團隊的整體表現。

站會負責人需要在每日站會中維護本組的Bug篩選器，以便快速定位并處理Bug。篩選器應包含以下內容：

1. 昨日解決的工單（通過“解決日期”字段篩選）。
2. 本組成員（研發、產品、測試）尚未解決的工單（通過“解決結果”字段選擇“未解決”）。

每日站會內容：

在每日站會中，團隊需要重點關注以下兩個方面：

1. 逐個查看昨日解決的工單，進入工單頁面，由修復人講解“研發分析”，包括產生原因、修復方法和改進措施等。這有助于團隊成員學習和預防類似問題的再次發生。
2. 討論本組未解決的Bug工單，制定修復計劃，確保工單不會超期。通過這種方式，可以及時發現并解決潛在的技術難題。

業務組周會：確保團隊協同與目標一致

定期的周會對于確保團隊成員了解項目的整體進度和各自職責至關重要。特別是在多項目并行的情況下，有效的周會可以幫助團隊避免資源浪費和重復工作，提高協同效率。

每周召開一次業務組周會，明確本周的重點工作和下周的核心目標。會議內容應包括但不限于以下幾個方面：

1. 上周待辦跟進：回顧上周周會確定的待辦事項，檢查完成情況，并同步公司產研周會的重點內容。
2. 重點數據分享：分享整體營收、重點客戶的營收情況以及重要產品特性的活躍數據。這有助于團隊了解業務的整體表現和發展趨勢。
3. 季度OKR進展：同步季度OKR的進展情況，指出哪些目標進展順利，哪些存在困難，并討論解決方案。
4. 產品和業務分享：介紹內部新產品和外部競爭產品的情況，以及市場側的需求和趨勢。這有助于團隊保持市場敏感度，并從中汲取靈感。
5. 制度流程宣導：傳達公司最新的制度、流程及要求，確保團隊成員了解并遵守相關規定。
6. 本周待辦：確定本周需要完成的任務，并給出大致的完成時間。

需求評審會：確保需求清晰

在需求理解不清晰時尤為重要。它幫助團隊成員找到重點和難點，明確需求，并討論實現的可行性。

需求評審可以在需求設計完成后隨時召開，但進入本迭代的需求必須在迭代啟動之前完成評審。評審過程中，研發團隊要充分發表意見，尤其是提出反面意見，以便全面評估需求的可行性和潛在風險。

上線會：提升團隊信心

確保上線前的各項準備工作就緒，提升團隊的信心。在會上，團隊成員需要同步上線的重點事項，確保相互支持，并提前做好上線后的準備工作，如在線客服、客戶服務等。這樣可以減少上線時可能出現的問題，提高用戶體驗。

會議指導原則

為了確保會議的高效性，我們需要遵循以下基本原則：

原則一：不開無效會議

1. 必要性審查：每次開會前都要問自己，這次會議是否真的必要？如果可以用一兩句話解釋清楚，或者可以通過郵件或群聊傳達的信息，就不必召開會議。
2. 取消低效會議：取消那些沒有充分準備、漫無目的或只是為了同步信息的會議，改用郵件或群聊等方式進行。

原則二：充分的會前準備

1）明確會議目的：在會前和參會人溝通清楚會議相關信息并達成一致后再拉會議日程。

2）確定會議類型：根據會議的性質（解決問題、決策執行、頭腦風暴、信息同步或考核成果）來組織討論。

3）選定參會人員：

• 需要決策的會一定要邀請擁有決策權的人參加。
• 控制參會人數。參會人員必須與議題執行相關，限制在最關鍵的人之間。
• “禮貌參會者”—知會自選、紀要必達。

4）確定會議的基本信息：

• 確定召開時間、會議所需時間：會議時間控制在1小時內。
• 確定會議地點：公司（會議室）、非公司（午餐、咖啡廳等）。
• 建會議日程：使用企業IM中的日歷。
• 確定會議的形式：線上、線下、線上+線下。

5）制定明確的議程，令會議高度系統化和緊湊：

• 怎樣順序的討論最可能達成我們的會議目的？
• 如何盡可能開短會？
• 參會人員需要在開會前多久看到會議議程？

6）制定會議規則

• 參會人必須準時到會，有事提前半天向會議組織者請假。
• 會議現場不接電話，不用通訊設備回復消息。
• 如果保密項目，參會人員需要對會議內容進行保密。
• 未盡重要事宜約定列入下一次會議議程。
• 共性問題有針對性的解決；不是共性的，則可以略過，與提出者在會后單獨解決或者召開專題討論會。
• 討論不務虛、不討論細節、不抱怨訴苦、不搞一言堂、不跑題。
• 限制參會人員的發言時間。
• 嚴格遵守時間。
• 參會人都需要發言，必須對會議結論表態。
• 會后的執行事項定義的責任人必須是參會人員。
• 會上已達成一致的事項，會后再反對不作數。
• 會議遺留事項做閉環跟進，若責任人超時1天未解決也未反饋則需要提前說明。
• 會議材料詳備且事先送達，倡導用在線文檔推進會議。
• 制定具體準備人員準備會議材料，建立會議日程時同步發出。
• 提倡會議前15分鐘，所有人先閱讀，評論自己的疑問。
• 提倡針對文檔內的評論進行逐條探討，當場解決問題，會后明確下一步行動和預期時間。

7）會前做好設備調試和材料準備工作：

• 會議主持人提前5分鐘到會議室做會前準備工作，并在會前2分鐘發起線上視頻會議。
• 若會議延遲開始或者臨時更改會議時間，會議組織者需要在會前10分鐘及時告知參會人員

原則三：一定要主持會議

在會議的實際進展中，作為會議的組織方，我們需要明確參會人的角色，讓每位參與者都能高度投入。通過有效的主持技巧，引導討論沿著理想的路徑推進，真正解決問題，形成方案與共識，并確保會議達成一致意見后能夠按約定執行。

在參會人員中，每個人都應該有明確的角色，并履行各自職責。常見的角色類型包括：參會人員、主持人、記錄人和決策者。

參會人員

作為參會人員，在會議中的主要職責是：

1. 提供信息：分享必要的知識和信息。
2. 積極參與：積極發表意見、建議，并參與討論和表態。

主持人

作為主持人，有著流程管理的會議功能，其職責一般包含：

1. 開場介紹：明確會議目的、議程、時間及規則。
2. 協調討論：確保會議舉行、嚴格遵循會議議程，沒有被任何人主導。并且確保討論緊扣議題，避免偏離主題或陷入爭論。
3. 引導總結：在具體節點控制討論，以確保所有有效意見均得到表達。確保每個環節有序進行，并在會議結束時進行總結。
4. 時間控制：嚴格控制每個人的發言時間，確保會議按時結束。會議結束時間一到，馬上結束會議。
5. 執行事項：明確會議中的執行事項，并指定責任人及完成時間。在會上直接確定執行事項落到責任人并明確截止時間，并再次同步執行事項下一步動作，確保全體參會人員都認可下一步工作安排。

會議記錄者

作為記錄人，有著信息管理的會議功能，其一般職責包含：

1. 記錄內容：詳細記錄會議討論的內容、達成的共識及后續行動安排。
2. 分工明確：對會中達成一致的執行事項進行明確分工（將各問題按區域分類、確定完成時間、執行責任人，以便更好的執行閉環）。
3. 整理紀要：按主次整理會議紀要，確保信息準確無誤，并在會后12小時內通過郵件或即時通信工具發送給所有相關方，保證信息透明。

決策者

作為決策者，對會議最終能否達成指導后續工作的共識起著至關重要的作用，其一般職責包含：

1. 參與決策：確保所有利益相關方參與決策過程。
2. 聽取意見：認真傾聽各方意見，并在最后發言進行總結。
3. 明確標準：列出決策的標準，指導集體作出最佳決策。
4. 歸納決策：明確歸納所作決定及其理由，并在必要時解決爭議。

（4）會議跟蹤與結果落實

任何沒有結果輸出的會議都是在浪費時間。為了確保會議的有效性，我們需要：

1. 明確執行事項：列出需要采取的具體行動，確保每個步驟都有明確的目標。
2. 責任分配：明確后續執行的責任人，確保每項任務都有專人負責。
3. 設定時間表：定義每項執行動作的預期完成時間，以推動行動節奏，確保成果的交付。

會議人數≥5人時，必須輸出會議紀要和執行事項，并用任務管理工具進行跟蹤。

跟蹤與反饋機制：

1. 在下次正式會議前同步執行事項的進展。
2. 對于進展緩慢或無進展的事項進行詳細討論。
3. 對于進度正?；蛞淹瓿傻氖马椫恍柰浇Y果。

確保信息透明：會后12小時內通過郵件將會議紀要和結論發送給相關方（不僅限于參會人員，還包括需要知曉會議內容的其他人），以保證信息的透明管理和避免溝通遺漏。

最后，總結下核心要點：

1. 簡明材料：確保會議材料簡明扼要，并高度概括，以便參會人員在會前閱讀。
2. 明確議程目標：提前說明每個議程的具體目標。
3. 提前通知：通過郵件或日歷邀請所有參會人員，并明確會議的目的和內容框架。
4. 會議進行：主持人應明確會議的目的，控制時間，確保會議內容緊湊，并在總結時重復關鍵信息，確定待辦事項（ToDo）。
5. 會后跟進：會后整理會議紀要，并抄送給所有參會成員，確保所有人都清楚下一步的行動。

03 內部與外部共識：匯報與文檔的力量

在團隊管理和項目推進中，內外部共識的建立是至關重要的。無論是對外展示團隊進展，還是內部溝通協作，有效的匯報和文檔化都是不可或缺的手段。

以下是幾種常見的匯報和文檔策略，幫助團隊提升內外部的共識水平。

團隊周報：展示進展與貢獻

解決外部的信任問題，對外展示團隊的進展和貢獻。

定期發送團隊周報，同步項目的進度和團隊的工作成果。通過周報，可以讓外部利益相關者（如上級領導、合作伙伴等）了解團隊的努力和成績，從而增強他們的信任和支持。

里程碑匯報：提升團隊士氣

提升團隊成員的成就感，激勵他們繼續前進。

在項目達到重要里程碑時，進行匯報，表揚和鼓勵團隊成員。這種正面的反饋不僅可以增強團隊成員的歸屬感，還能激發他們的積極性，讓他們更有動力迎接未來的挑戰。

突發情況匯報：迅速響應與應對

及時同步突發問題，避免延誤。在遇到突發問題時，及時匯報風險，并尊重時間，迅速尋求解決方案。這種快速反應機制有助于團隊迅速應對突發事件，減少負面影響。

文檔沉淀：提升團隊能力

改善新人與老人之間的共識問題，通過文檔化的方法提升團隊整體能力。以下是兩種典型情況的文檔沉淀：

1. 歷史工作文件：我想要找尋一個文件,它在哪里?——建立資料文檔庫
2. 工作方法的沉淀：我想要完成一個任務,怎么去做?——編寫幫助文檔，提供詳細的步驟指導。

不要急于直接解決問題，而是要思考如何提升團隊的能力，從而減少困惑的頻率。比如，所有新上線的功能都應附帶使用手冊，并提供完整的功能清單。在迭代過程中，對新功能進行標注，確保每個功能都有明確的意義。

04 做好基于項目的總結和復盤：推動團隊成長

在項目管理中，定期的總結與復盤是促進團隊效能提升的關鍵環節。無論是在項目的初期階段還是完成重要里程碑之后，及時的反思都能為后續工作奠定堅實的基礎。

復盤不僅僅是對過去的回顧，它是面向未來的行動指南。通過有效的復盤機制，我們可以：

1. 關注團隊和成員狀態：理解團隊成員的情緒波動和工作狀態，這有助于構建更加和諧的工作環境。
2. 將成功的經歷變成規律：總結成功的方法，形成一套可以重復使用的模式，使其成為團隊的標準操作程序的一部分。
3. 將失敗的教訓變成經驗：分析失敗的原因，從中汲取教訓，避免同樣的錯誤再次發生。團隊的磨合是一個持續的過程，需要不斷改進。

項目復盤的步驟

為了實現高效的復盤流程，我們可以采取以下步驟：

1）收集問題：

• 采用匿名方式收集團隊成員的意見，關鍵是讓每個人的聲音都被聽見。
• 如果團隊關系還不夠緊密，可以采用紙質問卷并放入盒子中收集；如果關系較好，則可以直接在線上問卷進行。

2）打分量化評估：對項目的整體表現進行評分，了解團隊成員對項目的滿意度。

3）列出表現好的點：記錄項目中表現優異的部分，作為團隊的亮點。

4）目前存在的核心問題：確定項目當前面臨的最主要問題，以便集中精力解決。

5）分析問題，共同探討：

• 將成員的自我評價和項目評價匯總上墻。
• 分析成員對項目的評價，整理出亮點與問題。
• 討論問題：召開復盤會議，形成對當前狀態和問題的共識。
• 通過投票選出前五項亮點和前五項問題，進行深入討論。

6）解決問題，制定行動計劃：

• 通過郵件通報全體成員，總結規律，并列出待辦事項（ToDo）。
• 提煉亮點，將其沉淀到知識庫中。
• 拆解問題到具體原因，并列出待辦事項（ToDo）。

項目復盤的原則

• 有合適的主題：復盤的主題必須明確，不能過于發散，以保持討論的針對性。
• 對事不對人：關注結構性的問題，而不是個人批評。復盤應該是一個積極向上的過程，而不是指責大會，創造一個開放和支持性的氛圍。
• 會后跟進：一定要有專人負責跟進復盤會議達成的待辦事項（ToDo），確保改進措施得到有效執行。

可參考的復盤模板

PART01：三點經驗（我有什么經驗可以分享給大家）

1. 項目過程中，出現了什么樣的風險？我是怎么去消除的，有沒有什么好的方式方式可以分享給大家？
2. 項目目標達成過程中，我用了什么方式讓目標推進更加順利？
3. 我是如何進行資源協調的？
4. 在整個項目過程中我沉淀了哪些經驗方法？

PART02：三點教訓（從項目目標本身出發，我踩了什么坑）

1. 項目目標本身制定是否合理？
2. 項目過程的里程碑節點制定是否科學、目標達成路徑設定是否合理？
3. 遇到障礙有沒有及時向上級反饋？
4. 最終達成/未達成項目關鍵要素是什么？

PART03：三點落地改進計劃（基于我踩過的坑，明年我怎么提升避免？）

1）完成目標的過程中可以改進的方向：

• 資源的協調
• 里程碑的制定：包括時間節點的安排、過程跟進的情況、里程碑安排的合理性以及是否跟進進度實時調整里程碑

2）針對影響目標達成的因素，我可以做到哪些：包括內部因素（團隊內的、個人的）、外部因素（環境、組織等），基于這些因素，我可以做到哪些改進，促使目標達成。

3）基于可以改進的點，在下一個有孵化性質的項目中，我們可以怎么做？

參考文章：

devops.phodal.com

美團外賣持續交付的前世今生