产品线上交付阶段出现的两次显著Bug分析
前言
近期,部门内部的A
项目在线上使用时出现了两次较为明显的Bug
。作为负责A项目需求梳理、原型设计和功能验收的产品经理,我将从这一角色出发进行思考和总结。
问题描述
-
前端页面编辑一个输入框时,显示“入参错误”。 -
前端页面修改模块 A
时,模块B
和模块C
的同一参数输入框出现联动,都变为了模块A
的值。 -
前端页面调用的字段和后端定义的功能没有对应上。
问题分析
-
问题一的主要原因是后端相关的功能只发布在了开发和测试环境,而正式环境没有发布。 -
问题二的原因是模块 A
、B
和C
中同一参数是抽取复用的,但前端在处理时,没有使用对象解构赋值{...parameter}
来创建一个新的对象副本,而是直接引用了同一份parameter
对象导致。 -
问题三的原因是需求文档显示,前端在开发时,已经和后端同事约定好参数字段一一对应,但在后端实现时, 沟通上面信息没有同步到位,字段和预期的不一致,导致功能出现异常。前端开发人员没有真正从 用户角度出发,验证功能是否完善。产品交付时,产品经理没有依据需求文档进行验收,做好输入和输出两个关键部分,形成 闭环。
经验教训
-
当需求中出现大量专业性较高的参数字段时,需要在需求文档中说明清楚,确保信息同步,毕竟这些不是像 username
、mobile
、email
等常识类的字段。 -
前端在开发功能后,通常容易陷入只要保证自己实现的功能页面增删改查没有问题,就可以了。很少多想一步,从用户角度出发,模拟用户的使用场景,然后再次确认功能是否正常,这个意识还是很重要的。因为一个功能模块不仅仅涉及前端,还有后端,功能的验收要结合后端进行,这个时候没办法把职责划分那么清晰,只能前端主导,后端配合,把整个功能模块验证流程都走一遍,而不是浮于表面。 -
在部门里,期望产品同事参与到项目中,具体除了整理需求文档和原型设计,最终的交付也是很重要的,这就需要产品切实参与到版本功能的验收,确保和预期的需求一致。这方面曾涉及到对研发的 信任问题,其实和信任没有关系,能力再出众,功能做得再好,如果理解错了需求,最终交付的不是需求的本意,那也是有问题的,所以产品参与最终版本的功能确认,是很关键的一环。就好像封装一个函数,输入和输出,先不管函数里面到底是怎么实现的,最终还是以函数输出的结果为重,函数给的结果都不对,里面用了多好的技术和巧妙构思,都显得苍白无力。所以,产品对于每一个需求点,需求->验收,应形成 闭环。 -
潜意识里还是觉得是内部的项目,导致重视程度不够,而且,忙并不是借口,对于负责A项目的产品工作来说,验收形成闭环这一块确实懈怠了,本就应该按标准的项目流程去走,必须做的就要去做,没办法省略掉。
预防措施
-
验收环节需提供详细测试用例,并且分为三个环节:研发自测、项目负责人验收和产品交付验收,基本覆盖了这个功能的开发人员、这个项目的负责人和这个需求的提出人。 -
发版节奏放缓,确保各个环节都做到位。贪图求快,功能质量出现问题,工作结果还是大打折扣的。
本文由 mdnice 多平台发布