本篇文章将探讨产品经理验收时存在的几个问题：是否需要验收、为何不验收、验收与测试的不同及误区等，帮助大家了解验收的内容，希望本篇文章能对你有所帮助。
最近，在一个产品沟通群里，产品经理们又炸开了锅，起因是其中一名产品经理提到自己公司的产品上线之后，功能与业务不符，测试将这个“锅”甩到产品身上，认为产品没有做好验收，而产品认为这本身就是测试的工作。
于是，产品经理们开始在群里疯狂吐槽各自公司的测试人员，我看到了“一致对外”，但却没看到任何人在反省产品经理到底应该如何验收才能避免这样的事情再次发生。
这个问题的答案是肯定的，产品经理一定要做验收，至于其必要性，我们看一看产品经理不做验收会产生什么后果就知道了。
按产品与设计的偏离情况，可分为3种：
1）不符
这种情况指的是产品与设计有偏离，但无伤大雅，甚至可以不按原设计调整。
比如一个原本应该用红色级别的 Toast 提示被开发成黄色级别，由于红色和黄色在系统中均有表示警告的含义，所以这个偏离也不是不可以接受的。
2）一般不符
这种情况指的是产品与设计有较大偏离，可能已经影响到产品的使用。
比如一个原本通过弹窗提示的内容被开发成出现一定时间后自动隐藏的 Toast 提示，这个提示文案是在持续等待一段较长时间后出现（比如上传大文件，或系统处理较多数据的场景下）。
期间用户的视线可能离开产品界面，弹窗提示可以在用户回来后看到执行结果，而自动隐藏的 Toast 提示用户可能会错过。
3）严重不符
这种情况指的是产品与设计严重偏离，已经严重影响到产品的使用。
比如设计约束一个手机号只能注册一个账号，注册时，已注册的手机号不能注册成功，但开发的时候漏掉这一步，注册时可以使用同一个手机号注册多个账号，导致登录时系统无法识别具体要登录哪个账号而出错。
这种情况未必是因为产品与设计不符造成的，而是可能产品设计本身就与业务不符，产品的存在是为了服务业务。
所以一旦产品出现与业务不符的问题，则每一个问题都可能是致命的。
产品设计与业务不符需要通过调整错误的需求实现来满足业务，这必然会带来需求的变更。
发现错误的设计或实现，需要推翻原来的工作成果，重新设计和开发。
无论需求变更还是返工，都会使原本规划好的进度落后。
出现问题，大家都觉得不是自己的责任，开始互相甩锅。
既然产品经理验收环节这么重要，为什么产品经理们却不喜欢做验收呢？
产品设计的过程是一个探索和创造的过程，对产品经理而言是一个充满乐趣的过程，多数产品经理在完成产品设计交付给研发的时候，都会有一种“这是目前我能做出来的最棒的设计”、“不可能有比这更好的设计方案了”的想法。
而验收就不一样了，虽然交付的是设计，验收的是产品，但产品经理会认为自己的设计很清晰，不应该有人会误解，甚至会有一种“我的设计这么棒，竟然让我给自己的设计挑毛病”的想法。
有的产品经理会认为，设计交付给开发之后就没有自己的事了，最多在开发过程中帮开发厘清一些有疑问的地方，后续其他工作则与自己无关。
一般版本的研发时间由研发部门来确定，而研发部门在确定版本时间的时候，只会将测试的时间考虑进去，而不会考虑产品验收的时间，产品经理验收时间不够，验收没有效果，久而久之就没有了验收的习惯，测试通过就上线了。
产品上线后出现问题，首当其冲的就是测试，接着就是产品经理，最后就容易演变成两者的相互“甩锅”。
究其原因是因为公司或部门对二者在产品验收和测试环节的职责范围没有明确划分，最终只能由管理者来确定应该承担责任的人，一般如果管理者是研发负责人，会将责任归咎于产品经理没有做好验收，而作为产品负责人的管理者则会认为是测试人员的测试工作做得不到位。
因此，产品研发两个部门经常“打架”，这也是其中的原因之一。
关于产品经理验收和测试人员测试的区别，我大概列了以下几点，各位可以根据自己项目的实际情况参考一下。
看了以上对比之后，你可能会产生一种想法，觉得产品经理的验收好像很随性，没有明确的标准，没有量化的工具，甚至没有明确的目标。
的确，明确产品经理验收这个环节在业内并没有形成相对统一的标准和方法，更多靠的是产品经理个人的经验和在验收时的敏锐程度。
因此每个产品经理也都形成了一套属于自己的验收经验，一名优秀的产品经理经常能够发现很多测试都难以发现的问题。
下面根据本人以往的一些项目经验，简单总结一下，产品经理验收，到底是验什么？收什么？
1）验业务
产品经理是离业务和需求最近的人，也是接收业务信息和需求信息“失真率”最小的人，验收的时候，优先要考虑的是产品到底能不能满足业务，或者对业务目标有没有帮助，而不能一味考虑产品是否与设计一致。
所以产品经理验收产品的时候，需要代入业务目标。
一个功能，如果能够满足业务目标，但是与设计不一致，在不会影响其他功能或交互的情况下，也是可以被接受的。
因为实现同一个业务目标有时候不一定只有一种设计。
2）验设计
“不能一味考虑产品是否与设计一致”不代表可以不考虑。
上文说到，产品经理验收的时候不像测试人员一样有测试用例，所以产品设计就是最好的验收标准。
按照设计来验收是最快的验收方式，只是在碰到与设计不一致的功能实现时，优先要判断的是实现与业务是否一致，而不是不管不顾地推翻已经做完的功能，要求重新按照设计来做。
3）验场景
场景指的是业务场景，这个环节也是产品经理最容易发现测试人员发现不了的问题的环节。
测试人员对业务的了解基本都是通过产品经理的传递，测试时，针对的业务场景比较单一，产品经理因为对业务的了解更深刻。
因此在测试时，可以挖掘到更多的业务场景，也更容易发现不同业务场景下的问题。
1）版本基准
当前版本已经验收通过，可以封版发布，所谓的版本基准就是最终发布的版本内容，有些人可能会说，那不就是版本规划吗？其实不然。
版本规划指的是计划要实现的功能，版本基准指的是最终实现的功能，在特定情况下，版本基准等同于版本规划，但更多的时候，版本基准与版本规划总是会有一些不同。
因此需要将当前的版本基准记录下来，否则如果以后按照版本规划回溯当前版本的时候，会发现实际实现的版本与规划的版本并不完全一致。
2）问题清单
“我们需要尽量发现问题，尝试解决一些问题，允许存在一些问题。”这是验收版本时的一个核心思想，你不可能解决所有问题，因为问题会不断出现，所有尝试为了解决所有问题的行为最终都可能会导致版本延期。
所以要有选择性地解决一些必须在上线前解决的问题，并允许一些无伤大雅的问题存在，当然，这些问题并不是就此放任，而是需要记录下来，形成问题清单，在后续的版本中逐步解决。
3）迭代计划
迭代计划除了来自业务的发展和变化，同时也来自验收，验收过程中记录的问题以及发现的新的需求，将形成新的迭代计划，并入到新版本的规划中。
产品经理验收环节容易陷入这个误区，这些误区容易导致验收不充分。
产品经理在验收某些功能的时候，容易陷入一种误区，觉得自己的设计逻辑是很简单、很符合直觉，或者这是一个常识性的约束，不会有人理解错误，因此就不加以验收。
比如大家都会认为在使用手机号注册账号的时候，如果手机号已注册，是无法注册成功的，产品经理认为这是一个常识，哪怕自己没有在文档中写出来，开发应该也会这样实现，验收的时候也无需针对此项约束进行过验收，结果产品出来的时候，同一个手机号可以重复注册，导致登录的时候系统出错。
要避免这个误区，首先在设计的时候，即使是常识性的约束条件也应该清楚写进文档中，并在开发完成后逐项验收。
同时，要正确理解研发人员的工作方式和工作思维，很多时候是几个研发同时开发一个业务功能，每个人只负责一个子模块，从他们的角度，很难在脑海中拼凑出完整业务的形态。
所以只能根据设计和文档进行开发，设计和文档中没有的内容，他们是不会主动添加进去的。
这种就是验收前没有什么计划性，看到哪验到哪，想到什么验什么，这种“随心”的验收方式很容易忽略掉一些场景。
虽然产品经理验收不像测试那样有严格的测试用例，但要避免验收场景不充分的误区，最好在验收前先有一份“场景验收计划表”。
计划表主要需要包含验收的场景、准备的数据、预期验收结果、实际验收结果。如果可以，提前准备好数据值，这样验收的效率更高，准备数据值的时候，注意需要准备多个，主要需要错误的数据值、正确的数据值以及边界值。
下图是我针对注册登录环节验收整理的部分场景的验收计划表，仅供参考：
开发说修复完了，测试说测试通过了，结果产品一看，全是 bug。
这种主要是到了产品后期准备上线的时候经常遇到的问题，产品发现一个问题，开发就改一个地方，测试就测一个地方，导致其他有问题的地方没有被发现。
这种情况一般是需要多方去规避，比如公司应该有明确的测试流程和管理制度，研发规划时间的时候需要冗余足够的时间，产品经理应该充分阐述清楚业务场景等。
以上便是本文的全部内容，感谢阅读。
专栏作家
产品锦李，公众号：产品锦李（ID：IMPM996），人人都是产品经理专栏作家。不务正业的产品经理和他的产品设计。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。