如何做好B端产品的验收与上线交付？

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点，起点学院会员平台都会邀请一线的互联网产品、运营实战派专家，与大家分享最新的产品行业动态、运营玩法和干货知识。

每个月的会员直播都有月度主题，每周直播围绕月度主题展开。本月主题如下：

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！