久久精品人人爽,av在线免费播放,亚洲精品无码av人在线播放

搜索

APP

起點課堂會員權益

職業(yè)體系課特權

線下行業(yè)大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

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

起點課堂會員

2021-12-03

1 評論 8618 瀏覽 57 收藏

34 分鐘

11月的最后一場直播我們邀請到了深耕B端產品領域多年的@張?zhí)~老師，具備豐富的產品團隊組建以及產品管理經驗；擁有10年以上企業(yè)CRM項目業(yè)務咨詢經驗及項目實施經驗、6年以上互聯(lián)網運營平臺產品架構規(guī)劃和產品設計經驗，同時作為產品面試官面試人數達1000+，深諳互聯(lián)網精英團隊組建，人才需求要點。本文為直播內容整理，內容有刪改。

大家好，我是張?zhí)~，目前已經有十多年B端的產品經驗，服務過幾百家大型B端客戶，現(xiàn)在在百度帶團隊做一些B端產品的建設工作。

這次分享主要分成三個環(huán)節(jié)：首先會分享B端和C端在整個交付上的一些差異；其次是用實戰(zhàn)案例來講B端產品的整個驗收落地和效果評估；最后是分享一些誤區(qū)和避免踩坑的小貼士。

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

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

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

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

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

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

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

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

但是B端會基于我們管理的訴求、工作場景的要求，會犧牲掉一小部分的用戶體驗，來滿足整個業(yè)務的目標達成；

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

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

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

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

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

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

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

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

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

介紹完B端和C端的區(qū)別，接下來我用一個項目的實戰(zhàn)來介紹整個驗收和效果評估是一個什么樣的流程？怎么做的？

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

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

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

首先介紹下案例的背景，因為我是在百度做平臺化產品比較多，之前承接過一個需求叫框架政策的落地項目。框架政策落地是指作為很多的互聯(lián)網大廠，會有非常多的比如說廣告的大客戶，我們跟大客戶的合作更多是用簽框架協(xié)議的形式來完成的。

涉及到框架協(xié)議，比如說一年的廣告預算來簽訂，這樣對于明年的整個業(yè)績達成就會有非常好的保障，所以為了跟很多大客戶去簽訂對應的框架，需要每年制定對應的框架政策。

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

客戶購買什么樣的廣告業(yè)務？什么樣的產品可以有更多的優(yōu)惠？這是從客戶角度出發(fā)的一方面；另一方面，從整個業(yè)務生態(tài)的角度，比如說我們會有很多的代理商、合作方在框架協(xié)議的過程中也會有對應的激勵政策，是在這個時期同時制定的。

因為客戶的簽約需要銷售來完成，客戶簽約達成了業(yè)績，這是銷售要背的指標，對銷售而言，政策的制定對其打法和方向是一個很好的指引，來告訴銷售簽什么樣的協(xié)議，賣什么樣的產品等，這是一個大的背景。

1. 產品團隊的目標

說完背景，那我們作為平臺方產品團隊目標是什么？第一個就是要保證新一年的框架政策發(fā)布之后，線上可以完成整個框架協(xié)議合同的簽約，就是指客戶的錄入簽約、簽約后的框架合同計算、審批以及框架合同生效之后的監(jiān)控分析，完整的流程上線。

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

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

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

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

第一，政策團隊和我們作為平臺的系統(tǒng)操作方，會進行全國的巡游和培訓，保證大家對政策、系統(tǒng)的操作理解非常清楚，這是一種全國培訓；

第二，政策一旦發(fā)布，銷售團隊就開始去跟客戶做整個政策的宣灌，引導客戶的跟進和框架的簽約，合同一旦簽約之后，就會走線上的框架合同審批過程一直到最終的合同生效，雖然審批在這里只寫了一句話，但涉及到非常多復雜的業(yè)務場景，整個審批我們會拆出二十到三十多個并行的審批流程，會根據不同的情況走不同的審批流，涉及到不同的審批節(jié)點，業(yè)務邏輯上還是比較復雜的；

第三，當框架合同生效之后，下一步就是要做框架合同的執(zhí)行和監(jiān)控。大家可能覺得這是一個很簡單的看執(zhí)行情況，其實不是，對于大客戶而言，每年的框架協(xié)議涉及到的合同金額可能都過億。

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

2. 業(yè)績考核

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

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

第二，整個合同簽約的規(guī)則與新的政策，什么樣的客戶能簽什么級別、折扣的框架是有非常明確的規(guī)則，另外產品優(yōu)惠的規(guī)則核心是每年的新打法中對不同的產品有不同的激勵政策，這是引導客戶和銷售在哪個產品下單的一個核心步驟；

第三，業(yè)績考核的規(guī)則，甚至是一些特殊行業(yè)和客戶的一些特批狀態(tài)下的規(guī)則，這是詳細的一個需求內容。

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

二是內部客戶，內部用戶是包括銷售體系和職能體系，銷售體系現(xiàn)在核心服務于兩萬多個銷售，然后職能體系會有運營合同部、財務部、商業(yè)經營分析等相關團隊，整個業(yè)務的用戶還是非常多的。

3. 項目交付難點

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

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

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

有了客戶后，如果要簽框架協(xié)議，就得有要賣什么東西，所以我們會跟商業(yè)產品合作，上游商業(yè)產品的所有售賣邏輯、規(guī)則、標準，也要把信息同步到這個平臺，這是從上游。

有了客戶、對應的產品后，就需要在售賣平臺上發(fā)起框架合同的簽約，我會管理簽約過程的下單、審批、執(zhí)行、分析，有這些完整過程后，下游就要對接財務。

因為客戶簽完框架合同之后，接著就是要收錢了，所以就會有財務的計收，我會給財務系統(tǒng)同步收入的接口，還會有對應的業(yè)績，每周、月、季看業(yè)績，OKR融入的時候就需要拿到對應的數據，所以我有很多的下游口徑，這是因為我的業(yè)務方和上下游資源協(xié)調方有很多；

第二，有明確的deadline，因為這是對全國幾萬家客戶發(fā)布的一個政策，所以有非常明確的時間點，我們一般會在元旦過后一兩天做線上發(fā)布，在這個時間點之前，我的產品功能一定要上線，這個是非常明確的時間點要求；

第三，需求復雜，因為涉及到政策配置、產品售賣邏輯、折扣邏輯還有不同的框架下會有不同的范本流程、財務計收規(guī)則、業(yè)績規(guī)則和最后執(zhí)行的各種數據報表等，對應的完整流程下來需求還是非常復雜的；

第四，產品驗收場景復雜，當有這么復雜的需求時，我要怎樣保證線上的政策發(fā)布？因為它是一個對外部客戶使用的平臺，我必須得保證發(fā)布的政策邏輯是沒有任何問題的，要不然客戶就會認為作為大廠，邏輯上竟然有類似的問題，這是非常影響品牌和客戶形象的，所以對于整個項目的驗收場景是非常復雜的。

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

另外需求的復雜程度這塊，比如說當我們去做一個商家或者店鋪的交易平臺時，你對B端客戶做交易相關的時候，可能需求都會比較復雜，怎么樣核算成本、核算折扣、用什么樣的價格體系呈現(xiàn)、商品怎么計價，一直到后臺怎么計算，以及怎么跟商家分成等，會有比較多的復雜需求在里面。

驗收場景比較多，也同樣有很多特殊情況，比如說我跟很多產品同學溝通，他做商家后臺的時候整個驗收場景可能也會很復雜，大家遇到不同難點時，可以針對性的來看后續(xù)是如何交付。

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

基于我們剛才介紹的案例來看一下，分成兩個大的環(huán)節(jié)，一個是產品的驗收環(huán)節(jié)，拆開來看會包括QA的測試，PM的測試和業(yè)務方的測試驗收三部分，其實是基于不同的用戶，走了三個不同的驗收步驟，當全部驗收通過后就是我們的上線驗收、上線驗證和效果評估，一直到最后的復盤。

4. 產品的驗收落地

我們進入第一個環(huán)節(jié)產品驗收，比如我們的QA測試階段，測試階段大家不要認為是屬于開發(fā)提測后才進入的環(huán)節(jié)，對于一個相對復雜的項目而言，在需求評審階段，我們的QA就會介入進來，且當需求相對復雜的時候，我們會要求PM的需求評審完成之后，就要做兩件事情：

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

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

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

用這個案例來介紹測試Case評審，我分成了幾個部分，就像上面介紹的就是整個政策的發(fā)布框架協(xié)議的簽訂，我用簽約前、簽約中和簽約后三個大的業(yè)務環(huán)節(jié)來跟大家做介紹。

首先在框架合同簽約前，我們會來約定幾個事情，首先這個政策是標明什么樣的客戶可以簽？什么樣的客戶、行業(yè)可以享有什么樣的優(yōu)惠政策？簽約條件是什么？這些都是在真正簽約前要先做一步判斷，這個是所有的銷售同學通過系統(tǒng)直接來判斷的。

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

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

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

這塊其實在簽約中也要非常明確出來，作為測試我們要測哪些環(huán)節(jié)？比如所有發(fā)起環(huán)節(jié)要驗證它的折扣邏輯，就是什么樣的客戶類型買什么產品，享有的折扣是什么？系統(tǒng)是可以自動算出來他享有的優(yōu)惠以及預計消耗等，這些是可以在發(fā)起頁面控制自動播放邏輯的。

比如說發(fā)起之后可能會被駁回，駁回之后的編輯頁面是要修改哪些內容？怎么樣來看？另外對于返點的計算，比如說提交之后的查看審批頁面，因為審批環(huán)節(jié)涉及到的人非常多，銷售、運營、合同、財務各方看到的審批點是不一樣的，且我們能夠做到基于不同的角色給他做審批點的提示，比如說正常流程下，我們會標綠，然后告訴客戶、審批方，合同部的審批專員說這個合同是一個正常的，符合某流程的，他就可以看到這個提示正常走。

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

這個是簽約中的，對簽約后會涉及到的很多種情況，可能客戶提前終止了上一年的合同沒執(zhí)行完，他提前終止并續(xù)簽了，或者是合同在非正常狀態(tài)下的一個未完成，他要終止，甚至是他直接正常終止續(xù)簽等，所有不同業(yè)務場景下合同客戶的情況我們都涉及到優(yōu)惠、返點的計算，還有框架的各種邏輯計算，其實在各個場景下都會有的。

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

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

5.?PM和業(yè)務方的測試環(huán)境及驗收環(huán)節(jié)

研發(fā)開發(fā)完成體測之后，就對應的是我們的測試中，測試中核心關注的是項目的把控，項目管控對于QA的測試會有什么要求？

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

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

然后PM驗完之后就可以做下個驗收場景，像這種并行式來保證整個項目進度，因為時間緊，所以能夠快速的測試完，且交付到下一個環(huán)節(jié)的，我們都剝離出來一個個往前滾；

第三個就是按約定的階段來同步測試報告，因為當時整個開發(fā)上線只有一個月時間，所以每日戰(zhàn)會之后，我們按周會來同步測試報告。這個我貼了一個模板出來，比如說本周的測試進度測了哪些？結果是什么等等，會按周發(fā)出來，這個是可以跟QA約定的。

當QA測試完成之后，記錄測試后的一個測試報告環(huán)節(jié)，我們正常的項目管理和產品交付的要求是所測試完的項目，QA要發(fā)出完整的測試報告，然后里邊會包括詳細的測試內容、測試結果，然后PM要根據QA測試逐條去驗證。

PM驗證完之后要發(fā)布，比如說我們準予測試通過，然后可以做PM的驗收，這個時候當PM回復驗收通過的時候，才作為一個上線的標準可以進行上線。