ID211326

发布在即，历经一个多月的辛勤努力，团队终于完成了所有功能点，产品负责人看到成品后却皱起眉头，“呃，看上去不错，但这不是我想要的！”推到重来？OMG，还有比这更悲催的么？

这种现象在我的周围并不少见，在花费了足以建造一架过山车的成本和代价之后，发现用户实际需要的只是个轮胎做的简易秋千。。！！

 或许你会说，用户对于需求的描述很模糊，文档质量不够高，层层沟通传递下来，导致各角色间的理解偏差被一步步放大。说的没错，沟通确实是个大问题，但为什么最后做完才发现，早点干嘛去了？

在很多项目中，产品验证严重滞后。一方面需求及设计没有经过严格验证，就匆忙投入开发。另一方面，开发中间过程，一直看不到任何实质的功能成果，只能等、等、等。产品经理必须等到软件开发的尾声，才能看到可以运行的产品。而在此时，一切都已定格，再想大幅修改产品代价已非常高了。

从系统性机制上来考虑这解决个问题，最最重要的是，常常做产品验证，趁早做产品验证，确保产品一直运行在正确的轨道上。

什么是产品验证？

弄清楚要开发什么产品，准确把握并实现用户需求，并不是件简单的工作，对产品人员的要求很高。在日新月异的互联网领域，定义产品更像是一项探索工作，一步到位然后就埋头开发的模式已经越来越行不通了，必要的探索与尝试是需要的。而在迭代式的产品探索过程中，更需要迭代式的产品验证。

产品验证，包括三个方面，产品的价值，可用性，可行性。

可行性验证，在现有技术条件下，能否成功开发出产品？可行性验证需要开发及架构师深度参与进行技术调研，重点在于确认是否存在难以克服的技术障碍。如果你的产品存在可行性问题，一定要提前解决这些问题。

可用性验证，目标用户是否能够明白产品的功能特性如何使用？可用性验证需要产品人员与设计师深入参与观摩用户测试，重点在于观察用户如何设法完成操作。可用性测试能够发现那些未实现的产品需求，甚至能够发现原本被忽视的产品需求。

仅仅知道产品能够开发出来、方便使用，这还远远不够。更重要的是，目标用户是否觉得你的产品有用，是否愿意购买，有多需要和喜欢产品？价值验证可以与可用性测试同时进行，但更侧重于观察用户是否需要和喜欢这个产品及功能。

谁来做产品验证？—功能小组

提到产品验证，大多数人会想当然地觉得这是测试人员的工作。做项目像是传一个接力棒，策划做完丢给设计，设计做完丢给开发，开发做完丢给测试。最后的最后，所有的验证工作都自然丢给测试。也正因为此，价值及可用性验证一直以来却没有得到足够的重视。可问题是，测试能够为产品的价值和可用性负责吗？测试人员是产品验证的重要力量之一，但产品验证无疑需要更多的力量。

要改变这个现状，就需要将策划、设计、开发、测试的力量紧密协作，共同为产品的用户价值服务。其中产品经理、策划为产品的价值负责，用户体验设计师为产品可用性负责，开发为产品可行性负责。

功能小组是以面向用户的功能为维度来进行划分的跨职能团队，涵盖该用户功能相关的策划、设计、开发、测试等各职能部门的人员。功能小组时刻聚焦终端用户需求，以用户功能为中心，帮助团队各个角色成员聚焦用户价值，避免由于成员间职责分离而导致的工作断裂。业界的实践表明，功能小组模型在项目管理、需求管理、以及技术及构架控制等方面有着很好的扩展性。

在功能小组内部，由策划来进行统一协调各个职能组成员的工作，定义需求，并在全过程中跟踪该功能的设计及实现等各项工作。作为功能小组的负责人，策划的工作职责主要包括：定义需求；与用户体验设计师密切合作完成设计；在开发过程中跟踪需求实施（不断核实范围、控制范围）；支持并协助运营工作的开展；主导并跟进统计工作等。

项目经理协调多个功能小组之间的依赖关系，对项目整体进度负责。

如何做好产品验证？

在投入开发之前，制作设计原型进行验证，是产品验证最主要的方式。不同的产品有不同的原型，可点击的页面、或画在图纸上的设计稿等。设计总有考虑不周、出人意料的情况，原型测试能够帮助我们在项目早期发现问题。

在进入开发期后，苦于读一堆恼人的状态报告，却看不到真实的进展，那么这时如何能够更好地进行产品验证呢？你可以尝试以下几种实践方法。

方法1 持续集成

原型固然好，我们仍然希望早一点看到成品。有了持续集成，产品人员不需要干扰开发团队，就能得到最新的功能开发状况，及早发现偏差并调整。每天晚上，持续构建服务器都会从头构建产品，并发布二进制文件（ears，wars等）。如果出现问题，它就会向整个团队发送邮件告知大家构建失败。构建失败会被当做高优先级的任务，要求快速解决。

搭建并维护持续集成，需要比较大的工作量，但付出绝对物有所值。WEB类的产品也会被自动部署到测试环境中，加上自动测试，效果会更好。另外，持续构建对于开发质量也是种有效约束。

方法2 demo演示

如果顾虑持续集成的成本，你还可以选择demo演示的方式。与开发团队制定阶段性demo演示的目标与计划，分批验收功能。

 方法3 bug bash

Bug bash，又叫bug大扫除，是指在版本发布之前，发动项目的所有人员，在同一个时间段内，集中全部精力，一起找Bug。Bug bash 动员项目组一切力量，发现更多BUG，帮助从多个不同视角（产品、设计、用户、市场）来进一步衡量和检验产品。实践证明，bug bash是一种有效的产品验证方法，同时也是团队建设的好机会，对增强成员对产品的ownership大有帮助。