早发现BUG好于晚发现，自己发现好过用户发现

2020-12-11 09:18:49 阅读（144） 评论（0）

如果产品和开能还能就两件事达成共识，那么除了喜欢苍老师，另一件事一定是讨厌bug。但是，所有与IT相关的人都必须熟悉BUG。但话说回来，早发现bug比晚发现好，自己发现比用户发现好。与此同时，BUG的修复和改进也是产品日益完美的必由之路，真是令人讨厌的BUG。bug定义bug的意愿是臭虫，可见人类对bug的厌恶。现在主要用来描述软件中隐藏的一些未发现的缺陷或问题，也可以算是性匹配。bug通常发生在开发过程中。每当开发完成部分开发工作时，测试、产品或设计师都需要评估和测试开发阶段的输出（测试包），由此产生的问题将属于bug。有些bug可以立即修复，但有些bug可能需要较长的开发周期，因此在下一个测试包输出阶段会产生新的bug。一般情况下，bug需要根据优先级进行安排。在bug分类工作中，我通常用三个级别来定义bug级别：严重、一般和轻微。严重bug：不能使用功能，或者用户因为一些漏洞而受损。比如平时用手机经常遇到的软件闪退、死机等，都是严重的bug。严重的bug是不可接受的，产品上线前必须保证没有严重的bug问题(或在较低范围内)。一搬bug：问题明显，但不会影响用户的正常使用或损坏，一般是由于功能实现不彻底或冗余造成的。例如，常见的点击按钮不能第一次响应，需要再次点击才能激活按钮。或者网络环境明显正常，但账户登录需要很长时间。在产品上线初期，一般bug总是占据bug问题的大部分，一般bug在产品更新迭代过程中需要不断修复和消除。轻微bug：用户在正常使用状态下不会感知细节，如图标尺寸、字体颜色等。轻微bug一般属于需求实现不完全或等同于新需求。在早期的界面开发中，产品经理可以尽可能吸引设计师，根据帧级检查开发的相关界面问题，确保开发完全按照设计草案实现，避免后期因界面调整而浪费能源和士气。bug处理下图是bug处理的简图，bug主要由测试、产品评估、开发解决等方面提出，缺一不可。重点处理严重bug问题：一般来说，如果产品想要稳定发布，必须解决所有严重bug问题。但实际情况并非如此。有两种情况可以讨论严重的bug：一种是受外界影响的不可控问题。例如，手机产品经理必须认为用户手机死机的问题是优先级最高的问题。由于用户使用手机环境的复杂性，很难完全避免死机。对于这类问题，需要设置阈值，当手机崩溃率高于此范围时，必须处理；低于阈值，将被认为是合理的，不需要花费太多的精力来修复。一般情况下，软件的崩溃率应控制在万分之五以下。例如，如果手机qq每天启动100W次，则允许qq每天崩溃100W*5/1W=500次。若高于此值，则为异常情况，必须处理问题。二是内部核心的可控逻辑。比如像支付宝这样涉及金钱交易的金融软件，产品逻辑相当复杂，可能会有一些闪回崩溃的bug，这是可以接受的。然而，与内部支付相关的主要逻辑必须是完美的，没有漏洞。否则，在执行过程中，任何问题都会导致用户资金损失，这是一个重大事故问题。产品要记住的是，对于一个产品来说，bug总会存在，因为软件的外部环境是基于人员交接的内部逻辑调整。bug的修复只是产品迭代的一部分。解决bug不能作为产品规划和发展的方向。勤奋的行为不能掩盖战略懒惰。产品经理的主要目的是在产品体验和商业模式之间找到平衡，以吸引用户和实现商业目标。

内容来源:人人都是产品经理，以上内容来源于网络，不代表本站观点，如有侵权，请联系删除。

上一条：给社交媒体的运营或管理人员的11条建议下一条：不同类型的账号和目的，有完全不同的历程

商标/知识产权

网站服务

CRM/销售管理

ERP/智慧办公

财税人力

安全/技术支持

其他应用

商标版权

小程序

早发现BUG好于晚发现，自己发现好过用户发现

推荐阅读

猜你喜欢

分类

最新文章