产品验证,你做了吗?

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

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

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

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

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

 

什么是产品验证?

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

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

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

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

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

 

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

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

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

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

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

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

 

如何做好产品验证?

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

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

方法1 持续集成

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

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

方法2 demo演示

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

 方法3 bug bash

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

评论
热度 ( 1 )

© 蓓蓓—PM的修炼 | Powered by LOFTER