如何做好B端產品的驗收與上線交付?

語言: CN / TW / HK

11月的最後一場直播我們邀請到了深耕B端產品領域多年的@張太葉老師,具備豐富的產品團隊組建以及產品管理經驗;擁有10年以上企業CRM項目業務諮詢經驗及項目實施經驗、6年以上互聯網運營平台產品架構規劃和產品設計經驗,同時作為產品面試官面試人數達1000+,深諳互聯網精英團隊組建,人才需求要點。本文為直播內容整理,內容有刪改。

大家好,我是張太葉,目前已經有十多年B端的產品經驗,服務過幾百家大型B端客户,現在在百度帶團隊做一些B端產品的建設工作。

這次分享主要分成三個環節:首先會分享B端和C端在整個交付上的一些差異;其次是用實戰案例來講B端產品的整個驗收落地和效果評估;最後是分享一些誤區和避免踩坑的小貼士。

一、B端和C端在產品交付上的差異

在講差異之前,我們先對齊一個基本的概念,什麼叫產品交付?用官方百科詞條的定義是指在一個明確的時間週期內,產品從開始設計到最終結束的過程。不同產品的結束過程是不太一樣的,有的是研發成功,有的是上線等等,會有不同的結束過程,這是一個官方通用的產品交付定義。

產品交付對於整個業務或產品的重要性,這個不太需要特別多的強調,因為任何產品的設計最終都需要有完整的落地過程,它是我們價值輸出的必經之路。也就是説所有好的idea最終的設計都是需要有交付過程的,同時我們的交付也是一個產品質量保障的核心。

作為一個系列直播,前面的需求包括產品設計,之前的老師都已經介紹過,這次講產品交付的過程,是指從研發完成到產品的測試、驗收、上線到效果評估的一個完整過程,所以核心是交付的後半段,從驗收到上線到效果評估的階段,這是本次分享的核心範圍。

接下來介紹下B端產品和C端產品整個交付上的差異,為了便於大家理解,我們從四個方面來看,當然不僅是交付過程存在差異,在整個產品的建設過程中都會存在一些差異:

第一,項目目標也就是交付目標,兩邊是差異很大的,B端的交付核心看的是為客户輸出的價值、機構方或客户方的需求和收入、給客户方帶來的降本提效,甚至是B端很多內部用户、B端業務用户等等,主要目標就是收入降本和提效。

但是C端就不太一樣,C端作為一個完整C端用户交付的邏輯,它其實是一個用户增長的思路,從拉新促活、留存轉化和用户體驗等,從這些方面上來做整個產品的交付目標;

第二,服務用户,實際上B端客户一是有工作場景,二是有管理需求的,這個是不太一樣的點。對於C端,更多的是個人需求的一些滿足,然後通過產品來做需求的引導,核心關注的是產品的易用性、體驗好不好等,這就是C端用户看中的一些地方。

但是B端會基於我們管理的訴求、工作場景的要求,會犧牲掉一小部分的用户體驗,來滿足整個業務的目標達成;

第三,產品流程,B端業務大部分是比較複雜的,因為跟B端客户完整的業務流程來看,它都會有客户的引入、客户的業務溝通合作和最終客户的一些項目或者成果的交付等,是有一個比較長的業務服務週期,對應的業務邏輯就會比較複雜。

但是C端就會更加關注用户的體驗地圖,用户登錄這個產品在不同階段對應的產品體驗高峯,快樂的區域或者是低峯情緒的低峯區,通過情緒的變化來做很多產品的引導,這是思路差異特別大的一個點。

且在整個交付的過程中,由於整個業務邏輯不太一樣,對應的就會有幾個業務上的差異,比如説B端產品一旦設計好以及開發完成,就不會特別大地去變動,但是C端產品在整個交付過程中,會有一些實驗,這個實驗會有周期性,比如説短期的實驗組,這是一個比較大的差異;

第四,項目週期,就像上面説的,由於B端業務邏輯更復雜,所以項目週期就會更長,會更偏向於項目管理的過程。C端相對比較短,因為它有很多的實驗組場景,這是整個交付的差異,接下來看整個的交付特點。

B端最核心的產品交付特點,總結是從幾個維度來看:

第一,關注用户方最核心的需求,無論是外部客户或者是內部的B端用户,他的核心訴求是滿足一些工作的場景,所以他的核心訴求是什麼?目標一定要非常明確。

用最小圈來開始做,我們去設定MVP最小的需求範圍,這樣可以保證在比較短的時間內快速交付、快速驗證、快速上線,這個是B端關注的第一個點,就是用最小圈能力小步快跑;

第二,在B端是非常強調項目管理和質量把控的,因為很多B端的邏輯一旦確定之後,就不需要大動,所以在這個過程中,我們要保證每個環節的正常交付。對於C端來説,當某些體驗或者是某一些流程不太好的時候,可以迅速回滾,或者是迅速去做策略調整,但是B端邏輯太複雜,所以就使得整個過程要儘可能的保證不出錯;

第三,多團隊多角色的資源協同,當一個業務流程比較複雜的時候,涉及到的業務方、上下游就會非常多,這種多資源協同的情況就會很常見。

介紹完B端和C端的區別,接下來我用一個項目的實戰來介紹整個驗收和效果評估是一個什麼樣的流程?怎麼做的?

二、B端產品的驗收落地與效果評估

先從一個方法論的角度,B端特別完整的產品交付流程,是從需求評審、確認排期、項目管理、產品驗收、上線效果評估和項目覆盤的完整過程來看的。因為上面也提過,我們的交付過程是從產品驗收開始,所以今天核心是講後面三部分的一個內容。

現在開始講我們的重點項目,因為這塊有非常強的一些行業特性,所以我會詳細講解我們之前做的一些案例供大家去理解。

首先介紹下案例的背景,因為我是在百度做平台化產品比較多,之前承接過一個需求叫框架政策的落地項目。框架政策落地是指作為很多的互聯網大廠,會有非常多的比如説廣吿的大客户,我們跟大客户的合作更多是用籤框架協議的形式來完成的。

涉及到框架協議,比如説一年的廣吿預算來簽訂,這樣對於明年的整個業績達成就會有非常好的保障,所以為了跟很多大客户去簽訂對應的框架,需要每年制定對應的框架政策。

框架政策是我們的業務方會根據整個行業的市場和有發展的公司戰略要求來制定的一些新的政策。這個政策包括明年整個公司的戰略方向是在哪個地方要做新的業務拓展,對於重點發力方向和業績增長,需要去做一些政策的扶持。

客户購買什麼樣的廣吿業務?什麼樣的產品可以有更多的優惠?這是從客户角度出發的一方面;另一方面,從整個業務生態的角度,比如説我們會有很多的代理商、合作方在框架協議的過程中也會有對應的激勵政策,是在這個時期同時制定的。

因為客户的簽約需要銷售來完成,客户簽約達成了業績,這是銷售要背的指標,對銷售而言,政策的制定對其打法和方向是一個很好的指引,來吿訴銷售籤什麼樣的協議,賣什麼樣的產品等,這是一個大的背景。

1. 產品團隊的目標

説完背景,那我們作為平台方產品團隊目標是什麼?第一個就是要保證新一年的框架政策發佈之後,線上可以完成整個框架協議合同的簽約,就是指客户的錄入簽約、簽約後的框架合同計算、審批以及框架合同生效之後的監控分析,完整的流程上線。

保證銷售政策落地的核心作用是因為框架協議對於整個百度而言,它是帶來新的一年業績達成的核心關鍵,因為框架客户能帶來一大半的業績收入,當框架政策能夠正常執行,就能保證明年業績目標可能百分之六十左右就已經能夠實現了,這是核心的價值,所以這是基於目標必須要完成的事情。

詳細的需求介紹一下,最開始我們會在每年的十月十一月、十二月之前就開始進行框架政策的一些溝通,這個時候還是沒有發佈的。政策團隊會開始和產品團隊來做需求的溝通,來看明年的政策到底有多複雜?有哪些需求點?雙方就要開始去評估開發期有多長。

因為框架的整個政策是有一個時間發佈的,我們必須要在時間點之前完成產品的上線。產品上線和政策發佈的日期要同步進行,當政策一旦發佈,我的產品功能就必須要上線,這有非常明確的時間要求。

當需求溝通完之後,就會進入到需求評審,保證產品的上線。從整個框架項目的政策來講,上線之後會有下面幾個操作:

第一,政策團隊和我們作為平台的系統操作方,會進行全國的巡遊和培訓,保證大家對政策、系統的操作理解非常清楚,這是一種全國培訓;

第二,政策一旦發佈,銷售團隊就開始去跟客户做整個政策的宣灌,引導客户的跟進和框架的簽約,合同一旦簽約之後,就會走線上的框架合同審批過程一直到最終的合同生效,雖然審批在這裏只寫了一句話,但涉及到非常多複雜的業務場景,整個審批我們會拆出二十到三十多個並行的審批流程,會根據不同的情況走不同的審批流,涉及到不同的審批節點,業務邏輯上還是比較複雜的;

第三,當框架合同生效之後,下一步就是要做框架合同的執行和監控。大家可能覺得這是一個很簡單的看執行情況,其實不是,對於大客户而言,每年的框架協議涉及到的合同金額可能都過億。

過億拆分到每個季度,每個月要消耗多少的廣吿預算,是有非常明確的指標要求的,這就要求在框架執行過程中要有非常高的頻度,然後有運營、銷售同學會一起參與到整個的合同執行過程中。因為但凡框架合同的執行過程不符合預期,每一天可能是幾十萬上百萬的業績損失,所以相關同事都會非常緊抓住所有跟框架合同過程相關的一些日常數據監控。

2. 業績考核

有了框架執行後,接下來就是業績考核,收入達成的每一個階段按周按月按季,業績考核會傳輸到下游業績考核的數據平台,這個是完整的業務流程。在業務流程中拆解對應的項目需求,就會有非常多的點,我總結有以下幾個方面:

第一,整個產品售賣的流程,大家覺得這已經是確定的,其實不是,對於新一年政策的產品售賣,可能會有一些新的變化。百度對應的產品線有兩百多條,這兩百多條產品線在新的政策下是否有新的調整,這個是必須要拆解和確定的;

第二,整個合同簽約的規則與新的政策,什麼樣的客户能籤什麼級別、折扣的框架是有非常明確的規則,另外產品優惠的規則核心是每年的新打法中對不同的產品有不同的激勵政策,這是引導客户和銷售在哪個產品下單的一個核心步驟;

第三,業績考核的規則,甚至是一些特殊行業和客户的一些特批狀態下的規則,這是詳細的一個需求內容。

接下來講下整個項目對應用户方包括兩大部分:一個是外部用户,外部用户核心是直銷客户,他可以直接線上發起簽約,走自助簽約流程,以及核心代理商也可以幫客户來下單或者自己下單;

二是內部客户,內部用户是包括銷售體系和職能體系,銷售體系現在核心服務於兩萬多個銷售,然後職能體系會有運營合同部、財務部、商業經營分析等相關團隊,整個業務的用户還是非常多的。

3. 項目交付難點

講完項目的整個背景,現在説下整個項目交付的難點,因為框架政策落地對於百度而言是一個非常重要且複雜的項目,我用這樣一個項目是想跟大家説,我把涉及到產品交付過程中可能大家會遇到的一些交付難點,都一起在這個項目中體現出來,日常工作中可能不太會遇到那麼多複雜的難點。

大家可以根據自己本身可能會遇到的難點,一起來看下我們怎麼去解決這些難點,因為在不同項目上遇到的難點都不太一樣,剛好這個項目涉及到的難點比較多,就拿它來跟大家分享:

第一,業務方、上下游非常多,業務方上面介紹了有內外部用户方,另外從系統和產品對接角度,我的上下游非常多,因為這個平台定位是百度的統一售賣平台,售賣平台就意味着如果要賣產品,第一得有客户,第二得有一些產品規則,所以客户從哪來,我做了上游相對應平台,將會把對應的所有能簽約客户的各種資質要求會同步給我,這樣就有了客户。

有了客户後,如果要籤框架協議,就得有要賣什麼東西,所以我們會跟商業產品合作,上游商業產品的所有售賣邏輯、規則、標準,也要把信息同步到這個平台,這是從上游。

有了客户、對應的產品後,就需要在售賣平台上發起框架合同的簽約,我會管理簽約過程的下單、審批、執行、分析,有這些完整過程後,下游就要對接財務。

因為客户簽完框架合同之後,接着就是要收錢了,所以就會有財務的計收,我會給財務系統同步收入的接口,還會有對應的業績,每週、月、季看業績,OKR融入的時候就需要拿到對應的數據,所以我有很多的下游口徑,這是因為我的業務方和上下游資源協調方有很多;

第二,有明確的deadline,因為這是對全國幾萬家客户發佈的一個政策,所以有非常明確的時間點,我們一般會在元旦過後一兩天做線上發佈,在這個時間點之前,我的產品功能一定要上線,這個是非常明確的時間點要求;

第三,需求複雜,因為涉及到政策配置、產品售賣邏輯、折扣邏輯還有不同的框架下會有不同的範本流程、財務計收規則、業績規則和最後執行的各種數據報表等,對應的完整流程下來需求還是非常複雜的;

第四,產品驗收場景複雜,當有這麼複雜的需求時,我要怎樣保證線上的政策發佈?因為它是一個對外部客户使用的平台,我必須得保證發佈的政策邏輯是沒有任何問題的,要不然客户就會認為作為大廠,邏輯上竟然有類似的問題,這是非常影響品牌和客户形象的,所以對於整個項目的驗收場景是非常複雜的。

當然我相信很多同學們可能不太會同時遇到這麼多的難點,但大家做B端產品的時候,會有一些自己的特點,比如説非常典型的做B端CRM產品,CRM產品是一個比較典型的上下游會比較多的一個平台,我覺得很多B端的同學可能會有這種感知,比如説它會有客户的售前階段、售中階段和售後階段,對應的部門、客户方的部門可能都是不一樣的,這種是大家都有可能會遇到的一些難點。

另外需求的複雜程度這塊,比如説當我們去做一個商家或者店鋪的交易平台時,你對B端客户做交易相關的時候,可能需求都會比較複雜,怎麼樣核算成本、核算折扣、用什麼樣的價格體系呈現、商品怎麼計價,一直到後台怎麼計算,以及怎麼跟商家分成等,會有比較多的複雜需求在裏面。

驗收場景比較多,也同樣有很多特殊情況,比如説我跟很多產品同學溝通,他做商家後台的時候整個驗收場景可能也會很複雜,大家遇到不同難點時,可以針對性的來看後續是如何交付。

講完交付難點,接下來我們針對今天要溝通的從項目提測、測試、驗收、上線到效果評估整個交付的過程中,我們是怎麼做的?

基於我們剛才介紹的案例來看一下,分成兩個大的環節,一個是產品的驗收環節,拆開來看會包括QA的測試,PM的測試和業務方的測試驗收三部分,其實是基於不同的用户,走了三個不同的驗收步驟,當全部驗收通過後就是我們的上線驗收、上線驗證和效果評估,一直到最後的覆盤。

4. 產品的驗收落地

我們進入第一個環節產品驗收,比如我們的QA測試階段,測試階段大家不要認為是屬於開發提測後才進入的環節,對於一個相對複雜的項目而言,在需求評審階段,我們的QA就會介入進來,且當需求相對複雜的時候,我們會要求PM的需求評審完成之後,就要做兩件事情:

第一,技術研發人員要做自己的技術方案的評審,測試的同學要開始進行測試的Case評審,評審完三步來保證我們合作各方對於需求理解是一致的。

在複雜項目下要做測試Case評審,一般會評審哪些內容?基於我們今天講到的Case給大家介紹下,如果日常跟進中沒有那麼複雜的項目,可能不太需要做測試Case評審的時候,我們可以省略這個步驟。

但是作為PM,心裏一定要有一個底,就是無論你的需求是什麼,你一定要知道怎麼來驗收和上線你的需求,你在寫需求的時候一定要非常明確你的測試邏輯,你的線上和線下的驗收邏輯是什麼?這個是自己心裏要有數的。然後根據需求和項目複雜程度以及相關的要求,來看是否需要走單獨或者正式的評審,這個可以自行根據需求來判斷。

用這個案例來介紹測試Case評審,我分成了幾個部分,就像上面介紹的就是整個政策的發佈框架協議的簽訂,我用簽約前、簽約中和簽約後三個大的業務環節來跟大家做介紹。

首先在框架合同簽約前,我們會來約定幾個事情,首先這個政策是標明什麼樣的客户可以籤?什麼樣的客户、行業可以享有什麼樣的優惠政策?簽約條件是什麼?這些都是在真正簽約前要先做一步判斷,這個是所有的銷售同學通過系統直接來判斷的。

舉個例子,百度會分品牌廣吿、效果廣吿的售賣,品牌廣吿會有很多的品牌資源位,比如開屏、品專廣吿等。當我們的政策約定,比如他前一年在百度的消耗必須要達到多少錢後,他才能享有折扣,會有類似於這種要求,所以銷售就可以在平台的後台先查,他要跟這個客户簽約,先看一下他前一年在百度的消耗是否符合對應的一些政策要求,如果不符合,就要後續走對應的流程,或者是想其他的辦法。

這個是在框架簽約前會從產品的角度做很多的邏輯判斷,這個時候我們就會有Case來判斷了,比如説他是大客户還是直銷的分公司客户,不同的客户類型、所屬行業,對應的政策是什麼,是否符合要求,這是第一步,就開始要做Case的評審了,要把對應的場景區分出來;

第二,當符合相關要求的客户能夠真正簽約的時候,就開始發起現場簽約的流程,這會涉及到非常多簽約的發起、編輯、審核、生效等各種頁面,如果其中有一些轉籤或者特批,還會加一些特批的流程和特批頁面,在這裏面會融合進來一起做。

這塊其實在簽約中也要非常明確出來,作為測試我們要測哪些環節?比如所有發起環節要驗證它的折扣邏輯,就是什麼樣的客户類型買什麼產品,享有的折扣是什麼?系統是可以自動算出來他享有的優惠以及預計消耗等,這些是可以在發起頁面控制自動播放邏輯的。

比如説發起之後可能會被駁回,駁回之後的編輯頁面是要修改哪些內容?怎麼樣來看?另外對於返點的計算,比如説提交之後的查看審批頁面,因為審批環節涉及到的人非常多,銷售、運營、合同、財務各方看到的審批點是不一樣的,且我們能夠做到基於不同的角色給他做審批點的提示,比如説正常流程下,我們會標綠,然後吿訴客户、審批方,合同部的審批專員説這個合同是一個正常的,符合某流程的,他就可以看到這個提示正常走。

有些客户簽約時會有特殊,比如説這個行業要求的折扣是八折,但是他的錢又是七折,所以需要單獨走審批,到某一個領導審批點時,我們就會提示他,這是一個超預期或者是比我們正常折扣要低的,然後他需要額外走別的審批等,會提示每一個審批節點的用户,我們都可以做到給他對應角色關心的一些審批信息,來保證他的審批效率以及審批不會出錯。

這個是簽約中的,對簽約後會涉及到的很多種情況,可能客户提前終止了上一年的合同沒執行完,他提前終止並續簽了,或者是合同在非正常狀態下的一個未完成,他要終止,甚至是他直接正常終止續簽等,所有不同業務場景下合同客户的情況我們都涉及到優惠、返點的計算,還有框架的各種邏輯計算,其實在各個場景下都會有的。

舉個例子,比如説中間涉及到的某個特批的場景,因為每個客户都希望拿到更低的折扣,就會有很多的特批場景,特批場景我們梳理下來大概有五十多個,這五十多個都會作為我們的測試Case評審的一些範圍。

這個項目我們本身團隊會比較大,當地有很多個產品的時候,我們會有幾個測試人員一起跟我們去測,是屬於一個團隊在協作這個事情。所以這時候我用一個框架政策落地的項目來舉比較複雜的一個Case評審,大家在自己的業務流程中一定要知道哪些業務場景是一定要做Case的整個驗收,這個要有預期。

5. PM和業務方的測試環境及驗收環節

研發開發完成體測之後,就對應的是我們的測試中,測試中核心關注的是項目的把控,項目管控對於QA的測試會有什麼要求?

第一個是重大複雜的項目要求每天站會,這個站會的意思是説大家用十分鐘快速對其當前項目進度,以及每個人負責的事情,是否有風險,沒有的就正常過,有的話就一定要當天提出來,這個是測試中的進度同步;

第二個就是對於QA測試環節而言,在測試過程中我們要去剝離出來可交付驗收的環節,這個相當於一個QA和PM並行的過程,我們的場景非常多,比如説在整個Case評審中,可能大概評估出一百個場景,一百個場景有一些是QA先測,測完了可以先交付給PM驗收,QA再測下一個場景。

然後PM驗完之後就可以做下個驗收場景,像這種並行式來保證整個項目進度,因為時間緊,所以能夠快速的測試完,且交付到下一個環節的,我們都剝離出來一個個往前滾;

第三個就是按約定的階段來同步測試報吿,因為當時整個開發上線只有一個月時間,所以每日戰會之後,我們按週會來同步測試報吿。這個我貼了一個模板出來,比如説本週的測試進度測了哪些?結果是什麼等等,會按周發出來,這個是可以跟QA約定的。

當QA測試完成之後,記錄測試後的一個測試報吿環節,我們正常的項目管理和產品交付的要求是所測試完的項目,QA要發出完整的測試報吿,然後裏邊會包括詳細的測試內容、測試結果,然後PM要根據QA測試逐條去驗證。

PM驗證完之後要發佈,比如説我們准予測試通過,然後可以做PM的驗收,這個時候當PM回覆驗收通過的時候,才作為一個上線的標準可以進行上線。

三、如何避免踏入產品交付誤區

在接下來的部分,太葉老師為大家重點講解了 PM和業務方的測試環境及驗收環節、B端產品的上線、驗證和效果評估具體流程,最後還分享瞭如何避免踏入產品交付誤區

囿於篇幅有限,想要觀看完整視頻的朋友可掃描下方海報的二維碼添加會員學習顧問@小熙老師的微信(微信號:qdxyx520)並備註“張太葉”,即可獲得觀看鏈接。

四、本月直播回顧

本次會員直播課程,太葉老師為大家詳細講解了如何做好B端產品的驗收與上線交付,希望大家都有所收穫~

每週三/四晚上8點,起點學院會員平台都會邀請一線的互聯網產品、運營實戰派專家,與大家分享最新的產品行業動態、運營玩法和乾貨知識。

每個月的會員直播都有月度主題,每週直播圍繞月度主題展開。本月主題如下: