起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識電商O2O后臺產品上線和使用跟進
文章將分為六個部分詳細介紹后臺產品的設計過程：后臺產品的作用、后臺產品種類、業務需求對接、產品自身設計、產品上線和使用情況跟進。本文為最后一部分——產品上線和使用情況跟進。
互聯網產品領域，可以籠統地分為前臺產品和后臺產品。前臺產品即是C端的產品，后臺產品可以籠統地概括為各種管理系統。
我們常說的C端產品價值在于滿足用戶需求、提升用戶體驗，后端產品完全不同，第一要義是對業務的支持和提升，通過業務操作和數據的線上化，來標準化業務管理流程、提升業務運轉效率，以及發掘數據的價值，進而在各環節影響到公司的成本和收入。
這對于主營業務為電商、O2O等任何形式交易的公司來說尤為重要。四五年前，當互聯網還處于線上產品為主的階段，業內會說有很多公司不注重后臺。但現在互聯網各行業各類線下服務早已層出不窮，都9012年了，如果還有認為后臺產品的價值小于產品的公司，可以倒閉了。
我本人在小公司做了一段時間的公司內部支持系統，總結出了一部分關于后臺產品的個人經驗。
本文分為六個部分，按后臺產品設計過程的順序，分別是后臺產品有什么用、有哪些后臺產品、業務需求怎么對接、產品本身怎么設計、如何上線和如何跟進使用情況。
這是第三篇，主要寫上線和使用情況跟進相關的內容。這兩塊比較偏向于項目管理范疇，很多規模不是很大的互聯網公司，產品經理都會承擔一些項目管理職責，比如研發進度跟進，上線的過程，以及各種和業務方的協調。其實本人并不太擅長項目管理相關的事情，因此這篇只是把我把經歷過的項目過程和想法描寫一下。
五、后臺產品的上線方式
5.1?為什么后臺產品上線要單獨拿出來寫
我剛開始做產品，接觸到所謂的上線，就是研發把代碼提交了，發個郵件通知下相關人員就行，用戶端的再寫個版本更新說明，應用市場提交下安裝包。后來當我第一次做涉及到系統整體更新的項目時，我的老大一直在跟我說，梳理流程做功能不難，怎么上線才是難點，哪個版本上，什么時候上，如何培訓，這些都要提前搞清楚，弄不好就會做完了上不去。然后我去人人都是產品經理等網站上找內容參考，結果寫上線過程的一篇都沒有。接下來我只能一邊向老大和有經驗的研發求助，一邊摸索著上線大項目，最后雖然有點延期，總算是上線成功了。
所以說后臺產品的上線本身值得單獨拿出來寫。它和用戶端產品上線不一樣，用戶端上線需要做的事情是發版。大版本和1.0版本，更多要考慮的是上線后運營層面的事情。
至于后臺產品，如果只是上線一些小需求或者個別不復雜的頁面，那自然發個郵件通知下就可以。
如果是1.0版本，或者系統整體遷移更新的項目，那產品上線等同于一塊業務的上線，產品經理在上線的前后需要在和業務方的配合下，推進整個業務開始使用。
如果上線事項沒安排好，那好一點的結果就是上線后沒人用，大家繼續用原來的方式，壞一點的結果就是沒法用造成公司業務停滯。
本文就寫一個我所經歷過的大項目上線的整個過程。
5.2?大版本上線標準
大項目上線前的第一步，是確定上線標準。
后臺產品的產品迭代過的思路很不同于用戶端產品。用戶端產品是MVP原則和小步快跑，1.0版本的方向是做最簡單的部分，上線后快速驗證。而后臺產品因為業務本身涉及面廣，各個業務模塊之間的耦合性很高，因此從宏觀層面來看，1.0版本必須是一個主要業務流程閉環的大系統，達到能支持核心業務流轉的標準。如果只做部分模塊上線，流程未閉環，操作了流程前半截，后半截沒了，那顯然沒有意義。
在此基礎上，互聯網行業的后臺產品又不能像傳統軟件企業那樣，一次性交付一個大系統，做完完事沒有迭代。那樣不僅研發周期超長，解決問題時效性慢，而且上線后一旦有問題，影響面非常廣，會牽扯到很多流程。
因此上線的標準需要做到流程閉環和小步迭代的平衡，在微觀層面上，一些不重要的業務流程沒必要全部做，只需要預留能手動操作的入口，有個辦法讓業務都能進行下去。
具體操作本身不需要設計得太精細，同樣是實現必要的操作，滿足業務的流轉即可。一些查詢統計類的需求，先實現明細數據的查詢功能。1.0版本的操作不會很方便，只能上線讓業務方正式用起來后，再對操作細節的體驗進行優化。畢竟使用起來后，有些具體操作上的問題才可以看得到，迭代起來更有針對性。
以上就是后臺產品1.0版本的上線標準了，核心流程閉環全覆蓋，非核心流程預留操作入口，具體操作實現功能但不需要精細。
此外，如果是系統整體遷移更新的項目，除了以上標準之外還有一個條件：原先舊系統中已實現的業務模塊，在新系統中同樣需要實現。也就是說更新后的新系統1.0版本的功能涵蓋范圍會比較廣，一定大于等于舊系統。如果因為涉及到業務模塊過多、開發周期太長，一部分稍微不重要的業務流程可以先照搬舊系統，如果需要調整可以等新系統上線后再改。
舉個例子。我曾經參與過一個電商/O2O的供應鏈系統整體遷移更新的項目。項目的背景是舊版系統功能很簡單，而且很久沒有迭代，很多模塊已經不符合實際業務，因此開發新版系統，實現業務流程每個環節的支持。1.0版本的上線范圍當時想了很久，最終的方案如下：
首先，供應鏈的底層邏輯：庫存結構，和核心業務：采購、調撥（訂貨）、訂單消耗，作為四個核心模塊，開發過程分為四個子版本，并根據實際業務情況進行系統流程重構，實現完整的流程閉環，上線后替代舊版系統的業務操作。然后，舊版本缺失的流程模塊，比如售后退貨，以及非核心的盤點、買斷等操作，因為不影響系統遷移，新系統1.0版本中先不做，通過額外開放一個特殊出入庫的模塊實現這些業務。至于數據統計、出入庫記錄查詢類的頁面，通過加導出數據明細的功能實現，提供數據讓業務方手動查詢，后期再針對性地做統計報表。
不過當時這個盡可能縮減的1.0版本，還是因為前期準備不足，花了4個月的時間開發才上線，算是踩了一個大坑。
5.3?上線事項
分享一下我所經歷的一個后臺產品遷移更新項目，整個1.0版本的上線過程。我把它分為了12個步驟，1-4是產品本身的事情，5-9是上線前項目管理方面的事項，10-12是上線的時候要做的事情。因為是系統遷移，所以相對比從零上線1.0版本要復雜一些。
具體事項大致如下：
0）需求對接、產品設計、研發、測試這些事項。在大項目中，將具體業務模塊分為多個版本，進行這幾個階段，直到達到上線標準的版本測試完畢；
1）操作說明文檔的編寫；
作為業務培訓的資料，在培訓之間需要完成。想要寫個全面又可讀性強的操作文檔，是件很花時間的事情；
2）業務方驗收；
將新版系統和操作說明文檔給到業務方的對接人，讓業務方進行驗收。盡量用真實的數據進行測試，所有流程模塊都需要試一遍。我們需要通過觀察并與業務方確認三類問題：
第一是否有流程模塊漏下導致沒有閉環。在系統遷移更新的過程中，會出現一些在舊系統中可以進行、或者無需進行的操作、數據查詢，在新系統中無法進行，設計的時候沒有考慮到的情況；
第二類是對操作效率、體驗影響比較大的功能交互問題。讓業務方用真實數據跑一遍之后，一些我們自己想不到的問題，以及實際操作過程中很關鍵的小細節，業務方使用后都能看出來。當然這里業務方會提出一大堆問題，有些重要、影響面高的是需要上線前完成的，有些相對不重要、有臨時解決方案的，是可以上線后再優化的。
第三類是是否還有bug。
3）遺留流程模塊補全和操作細節優化；
將上一步梳理出來的問題，安排小版本進行優化。
這兩步的耗時可能會比較長。我當時的項目，在之前制定的上線標準版本到最終上線，中間還做了兩到三個小版本，都是在補全一些必要的功能；
4）關聯系統的配合調整；
一個大的后臺系統的某些業務模塊會和其他系統相關聯，比如電商領域的供應鏈系統、訂單系統、統計系統之間有不少業務和數據有強關聯。在系統上線前，這些關聯的系統需要配合進行調整，包括規則上的和數據結構上的。這一步也和前面一樣，需要梳理出哪些調整是現在就要完成的，哪些是可以上線后再改的。
調整之后，在最后上線的一步一起上；
5）人員、事項的安排；
這一步開始可以正式安排上線前的事宜了。與業務方的負責人一起確認上線事項，包括時間、涉及到的人員、培訓計劃等。安排好后發郵件；
6）業務方培訓；
將系統詳細的規則和操作方式，給業務方具體的使用者進行培訓，讓所有人知道新系統怎么用。前面的業務方是直接對接的負責人，這一步則是下面具體使用的人員。有些公司這一步會有業務方進行，不過一個比較大的系統的培訓，還是由產品經理直接進行比較合適。如果操作人有其他城市分公司的，需要進行視頻培訓。
這兩步會遇到的問題是業務方人不全。業務方有些人可能會很忙、不關心系統的事情、不看郵件、在其他城市，會導致我們反復通知、大規模培訓后，他們有人還不知道新系統的事情。如果是在我們力所能及的范圍之外，只能讓業務方的負責人幫我們做一些強制規定；
7）人員角色和權限分配；
在系統上配置每個角色的權限，和所有相關人員的角色；
8）大范圍內測；
培訓和權限配置完成后，讓業務方使用系統的人員進行內測，用真實數據跑一遍核心流程。內測的目的主要有兩點，一是讓業務方熟悉操作，二是再看一遍，有沒有比較重要的，上線前需要優化的交互操作。
這一步比較耗費人力物力。如果系統沒那么復雜的話，可以跳過。
要注意的是，截止到這一步，所有業務操作依舊需要繼續在舊系統中進行；
9）基礎數據的配置；
支撐業務進行的一些基礎業務數據，需要在上線正式使用前完成配置，比如供應鏈系統的倉庫庫區庫位結構、庫存類目結構等。如果是之前從沒配置過的數據，需要業務方的對接人預先完成配置；如果是系統遷移過程中舊系統已有的數據，可以直接進行遷移；
10）關閉舊系統的功能和權限；
這一步開始是正式上線的事情。選一個月黑風高的夜晚，提前通知業務方，幾點后不能再進行業務操作。然后在到點的時候，關閉舊系統的權限和功能，讓那些沒聽到我們通知的業務方無法再進行操作；
11）數據處理；
通常新系統和舊系統的底層數據結構邏輯是不一樣的，所以這一步就是把舊系統中的業務數據統一遷移到新系統中的過程。這一步需要研發人員通過腳本跑數據，如果數據量大，那么就需要一直奮戰到半夜，到一兩點是很正常的。我們產品雖然幫不上忙，但盡量陪著研發一起加班；
12）正式開始使用；
上線成功，第二天早上，業務方正式開始使用新系統。我們需要從一大早開始幫著回答各種問題，跟進處理各種功能和數據上的bug，新的一輪業務推進事項就此開始。
以上主要針對的是系統遷移更新的過程，如果是新產品的1.0版本上線，事項也大致是這幾項 ，上線本身的過程沒有那么麻煩，舊系統權限關閉和數據處理這兩步就沒有了；
如果是一個正常系統的版本迭代，上線一個大的業務模塊，那么培訓、內測相關的事項不需要那么細致，上線本身的過程也沒那么麻煩。但存在新規則上線后會影響舊規則和操作的情況，需要考慮上線這個時間節點前后，業務方具體操作的影響。
六、后臺產品的使用情況跟進
6.1?為什么要跟進使用情況
我們做用戶端產品，每個版本上線之后，接下來要做的事情是通過數據驗證是否達到了預期的效果，觀察用戶反饋是否滿足了用戶預期。后臺產品也一樣，同樣需要觀察上線后是否達到了這個版本的目標、效果。
后臺產品對公司業務本身的相關性很強，某種程度上來說，后臺產品的上線可以代表一個業務的上線。新的模塊上線后，只有通過具體的使用情況，才能判斷我們做的東西與業務的貼合度、和對業務的幫助有多大。
我最開始做后臺產品，做完后發個郵件給到業務方，然后就結束了，業務方有沒有在用，到底怎么用的，只會等他們來找我。要是不找我，我就以為一切順利。后來我的老大開始問我，你的產品上線后是否真正解決了問題，要是老板來問你做了這些的業績是什么，怎么回答。
于是我逐漸開始做上線后各種跟進擦屁股的事，以及開始制定指標或者階段目標，并根據業務方的使用情況復盤。后臺產品做了有沒有用，有哪些之前沒想到的問題，都需要我們自己去跟進觀察，甚至親自使用后才能發掘。
后臺產品從業務方的實際操作中獲取到反饋還是比較容易的，在具體的功能和操作的層面上，上線后可以直接通過溝通、觀察，了解到業務方對新功能的接受程度，找到需要優化的點。
此外，有些公司對后臺產品也會有類似于KPI的數據指標考核。當我們做一個目標是對業務進行提升的后臺產品后，老板肯定想知道，做了這個東西對業務到底有什么幫助，這個時候就需要通過數據指標來驗證后臺產品。
在實際業務過程中，我們需要根據需求本身的不同目的，制定不同的方案，來檢驗后臺產品需求是否實現了目的。
6.2?要跟進驗證哪些事情
上線一個新的后臺產品或新模塊后，我們需要跟進業務方，驗證如下幾個事情：
1）業務方有沒有開始用；
這是很關鍵的。事實上我們上線一個新模塊后，業務方不用是個比較常見的情況，我見過的原因就有好幾種，比如流程設計得不對、和實際業務不符，比如功能復雜、業務方看不懂不會用，比如為了某些管理的目的增加了他們的工作量，導致他們不想用，再比如業務方自己沒定好業務計劃，產品上線后業務本身遲遲不啟動，等待。
這個時候得先想辦法，通過功能的調整、優化，甚至是通過與管理層溝通，讓產品被使用起來，因為使用起來后才能談別的，不然這產品就白做了；
2）是否有bug或者數據不準確；
一般bug在測試的時候就能解決了，但有一些需求是需要上線后，用真實的業務數據才能看出問題來，比如統計類需求。這時這些測試環節的事情也是我們需要上線后驗證的；
3）實際使用的效率，業務方的滿意度；
這是使用層面的問題，對方對我們的產品使用起來是否滿意，是否存在不通暢的流程和不好用的功能，導致操作繁瑣、效率降低。有時候一些細節的篩選、搜索功能，會直接關系到整個業務效率。通常上線一個新的產品或者模塊后，很多細節操作問題需要不斷優化迭代才能達到最佳。
這一點是相對易于理解、容易操作的，直接找業務方溝通，了解他們的問題和實際操作場景，或者親自按照業務方的操作方式，走一遍流程即可。
4）從業務角度看實際業務的運作情況；
在業務對接環節中，我們已經對產品如何滿足業務的運作設計了方案，在上線后，需要通過驗證業務本身的運作情況，觀察是否符合我們設計的方案，業務本身是否有變化或沒有對接清楚的地方，以及很關鍵的，是否有我們遺漏、沒預料到的情況出現。通常以業務支持為目的的后臺產品，上線后都需要驗證下實際業務情況。
舉個簡單的例子，我做過一個采購系統的產品上線過程，對接設計的是主業務流程，上線后發現有兩個部分沒有按照系統規則使用，一個是某些量很小的第三方合作的業務，和主流程有些出入，導致有些環節流程走不下去；另一個是找供應商售后換回的部分，沒有采購價格，導致這部分庫存的成本為0。
這些特殊情況有些是業務對接過程中有遺漏，有些是預留的需要后續再改。業務方能有辦法在系統上通過其他方式操作，但是和我們設計的初衷不一樣，會造成系統的數據不準確等情況，因此有必要盡快調整。
這一點，除了業務方的反饋之外，還需要去現場看業務方的實際操作，以及觀察系統中的真實業務數據，來發現一些隱性的問題。
5）以對業務本身提升為目標的，通過數據統計驗證效果；
前面寫到，當我們做一個目標是對業務進行提升的后臺產品后，老板肯定會需要一個數據指標來衡量產品對業務的效果。上線一段時間后，通過對比指標的變化，來驗證是否達到了我們預期的目標。
后臺產品對業務的提升，常見的有通過精確匹配、智能計算、高效業務流轉，來提升效率、達成率、準確率這些方向，比如一項業務的完成時長，訂單的取消率，倉庫的缺貨率等。需要制定的數據指標就是實際業務的指標。
舉個例子，假如公司要做個客服工單系統，業務形式是用戶下單后通過呼叫中心第一時間響應溝通，旨在通過客服工單的分派機制來加快訂單的響應時間，保證5分鐘內響應，以此提升用戶體驗。那么訂單響應時間就是業務數據指標。產品上線后，通過前后響應時間的對比是否提升，和超過5分鐘響應訂單的比例是否下降，來驗證產品對業務提升的效果。
不過后臺產品的數據分析會相對困難一些，因為指標通常比較隱性，不像用戶端產品那么明顯，而且一個業務指標的提升不一定完全是由產品本身帶來的。以我個人的觀點，后臺產品是否要定指標要根據不同產品具體分析。
三到五點，分別對應了在第一節里寫到過的后臺產品三個目標：提升操作效率，標準流程管理，和業務驅動提升。根據產品的目標，選擇對應的驗證方式。
相關閱讀
#專欄作家#
潘帕斯雄鷹，人人都是產品經理專欄作家，進擊、踩坑中的產品狗一枚，關注互聯網，寫過小說，看過哲學。簡書：潘帕斯雄鷹。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
