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