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