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