一、为什么做产品验收
产品的每个迭代发布之前,都会存在验收的步骤,而验收就是对产品进行判断的过程,判断开发出来的产品是否与设计、需求存在偏差,能否达到设计预期。作为产品的“衣食父母”,产品经理非常有必要进行产品验收,主要有以下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 产品验收报告
产品验收报告代表产品经理对于产品已经验收完成,并且标注验收是否通过,一般而言,产品验收报告包括以下内容:
- 产品相关信息: 产品名称、产品版本号、预计上线时间
- 验收人相关信息: 验收人姓名、岗位、验收时间等
- 功能清单信息: 验收的功能清单,包括验收项目名称、验收标准、是否通过、不通过原因等。
- 签字确认项: 验收人签字、验收日期确认等。