'一次兵荒馬亂的上線，我學到了這些經驗'
"一個產品從研發到上線，中間有很多隱性的環節。而上線是一個查缺補漏的環節，其中需要專人專職，解決發現的問題，不斷完善產品。
一個產品從研發到上線，中間有很多隱性的環節。而上線是一個查缺補漏的環節，其中需要專人專職，解決發現的問題，不斷完善產品。
這是一個悲傷的“兵荒馬亂”的故事，希望你看到之後不會再遭遇如此猝不及防的上線事故。
項目背景：項目是一家跨境電商公司自己的ERP後臺系統，本次主要講述其中的採購模塊上線過程中發生的事情。
分享目的：通過客觀記述本次上線的全流程，總結過程中做得不好的地方，並針對性地給出應對方案，期望能讓讀者（也包括我自己）在下次跟進產品上線時更遊刃有餘。
一、項目簡介
採購模塊，顧名思義就是把貨從供應商家通過各種環節最終送到公司倉庫的過程。對於跨境電商公司來說，供應鏈的效率也是競爭力之一，供應鏈涉及節點和需注意的細節極其多，這裡簡單介紹下采購系統涉及的角色和各角色在這條供應鏈鏈條中的作用。
"一個產品從研發到上線，中間有很多隱性的環節。而上線是一個查缺補漏的環節，其中需要專人專職，解決發現的問題，不斷完善產品。
這是一個悲傷的“兵荒馬亂”的故事，希望你看到之後不會再遭遇如此猝不及防的上線事故。
項目背景：項目是一家跨境電商公司自己的ERP後臺系統，本次主要講述其中的採購模塊上線過程中發生的事情。
分享目的：通過客觀記述本次上線的全流程，總結過程中做得不好的地方，並針對性地給出應對方案，期望能讓讀者（也包括我自己）在下次跟進產品上線時更遊刃有餘。
一、項目簡介
採購模塊，顧名思義就是把貨從供應商家通過各種環節最終送到公司倉庫的過程。對於跨境電商公司來說，供應鏈的效率也是競爭力之一，供應鏈涉及節點和需注意的細節極其多，這裡簡單介紹下采購系統涉及的角色和各角色在這條供應鏈鏈條中的作用。
二、上線前的準備
在項目上線之前 ，我們做了如下準備：
- 測試工作：產品工作人員測試兩週半，業務部門小範圍測試一週半。儘可能保證大多數流程沒有問題。
- 採購系統使用說明書和操作流程：文檔形式的內容，用以指導大家根據說明書去使用新系統。
- 產品培訓：抽專門的時間給業務部門培訓新系統的使用，PPT講解+現場操作；並現場收集一些小問題點。
- 系統權限開放：不同部門的人員有不同的權限；統計相關職位的人員需擁有的權限，統一給參與者開放權限。
- 上線通知：告知各部門人員確切的上線時間和需準備的工作。
- 安排專人駐：等上線之後可以現場解答一些關於操作的使用問題。
- 拉群：產品工作人員進入業務部門的群；方便上線之後，業務部門在群裡反饋問題，，產品工作人員及時在群裡回覆。
三、產品上線過程中的工作
通過前期的準備，終於迎來了產品的上線，上線過程中遇到了很多沒有預料到的事情。所做工作如下：
- 產品工作人員駐場一週，負責解答業務部門的疑問和指導操作。同時，對於群裡的關於產品使用的任何疑問都需要及時回覆。
- 對於業務部門反饋的數據不準的問題，及時排查原因；給與回覆並做相關調整，以保證數據的準確性。
- 每天根據業務部門使用過程中發生的問題寫優化文檔，快速迭代以滿足需求。
- 每天更新前一天優化的功能點，讓業務部門及時瞭解系統的變化。
四、產品上線遇到的難題
- 對產品培訓時提出的問題沒有及時響應，版本規劃相對業務需求滯後；導致上線之後，業務部門意見比較大；與此同時，研發的緊急優化需求較多，節奏有點亂。
- 事先沒有準備FAQ文檔，對一些高頻問題沒有提前準備和提前準備好回答；導致上線之後有不同的人問，有些顧此失彼。
- 沒有及時對一些高頻重複諮詢的問題做彙總，重複回答不同人的同一類問題，花費了比較多時間，效率比較低。同時，對於已回答的問題由於時間匆忙也沒有及時彙總，會導致不同的人在群裡問同樣的問題。
- 對於當天提的優化跟進不到位，實際上如果研發及時優化了提的相關需求文檔，某些問題就會得到緩解。在過程中，自己也沒有對優化內容做一個優先級排序，導致研發沒有有限處理緊急的優化需求，資源未得到合理分配。
- 產品設計由於沒有覆蓋到一些場景導致了部分工作提升了各部門的工作量；反過來看，最開始做需求調研的時候應該更深入業務部門的實際工作場景，思維應該更嚴謹地做產品設計——不然會導致很多額外的工作量。
- 遇到自己解決不了的大問題，沒有及時反饋出去尋求更多的幫助，導致處理時效降低。所以在工作中，一定不要讓問題停留在自己手裡，連鎖效應很強大，這是本次上線過程體會最深的。
四、產品上線後的反思
經歷了接近1個月左右的忙前忙後，終於接近了尾聲，部門開會的時候，老大問了一個問題：你們知道我們為什麼要重新做一個系統嗎？可能之前一直忙於執行的工作，並沒有花時間來想過這些事情，因此在做項目覆盤的時候把自己的想法做個記錄：
1. 清楚項目目的是項目正常運行的前提
做一件事情，我們必須清楚目的是什麼，這樣在面對各業務部門的問題時才能有的放矢，從公司整體角度來看就是有些事情可以做，有些事情就是不可以妥協和讓步，項目目的跟很多因素相關，最主要就是公司當前所處的發展階段和業務規模。
於是我想了為什麼本次需要重新做一個系統：
- 公司發展早期，商品出入庫管理粗放，出入庫記錄和流程計劃不嚴謹。從而導致對商品的定期抽檢及庫存盤點存在較大困難，進而造成庫存數據不準確，易造成庫存積壓和缺貨，基礎數據不準確會影響一些決策，使數據分析沒有意義，沒有得出真正有價值的結論。
- 公司發展早期注重規模的擴展，因此對供應商的准入機制靈活性過大，規範性不足，缺乏統一的供應商管理系統進行統籌管理。隨著公司規模越大，對供應商的要求越高，對供應鏈效率要求越高，因此就需要嚴謹的供應商管理系統，方便公司對供應商進行統一管理和維護。
- 前期公司很多決策都依賴於人，依賴關鍵人物拍板決策。在發展過程中積累了不少基礎數據，系統需要更自動化和智能化，以提高工作效率，同時發揮大數據的作用，為公司決策提供全面且相對正確的數據。
2. 及時響應業務部門的需求
B端產品一定是為業務部門服務的，在業務部門使用過程中提出的合理需求，以及一些極特色場景的需求，產品都需要及時響應。在用戶提出疑問後，就要主動去跟用戶溝通，做用戶調研，瞭解用戶發生這個問題的場景，以及用戶遇到的問題和期望的解決方案。
同時需考慮用戶這個場景是不是大多數用戶都會遇到，發生的頻率有多頻繁？在瞭解清楚之後就要去想可行性方案，找到最合適的功能點提需求讓開發進入開發當中。
上線之後的優化需要快速迭代了，因為龐大的業務量半個小時都可能產生很多數據，需要從技術上把部分異常問題規避掉。
上線過程中產生的異常數據，如果研發可以通過程序把類似的數據都找出來修改的話，就儘量讓研發寫程序處理，單個人工處理效率低下且容易時效性不強。因此產品經理也需要清楚地告訴研發你的需求，你需要研發給你找到哪些數據，需要給你要的東西一個明確的定義和描述，讓程序能懂。
3. 需求評審的重要性
通過需求調研之後，產品人員形成了產品解決方案。然後這個時候需求評審就很重要了，需求評審就是讓所有人員明確需求時間、需求背景、需求目的。
需要跟業務部門確認產品方案是不是能滿足他們的業務需要，同時需要跟研發部門確認產品方案的可行性，需要研發部門評估研發時間，明確相關負責人的工作內容和交付時間。對於中大型項目，一般會有幾次需求評審，第一次是給大家過一下整體流程，在流程沒問題的前提下再下一次需求評審再跟大家討論方案細節，最終確認沒問題就進入開發階段。
4. 項目管理的重要性
一個產品僅做出來沒用，還需要交付給業務部門使用，需要推動、協調各方面資源來達成目的，對產品經理的軟實力要求比較高。
因此產品上線前，就需要有一個明確的目標，比如V1.0版本先運行一週，數據沒問題再上線V1.1版本更新的新功能；需要有明確的開始和結束時間，不然上線週期就會拉得特別長。同時需要有相對確定的參與者，比如需固定幾個研發專門處理這個上線項目的優化需求，各司其職，遇到問題也好找對應研發快速解決。
寫在最後：越是忙的時候越應該讓自己的工作有條不紊，這個是職場人員一直需學習和保持的東西。
本文由 @左左雜貨店 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
"