接著的就是再次的資源盤點和目標對焦，簡要的 recheck 確保補齊。這時 PM 根據各負責角色工作評估做出簡要排期和項目需求+參與方核對各方訴求，確定最終版本。這里也會遇到幾個問題：
排期時間過長。 解：拆分、加人、分階段。建議最小工作單元評估最好不要超過2人日 。
其他項目排期沖突。解：分析是產品節(jié)奏沖突還是人員(資源)沖突，確認好各自目標再共同協商總體排期。
重要階段未給足充分時間，如設計階段、系統(tǒng)聯調、冒煙、測試、內測等經常忽略項。解：提前協商溝通好協調。
最后，項目排期要和各參與同學溝通清楚投入度和時間節(jié)點。一定要明確幾個重要的時間點：設計評審、測分評審時間、提測時間、產品驗收時間、發(fā)布時間(如果客戶端還要根據不同端特殊情況分開列出)。同時排期過程中可能遇到的并行風險、人員資源風險及時對外同步。
★ 設計+測分評審
設計之于項目隱患+后期擴展、測分之于項目質量風險的意義，技術同學想必都是非常清晰明確的。這不僅僅要求項目PM，對于核心的系分、測分設計人員也提出嚴格要求。務必保證：
1. 重要流程有圖、有文字、有用例覆蓋。
2. 重要設計方案、測試方案要提前溝通討論評估風險和影響。
3. 需要考慮資金、安全、性能、風險的，單列 todolist + checklist。
4. 重要設計影響對外同步。
對于技術型的 PM，最好滿足：
1.項目中的核心設計者；
2.業(yè)務 owner 或核心，其中一項。
這里主要是考慮到技術項目 PM(實在不行要有核心設計人員)對于業(yè)務定型、技術定型在業(yè)務中后期的影響著實太大。
此階段開始作為過程跟蹤重要手段需要有常規(guī)的項目日報和風險提示 了。建議對于工作日小于20人日的項目可以不用每天發(fā)項目日報，有風險及時同步即可。超過的最好每日有項目詳細進度， 根據項目復雜度不同 粒度可以精確到單人負責的模塊 。重要的是過程跟蹤+問題及時反饋解決。
★ 研發(fā)過程
研發(fā)過程中一般大家精力都會集中在各自項目負責模塊上。同時對于我們這種互聯網公司，變化又是家常便飯。這里有個原則是信息跟蹤和同步評估要充分?？赡苌婕暗脚牌谡{整的，要及時溝通和調整。也要注意風險和項目范圍把控。這時你可能會有如下幫助：
1. 項目空間任務列表(aone有批量功能)
2. 排期進度表(云雀)
3. 需求變更記實錄表(云雀)
4. 人員負責表(云雀)
5. 風險跟蹤列表(云雀或aone)
6. 過程進度日報：模塊進度條百分比、當日工作主要內容、風險同步與處理。
7. 重要邏輯影響對外同步(如表邏輯、業(yè)務邏輯變更的，需同步對應使用方)。
★ 冒煙+聯調+提測
大家都知道大多數的線上技術問題都可以在測試階段提前發(fā)現。而PM要思考的是測試前我們能做什么？提測前的冒煙、聯調包含了必要的單元測試、功能測試和部分集成測試。尤其是對于多系統(tǒng)聯動的項目冒煙和聯調的質量直接影響到測試效果和線上問題量。這里PM一定要提前溝通評估安排好時間控制和冒煙聯調節(jié)奏，有必要的話集中閉關+小階段目標設定可以實行 。同時對于復雜的項目由于整體節(jié)奏和工作壓力等原因參與人員很容易陷入自我流程和模塊邏輯里。 在聯調階段作為PM最好能設計出幾個經典業(yè)務場景作為聯調目標，對項目的整體質量做提早把控 。重要項目特殊建議：
1. 全量(70%+)含憑證冒煙。
2. 流程覆蓋設計+測試執(zhí)行(PM)
3. 閉關聯調+分模塊分階段聯調半日目標進度。
4. 獨立的項目聯調環(huán)境準備。
5. 關鍵鏈路的日志標要求。
無論是作為核心開發(fā)還是純PM，此階段都需要主動去檢查項目的研發(fā)交付程度。包含但不限于主業(yè)務流程、特殊分支邏輯等 。你可以根據項目重要程度復雜程度來判斷是否需要精細化。同時此階段也很容易暴露缺失或錯誤邏輯。我個人做法是小型項目自己設計場景 case 走；大型項目聯合核心研發(fā)測試一起設計場景 case；同時注意對產品交互和 demo。
★ 測試
項目到了測試階段大部分的開發(fā)工作已經基本結束了。我們這里討論一種場景是開發(fā)測試有不同人員執(zhí)行。測試 bug 要督促做到日清，不能日清的需要有原因跟蹤。本階段一般也是 code review 集中階段。PM應直接或間接的對于關鍵鏈路設計、流程日志記錄、編碼規(guī)范要著重把關 。同時產品發(fā)布+回滾方案在本階段要做準備了。一般來說每個團隊發(fā)展到2年后都會有比較規(guī)范的發(fā)布計劃模板。這里我們著重提及幾點PM要注意的事項：
0. 安排處理好項目測試環(huán)境，確保穩(wěn)定性。
1. 安排各系統(tǒng)CR節(jié)奏，并跟蹤反饋。
2. 安排發(fā)布計劃討論和準備。制定并總結初步發(fā)布執(zhí)行計劃(單點對應明確責任人)。
3. 安排討論確定版本限制兼容方案。
4. 安排準備線上功能開關和灰度方案。
5. 重要項目要有發(fā)布預演。
6. 預發(fā)和線上不隔離的系統(tǒng)要注意單獨考慮預評估發(fā)測試風險。有必要的給出操作步驟。
★ 產品驗收
一般情況測試完成后就到產品驗收環(huán)節(jié)了。這個過程有些同學可能就直接不問或者任憑產品驗收結果做最后的質量兜底。這是極為不可取的，原因是一般的產品驗收最多只會跑到整體項目 case 的30%不到，越是大越是復雜的項目這個比率越是低。產品驗收的目標是檢查產品功能完整性、產品體驗，而對C的線上用戶幾乎會全方位無死角覆蓋。所以這次是你
