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