項目随着時間的推移與PMO、PM的鞭策，項目開發階段接近尾聲，PM需要進行統籌項目上線相關事宜。本篇文章将從三個方向，提供項目上線前的全部攻略。

分享一下我自己挖的坑或者别人分享的生産事故現場：

• 未與相關業務部門宣導項目上線，導緻上線後業務部門癱瘓。
• 相關參數配置未初始化，生産配置出錯。
• 主流程驗收不認真，導緻生産灰度失敗。
• 項目匆忙上線，生産無法運行，無回滾方案。

………（未完待續）

上面的事故可能PM或多或少都有出現過，踩過坑不怕，我們吸取教訓，怕的是在同樣的項目上犯同樣的錯誤。那麼回過頭去複盤思考，是否上線步驟有規律、有方法可尋！（萬物皆有方法可尋）

我複盤了自己經曆過的大大小小的項目（小到三人項目，大到幾百人項目），把項目上線的過程用金字塔思維整理成思維導圖分享給大家。

我認為項目上線的過程分為三個階段【産品主導階段】【技術主導階段】【項目發布成功】，下面用稍微啰嗦的語言與大家一一唠嗑。

一、産品主導階段

時間節點：全項目周期（感覺做産品很苦逼）

其實大家可以看出來從我梳理的結構來看，PM在每個項目所需要幹的事情挺多的，且很雜（這裡還沒有包括項目前期的需求分析，出方案，交付物産出等），我們接下來針對每個階段展開說明。

1.1 項目驗收測試

目的：PM或需求幹系人進行确認需求的實現是否達到預期，并推進項目進入發版階段。

前置流程：測試同事完成ST測試并回歸完所有BUG,開發同事重新打包程序包用于驗收環節測試。

（特别說明：中小型企業在項目團隊不完善或開發人力資源緊張時，PM其實在ST測試環節已經變身測試人員進行測試，從而會把ST測試環節與驗收測試進行合并進行）

關鍵關注點：

1. 核心流程驗收。
2. 涉及前端需求（涉及前端交互習慣改變，客戶端視覺優化），需要叫上設計師進行配合完成關鍵節點還原度。
3. 幹系人關注點，需通過内部溝通軟件或郵件通知幹系人驗收，或者由産品經理向幹系人演示相關節點。保證需求的策劃滿足幹系人的訴求。
4. 當關鍵驗收指令發出，測試同事抒寫測試驗收報告，開發進行代碼封闆，準備上線事宜，産品同事需要準備相關上線的材料與配置規則。

技術與測試相關的事宜我們放到第二階段，技術主導層面去科普，當前第一階段我們先談産品經理需要搬磚的内容。

1.2 材料準備清單

每次的需求上線都伴随着相關的更新說明文檔等相關的材料，當然材料之間也會有大的區分，針對不同的目标群體需要制作不同的材料。我分為2大類，下面我們一一說道。

1.2.1 标準化文檔

1.2.1.1 标準化SOP指引文檔

SOP為“Standard Operation Procedure”三個單詞中首字母的大寫，即标準作業程序，在企業中指的就是将工作和操作步驟規範為一個标準的流程，從而給員工的日常工作提供最優化的指導。

• 材料目的：為本次需求優化針對市場人員/客服人員應對用戶或者客戶進行的疑問咨詢，提供标準的解釋模闆。
• 前置流程：在指定文檔之前，需要與幹系部門的相關幹系人員确認文檔的合理性。當然材料不一定産品經理撰寫，但是産品經理一定要跟進此文檔的完成情況。
• 關鍵關注點：文檔的通用性，文檔的可讀性，文檔的指引覆蓋的全面性
• 文檔撰寫人：産品經理or 業務人員。簡單舉個例子：客服作業的SOP标準文檔，這個就是有産品經理輔助客服部門進行完成文檔的撰寫，比如提供可能的功能疑問點，常見問題等，由客服人員撰寫文檔内容，最後進行統一審閱，确定最終版本SOP指引文檔。

1.2.1.2 業務規則配置文檔

常見的配置文檔，組織架構權限文檔，活動默認規則、數據報表文檔等。

• 文檔目的：針對譬如“活動、權限、組織架構、業務審批流等具備多規則功能需求”需設定系統層面默認上線參數配置。
• 前置流程：與功能涉及幹系部門梳理業務規則與涉及幹系人，另外必須基于包含在當前需求範圍内。（超範圍溝通難免的事情）
• 關鍵關注點：文檔覆蓋配置項完整，參數配置之間無互斥條件。
• 文檔撰寫人：産品經理。簡單舉個例子：比如某某信貸系統更新，需要與各個業務部門之間确認涉及崗位，崗位角色、崗位功能、可操作數據範圍等等。

1.2.2 差異化材料

企業業務方向不一樣，準備的材料可能會有一些區分，簡單定義為TOB 與TOC企業兩種 ，現在流行的TOVC的高度過高，就不提及了。

1.2.2.1 TOB企業差異化材料

1.2.2.1.1 培訓材料（PPT）

• 文檔目的：讓運營部門或客戶支持部門快速并且全貌的了解和熟知本次項目或者版本升級的全部功能點。然後由運營人員在向企業客戶進行培訓（如需要）或者進行答疑
• 前置規則：在新版本上線之前完成材料内容即可， 提前約相關的部門時間點。
• 關鍵關注點：提前完成培訓材料，産品内部進行過初步内容，查漏補缺階段。提前發出材料讓業務部門的人員熟知，并且預約培訓時間與版本上線時間。
• 文檔撰寫人：産品經理

1.2.2.1.2 宣傳易拉寶、落地頁等

• 材料目的：如上線功能利于業務推廣宣傳，需要與業務部門進行溝通，進行宣傳材料的制作。
• 前置規則：更新升級有必要大勢宣傳。
• 關鍵關注點：營銷内容确認，需要産品提供完成的功能吸引點，跟進業務部門确保上線之前物料能到位。
• 材料準備人：業務部門人員。

1.2.2.2 TOC企業差異化材料

1.2.2.2.1 停機更新通知（如有）

• 材料目的：為了讓用戶提前知悉功能升級内容及停機通知。用戶提前心裡有預期避免出現沒通知用戶進行臨時發布，用戶會一臉懵逼。（講一個活生生例子，以前做支付需要斷交易半小時，未全部用戶通知到位，導緻商戶收款失敗，客服電話都被打爆的那種。）
• 前置規則：本次更新涉及到需要影響生産環境業務運轉。
• 關鍵關注點：停機文案撰寫的合理性，停機公告推送時間，建議提前2~3天進行推送，最晚也需要提前1天。
• 文案撰寫人：運營部門或者産品經理（emmmm大概率是PM）。

1.2.2.2.2 重磅更新banner圖

• 材料目的：讓用戶明白或者知悉本次更新的重要内容，達到通知和引導用戶升級APP等目的。
• 前置規則：根據新版本内容确定是否需要更新客戶端，當然現在不同的載體更新機制不一樣。
• 關鍵關注點：通知形式确認，push通知還是彈窗banner 還是二者皆而有之;通知内容确認，運營人員提煉相關更新内容與措辭.
• 材料準備人員：運營人員。

1.2.2.2.3 投放廣告渠道方案（如有）

• 方案目的：僅針對新業務或者新功能需要進行投入資源進行大力曝光，需要配套準備廣告投放方案。
• 前置規則：功能需要設計投入而外資源進行推廣。需要與廣告部門或者運營部進行協作完成廣告投放方案，需要提前想财務進行提預算審批。
• 關鍵關注點：投放渠道，是否需要做渠道區分（可能會涉及到功能埋點的區分);投放需要哪些産品層面的支持;投放的時間與周期。
• 方案策劃人：運營部門或者廣告部門 （大概率不會是産品部）

還有其他的很多差異化的材料或者方案………避免篇幅過長我這邊就不一一舉例。

1.3 項目上線策略

1.3.1 灰度計劃

微信視頻号為什麼我沒有入口，視頻号為什麼我沒有發布入口，這些都是産品灰度的機制。我們簡單分析和了解一下灰度機會一般需要準備什麼？

目的：常見産品上線規則，很多産品上線都會有灰度階段，新功能/重大業務流程改造需要小範圍測試用戶接受程度與業務數據（轉化率、跳出率）等。

設計策略：結合公司資源進行靈活設置，不要為了做灰度投入過高或過多的資源。需要去平衡投入産出比。

二、技術主導階段

這個階段基本沒多少産品經理的事情啦，就是配合開發提供一些系統配置參數等。

來看圖：

2.1 發布前步驟前置流程

産品經理/業務部門幹系人員驗收完成，測試正式推送驗收報告，測試通過進入封包發版階段。

其實思維導圖裡面的都是我自己根據多個項目經驗整理出來的步驟，有技術型産品經理覺得梳理得有誤，可以指正我修改。完整以下内容知道就好了。

2.1.1 配置參數檢查（如有）：檢查相關人員/系統參數是否配置正确。（例如：上新某個實名認證功能，需要做成開關配置，默認為【開】，那麼肯定需要檢查開關配置是否正确。）

2.1.2 項目版本封闆：代碼有毒，停止撸代碼。（ 意思就是開發可以不用改代碼了，不封版就會有各種“優化”需求提出來，改個字段，換個圖片等。）

2.1.3 服務發布方案：發版的時候肯定是有個先後順序，先發什麼服務，後發什麼服務，這裡面不同公司機制不一樣，當做了解就行。

2.1.4 版本回滾方案：這個一般都是不願意看到的，基本出現了這個回滾就有人要倒黴了，年底kpi考核難看了。當然不管版本回不回滾，方案是需要的。最可怕的是版本需要回滾，沒有回滾方案。emmmmm這事故現場想都不敢想。回滾場景：項目發布成功後，在準生産環境進行驗收主流程無法通過且短時間無法修複。

系統環境科普及其場景：

• 開發環境：技術同事實現需求環境。
• 測試環境：測試同事進行功能冒煙測試、ST測試
• UAT環境：業務部門、産品經理驗收項目。
• 灰度環境（準生産環境）：與生産配置一模一樣，為了做上線後驗證，如果業務流程無誤才會發布到生産環境。
• 生産環境：這個沒啥科普的。

三、項目發布成功

開發大佬把項目成功發布上線，這個時候又需要産品/測試/業務人員介入了，進行最後的生産驗證測試。

3.1 産品/測試驗收

3.1.1 産品驗收：驗收功能配置、灰度範圍、主流程是否正常。

3.1.2 測試驗收：生産其他原有功能、業務是否正常。不能因為新功能的上線，影響到了老功能。

3.2 幹系人驗收

3.2.1 業務幹系人驗收：驗證所提需求是否正常（有些需求改小小的規則，你們懂得，所以讓業務的人自己驗證）。

項目的上線是結束也是全新的開始。

本文由@微丶笑 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部