头痛的产品验收到底该怎么做？

这是Kevin的第 882 篇原创

近期带着团队再推动PMTalk产品的迭代和新版本上线。

围绕着自家的小程序、和PC、还有客户端app3个形态下不断做调试和优化。如果你关注使用过PMTALk，就应该可以感受到我们在近年也在发生了较大的变化。

对于小团队或创业项目的产品，产品验收即可以减少资源和时间的浪费，还能快速投入到下个环节工作。

我如何在团队里做产品验收的？分享下我的经验。

1.搞清楚验收和测试的区别

这个部分实际上就把很多小团队搞晕了。

由于没有测试人员、或专业的验收流程，导致产品的验收和测试全部混在一起。每次都是开发结束了后才进行测手验收。

其实验收和测试是2个完全不同的内容。

1.测试的工作

软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 

测试是依照产品经理的需求文档或测试用例进行还原，即使需求文档是错误的，包括没有描述到的逻辑问题，测试的工作要么是跳过不测试，要么是根据错误的需求来描述。

需求开始迈入UI设计前，需求评审中会拉上测试，搞清楚了需求的背景、目的以及需求大体范围后，测试会基于需求文档输出测试用例。产品经理则要求通读测试用例进行把控用例的描述是否准确，同时有无遗漏需求。

▲某测试用例

比如上图是测试用例的描述，针对功能下的操作前置条件、后置条件、基本操作流程进行描述。

一个功能需求会涉及到上百条测试用例，需要测试人员提前撰写和产品经理评估。

2.产品验收

产品验收和测试的目的完全不同，但产品验收产生的过程会和测试相重复，但产品验收的目的只有一个

当前产品版本能不能上线、能不能正式发布。在小公司里没有审核流程的说明，产品经理和业务负责人、或者老板同意就可以发版本。

产品验收阶段会发现很多问题，比如功能的设计缺陷、逻辑错误，甚至是最致命的功能无效、无法解决需求问题。

我们PMTalk会整理出验收表，如下包含了序号、问题、截图、优化描述、解决状态。

解决状态由开发进行标记和同步。其他部分则是产品经理填写

▲验收文档

以序号来定位优化问题，属于BUG的就归纳为当前版本，属于优化的就归属到下一个版本。

▲BUG池

在BUG文档里下面字段如下

解决状态：

当前BUG是否解决，是关键再次验收的标准。

优先级：

根据紧急和重要程度来建设4个优先级，分别是P1、P2、P3、P4

模块：

BUG的功能定位，在哪一个位置上

平台：

如果涉及到多个产品端和系统的介入，则需要定位出BUG在那个平台或系统上。如有调用科大讯飞语音能力，由于没有充值账户导致客户端的语音识别能力受阻，就是第三方平台能力欠费导致。

问题描述：

主要描述逻辑问题、UI问题、文案问题，给出正确的对应描述。如果涉及到复杂逻辑和复杂效果，则需要当面评审沟通。

提出人：

标记出问题的提出人，可能是业务、也可能是运营、还有可能是产品经理。总之定位出问题的直接提出者，注意不是责任人。因为很多时候责任人不是提出

问题类型：

问题的类型根据验收的环节不同，有非常大的区别。比如UI还原不正确的，属于Ui问题、与需求描述不一致的属于功能缺陷、常见的问题比如点击没有反应、跳转错误则属于BUG。

但很多时候如果团队比较小，都可以统称为BUG，唯独需要优化的单独罗列出来即可。

3.上线验收最难的是进度与状态更新

几乎每个公司都会出现这样的问题

就是产品上线前验收发现的问题，更新进度不及时就会导致重复测试以及资源浪费。

所以非常推荐各位产品经理使用禅道、TB这样的协同项目管理工具。及时更新BUG的状态和数量，盯紧对应问题的开发、UI执行人，注意不是负责人是第一执行人。

当然项目和系统还是要依靠人力管理，好的研发管理制度可以明显减少BUG解决时间，而扮演这个角色的人几乎都是产品经理为主。

如果全部丢给项目经理或研发负责人来管，其实也是不是一个合格的产品经理。

今天的分享就在这。