就是代碼不允許改動了，因為在最后時間的代碼改動都有可能引起bug導致無法按時上線。現(xiàn)在我們約定，上線前一天完成代碼凍結工作。
其他時間點：如有管理后臺配合的功能，就要約定管理后臺上線的時間;API接口的上線的時間，因為我們移動端的bugbash 是在線上進行的，所以在bugbash之前確保API接口已上線;ios的版本需要考慮testflight上測試的安排，一般會放在測試最后回歸的階段等。
3. 合理的統(tǒng)籌人員分配
工作量合理分配。各任務評估完成之后，需要將工作量做合理的分配。很多時候看到開發(fā)自己排定的計劃中工作量的分配會不均衡，有些人多有些人少。但是當被問及原因時也并沒有什么原因，可能只是沒有仔細考慮，所以項目經(jīng)理要幫助團隊更多的考慮這部分，將工作量能夠更合理的分配。
人員在多項目間的分配。例如發(fā)現(xiàn)開發(fā)和測試排出來的計劃已經(jīng)不能滿足時間節(jié)點的需求的時候，一方面當然是要優(yōu)化當前的計劃，但發(fā)現(xiàn)已無優(yōu)化空間時，就要考慮調整人員的分配情況。因為項目經(jīng)理會比具體的成員更了解從全局上的優(yōu)先級，就可以考慮將低優(yōu)先級項目的人員臨時調到高優(yōu)先級的項目上來，當然這是在跟職能主管取得一致意見的情況下。
4. 考慮假期影響
一個版本開始之前最好能夠收集大家既定的請假情況，在工作量安排上給予考慮。尤其是在一些法定節(jié)假日前后尤其需要考慮。另外一些特殊情況也會導致請假人員密集：例如公司每年六月份都會消除上一年遺留的年假，這也會導致大家在6月份密集請假。除了請假安排的考慮，項目經(jīng)理還必須考慮節(jié)假日帶來的“假期綜合癥”，如國慶或者春節(jié)這樣的長假前后，大家的工作效率都會降低，這也會成為項目延期的風險，所以需要在計劃階段給予考慮。
5. 周知計劃
確保相關人士能夠get到這個版本的計劃。研發(fā)團隊常常會禁錮在自己的一畝三分地，所以一般情況下，很少有人會想到要周知其他角色，就算有意識去通知相關角色也會很容易遺漏。所以項目經(jīng)理就需要幫大家補足這部分。那么除了研發(fā)團隊還有哪些角色會關心呢?
需求人員(包含老大)會很關心計劃，包含具體的需求范圍(需求范圍可能會跟策劃原先提的有所出入，會根據(jù)工作量情況做微調)，以及具體的上線時間。
運營人員，運營同學需要該計劃來確認下一波上線的內容，從而判斷是否需要針對某幾個功能或者活動安排運營推廣活動。
市場同學，市場同學需要通過該計劃來提前準備提交應用市場審核的相關材料，如果有首發(fā)安排的話，還需要提交首發(fā)申請。如果是跟其他業(yè)務團隊合作的，那么還需要通知合作方。
打個比方，沒有項目經(jīng)理，項目計劃還是能定出來，只不過這個計劃會缺胳膊少腿，到最后還會發(fā)現(xiàn)按時上線會遇到各種風險和問題。所以說，項目經(jīng)理并不是在項目計劃上可有可無的角色，也不只是幫大家畫個時間線這樣的角色，只是項目經(jīng)理在這上面的作用不是那么顯性，但卻是不可缺少的。