產(chǎn)品發(fā)布的最后一公里，最后一公里聽起來很少、很小，但對于場景的打穿、用戶的需求場景達成至關(guān)重要。

產(chǎn)品經(jīng)理A：產(chǎn)品都已經(jīng)發(fā)布上線了，還要我關(guān)注干嘛？

項目經(jīng)理B：代碼經(jīng)過了前后端開發(fā)的自測、聯(lián)調(diào)，也經(jīng)過了測試的冒煙、單元、回歸測試，產(chǎn)品和業(yè)務也都驗收了，還想怎么樣？

開發(fā)者C：測試工程師不都測試過了嘛！產(chǎn)品不都驗收了嘛！業(yè)務不也驗收了！管我什么事兒？

一、迫不及待的項目

常見的迭代結(jié)束后、甚至于迭代內(nèi)容處于驗收末期時，開發(fā)資源就會快速的被項目抽離。從項目管理的角度來說，加快資源日歷的流轉(zhuǎn)，看起來是可以提高“研發(fā)效率”的。簡單的理解思路就是，快馬加鞭，削短空閑時間。只要我自己奔跑，就能超過時間。

二、勇往直前的開發(fā)leader

研發(fā)人員，也不乏會有迫不及待的想進入下一個迭代的沖刺。對于這樣的研發(fā)表示在情感上不得不鼓勵，但并不贊賞。如果是迫切的coding結(jié)束，提測，等待測試來發(fā)現(xiàn)未盡的細節(jié)。無疑是總想抬頭看風景，忽略腳下的路。

三、出人意外的結(jié)果

如果是以上的背景情況，那么事實通常會是以下的狀況，資源被快速抽離進入下一個迭代的進程之后，逐漸暴露出來提測質(zhì)量不佳、實現(xiàn)點缺失、關(guān)聯(lián)系統(tǒng)影響改動遺漏、驗收時間被拖延。表面看起來開發(fā)端在趕緊時間交付代碼，但是如果質(zhì)量不佳，不好的影響非常大：

1?? 新的迭代起了頭，不得不被擱置。需要一氣呵成的代碼邏輯，被不斷打斷之后難免出現(xiàn)紕漏（對于開發(fā)者來說，連貫的編碼不被反復打斷絕對是有助于產(chǎn)品質(zhì)量改善的）

2?? 開發(fā)者自身的情緒和信心波動，由于沒有完整的自測和深入的代碼完畢后的復盤，面對排山倒海的缺陷甚至都懷疑人生了

3?? 測試、產(chǎn)品、開發(fā)溝通成本劇增，由于編碼前的一些必要信息對齊缺失，暴露在測試階段將會大幅度提升溝通成本，關(guān)于功能、實現(xiàn)邏輯等

4?? 產(chǎn)品正常的節(jié)奏、測試的節(jié)奏受到不可控的影響，引發(fā)各個環(huán)節(jié)的時間被強制擠壓，整體質(zhì)量下降

5?? 驗收交付之后，由于資源早已投入下一個迭代，對于線上的質(zhì)量問題，還要協(xié)調(diào)開發(fā)資源而不得不打斷正在進行的開發(fā)工作

以上這些如果在項目資源規(guī)劃層面沒有正確的識別和評估，導致的結(jié)果必然是：研發(fā)節(jié)奏紊亂、團隊信心波動，甚至于團隊內(nèi)部沖突。并且出現(xiàn)迭代總是不能如期保質(zhì)保量交付，產(chǎn)品節(jié)奏紊亂，用戶體驗受挫。

通常能夠做到對迭代正確的評估、認識、管理推進，已經(jīng)是非常不錯的了，這中間需要項目、產(chǎn)品、研發(fā)、技術(shù)的高度一致和碰撞，信息的不斷對齊。同時充分相信團隊成員，給予團隊負責范圍內(nèi)的自主權(quán)利。一群人，最可怕的就是一條心搞一件事了。能做到以上，我認為就是一個好的項目管理者了，現(xiàn)實中能達到御己御人地步的可能也寥寥無幾。更別提發(fā)布后的快速響應階段，快速響應階段應該成為一種常態(tài)，納入到項目管理的資源規(guī)劃范疇。

別看大家嘴上會說，關(guān)注下發(fā)布后的線上運行狀況，可大都還停留在saysay的階段，真正認真規(guī)劃并提供應對預案還是寥寥。

四、產(chǎn)品發(fā)布的最后一公里

緊張的時間規(guī)劃，版本上線后，產(chǎn)品、開發(fā)迅速抽離進入下一階段的緊張驗收和問題處理階段后。上線項目，導致資源匱乏，缺乏跟進，最優(yōu)勢的資源被撤離后，暴露出來的是連貫性上的迅速脫節(jié)。毫無抗風險能力、容錯空間，承擔的后果就是不得不陷入低效冗雜的溝通、調(diào)整、修復過程，最終讓整體的發(fā)布的效果大打折扣，業(yè)務因此也會受到影響。