B端产品经理怎么做验收

一、为什么做产品验收

产品的每个迭代发布之前，都会存在验收的步骤，而验收就是对产品进行判断的过程，判断开发出来的产品是否与设计、需求存在偏差，能否达到设计预期。作为产品的“衣食父母”，产品经理非常有必要进行产品验收，主要有以下3点原因：

一是流程闭环。 一个产品始于产品经理提出的需求设计，终于产品经理的产品验收，通过对测试结果的复核，能够形成流程闭环，有利于产品质量和效率的双保障。

二是确保产品符合需求。 产品经理是最贴近真实用户的存在，产品验收过程中可以判断开发出的产品是否满足业务场景、设计方案、用户作业逻辑以及发现未来用户可能会吐槽的点，力争做到不要轻易的让用户来发现bug。

三是形成迭代基础。 产品的需求来自产品经理，只能说产品经理对设计的产品最为熟悉，但是真正开发出来的产品一定会和设计内容有所偏差，只能通过产品验收进一步熟悉落地的产品，便于用户答疑、下一步开发迭代。

二、如何做产品验收

产品经理做验收，目前没有明确的标准。如果开发过程中与技术人员沟通频繁、如果公司的测试团队给力、如果业务侧减少需求的变更，可以在验收环节节省很多精力。但是很多时候事与愿违，所以产品经理们还是要仔细、认真做产品验收。

根据以往经验，我将验收又进一步分成了前、中、后3个阶段，以便能够更清晰掌握产品验收的过程（可视实际情况有所调整）。

2.1 验收前

大家可以试想，在产品验收中要产品经理解决不同角色账号问题、验收出的问题已经被测试发现只是没来得及修复，会不会很抓狂。

为了尽可能避免上述问题的出现，我们可以制定可进入产品经理验收流程的标准，一方面能够确保测试和开发人员的工作标准，另一方面也能够节省我们的工作时间。

2.1.1 不同角色验收账号

产品验收时，一套（而非一个）测试账号是所有验收内容的前提，这是因为99%的B端产品都会设计不同的用户角色以及权限，所以不同的账号对应不同的页面、操作权限、查看权限。

当然，如果是成熟的B端产品，都会有角色组、权限配置功能，此时也可以在测试环境赋予产品超级管理员角色，根据验收需要配置不同角色的配置账号，但是最终结果都是可以登录到不同角色账号进行验收。

下表是账号记录表，可供参考：

角色	账号	密码
超级管理员	Abc12345	12345@Abc
公司领导	Abc23456	23456@Abc
合同审核员	Abc34567	34567@Abc
业务员	Abc45678	45678@Abc

2.1.2 测试bug清单与用例

如果按流程工作的话，在产品验收前应该已经做过产品测试，而测试报告可以帮助我们简要了解产品开发的质量、目前已经存在的问题等。

在实际工作中，交付工期都是非常紧张的，所以很难做到测试完全OK并且bug修复完成后产品经理才开始验收，为了最大程度减轻验收工作量，可以和测试沟通测试出来的bug清单、跟进状态、测试用例。

2.1.3 系统数据干净

已经在工作中的小伙伴在产品验收中，如果验收出现了卡点，技术人员可能会说：这是脏数据，换一个条数据就行了。结果换了一条数据后依旧是脏数据，说到这里你想提刀去找开发吗？

为了最大程度避免上述问题，一方面可以让技术确认哪些账号是可用的，没有创建过脏数据，另一方面如果可能的话，是否可以提前删除掉开发过程中插入的数据。

在一个“干净”的系统中，我们就可以开始干活验收啦。

2.1.4 准备前期设计文档

试想：你说A页面不对，应该是三个按钮：返回、保存、保存并提交，但是开发说原型和PRD文档就是这样写的，你尴尬不？为了避免这种情况，建议在验收前期准备中把要对照的文档统统翻出来，形成验收的标准，具体包括：

• 产品需求文档： 用于验收过程中的功能比对；

• 产品原型： 产品文档往往不够直观，具体的功能跳转，甚至简单的交互都可以对照原型进行验收；

• 产品变更文档： 用于记录在需求评审后，变更的需求内容；

• UI设计图： 用于指导前端开发页面样式的文档。

2.2 验收中

2.2.1 产品与业务是否不符

产品经理是产品的“爸妈”，自然也是距离真正用户最近的人，所以在验收中第一要义是考虑是否满足业务， 并且善于从业务视角考虑功能是否可以满足要求。

一是核心业务流程是否畅通。 如果核心业务流程出现错误，一定是大问题。业务提出的采购申请，只有经过A、B、C三位领导都审批过后才能够正式生效。我们需要验证的是业务提交后是否可以自动到达领导审批，审批通过、驳回是否正确等。

二是是否满足审计/管控要求。 如果大家做央国企的软件系统，一定要额外留意的一点是系统是否满足国资委对业务的监管要求，例如超过200万的合同额信息要能够自动识别并且上报国资委；能够识别贸易中的交易风险等。

三是角色权限是否正确。 系统内共包括几种用户角色，不同角色之间是否能够查看对应页面、按钮、数据等，这些都是产品经理在验收过程中要格外注意的内容。例如普通用户只能看到自己购买的商品，但是公司管理员可以看到该公司所有员工的购买数据等。

2.2.2 产品与设计是否不符

一是页面以及实现方式是否一致。 在开发过程中，技术人员可能会使用不同于PRD文档中的实现方式，来实现某些功能，这时要判断是否需要修改，以及页面是否会有一些缺失等。

二是页面元素内容是否缺失。 B端产品的页面多为列表页面和表单页面。针对列表页面，需要判断查询条件、操作按钮、列表字段是否缺失；针对表单页面，需要判断不同字段关联显示逻辑、字段填写方式、字段下拉值集、字段校验条件等是否正确，这里是容易出现问题的地方

三是页面样式是否美观。 虽然B端产品并不像C端产品注重页面美观度，但是不同色彩搭配、模块搭配也会影响使用人员的观感、甚至操作友好度，所以针对这一部分，建议前端开发能够按照UI上传到蓝湖的大小、样式画页面。如果公司内分工明确的话，属于UI验收内容。

四是字段校验是否准确。 在填写表单时，会存在住诸多校验内容，这也是开发时容易出错的点。

• 必填校验。 例如在发布商品时，商品所属分类属于必填项，要验证前端页面是否标记为必填，以及保存提交商品时是否校验必填。
• 关联显示。 例如在创建立项时，选择集团内项目和集团外项目，下面展示的字段内容以及是否必填都会有所区别。
• 数量校验。 在填写合同里程碑金额时，需校验不同里程碑金额之和 = 合同总金额，否则应该提示错误。
• 日期校验。 例如在填写合同失效日期时，就不应该能够选择填写日以前的日期，或者早于生效日期的日子。

2.3 验收后

2.3.1 问题跟进表格

问题跟进表主要用于对验收过程中发现的问题进行记录、跟踪。一般而言，该步骤可以在项目管理系统进行跟踪管理，如果没有的话产品经理可以使用腾讯文档、金山文档等在线表格进行跟进。

2.3.2 产品验收报告

产品验收报告代表产品经理对于产品已经验收完成，并且标注验收是否通过，一般而言，产品验收报告包括以下内容：

• 产品相关信息： 产品名称、产品版本号、预计上线时间
• 验收人相关信息： 验收人姓名、岗位、验收时间等
• 功能清单信息： 验收的功能清单，包括验收项目名称、验收标准、是否通过、不通过原因等。
• 签字确认项： 验收人签字、验收日期确认等。