如何更加高效的管理产品 bug？

盘点bug管理流程

“bug管理”应该是所有互联网企业必不可少的工作内容之一，但是同行们针对这项工作的解决方案各不相同，我经历或见过如下几种：
1、小团队日常使用产品过程中遇到bug，直接找开发人员沟通、确认，然后开发人员记录，视bug紧急程度马上或稍后集中处理；
2、稍大点中小团队往往让技术人员开发一套异常简陋的“bug管理”系统，按照通用的bug管理流程进行系统设计，忽略UI、交互等等一切“次要”元素，保证顺畅基本职能；
3、购置一套“bug管理”软件进行bug管理。
第一种情况并不常见，是小团队在技术力量不足、资源不足情况下的无奈妥协，弊端也最多。
第二种就是我经历过的亲身体验，这套内部的bug管理系统如果忽略用户体验要素，基本上能够满足正常流程：纪录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除。自己开发bug管理系统虽然投入成本高，但是可以根据团队工作习惯定制化。但就是有一点麻烦：这个bug管理系统并不是团队每个成员经常登录的系统，这就导致遇到bug时，需要经过“找出收藏的网址→登陆→依照指标输入详情→阶段性查看最新进展”，如果遇到这个bug是用户向你反馈而后你输入到bug系统时，你还需要等几天后给出反馈。
这冗长的环节和时间等待，让我有点失去耐心，等到后来遇到用户反馈的bug我往往直接找技术反馈处理绕过bug管理系统。这样做肯定会影响到技术人员的工作效率，打断其思路，是非常不好的工作习惯。
第三种我倒没经历过，严格来讲，现在市面上“bug管理系统”也算是SaaS同行，但是这块业务前景真的很小，一是互联网公司开发bug管理系统并不困难，二是其未来的延展性并不大，所以市面上并没有非常知名的“bug管理系统”。
购置“bug管理系统”还是会遇到和第二种一样的境况，不经常提bug的人往往会绕过管理流程而直接找技术人员反馈。

那有没有一种解决方案相较于上面三种方案：
1、节省企业成本；
2、降低“bug管理系统”使用门槛；
3、照顾技术人员处理方式；
4、照顾提bug人员、处理bug的技术人员、甄别bug的产品经理使用体验？

我们日事清产品、研发团队的bug管理流程相较于上面三种解决方案具备这四个优势。我们把bug管理流程分为如下几个状态：收集→确认→其他→暂缓bug→开发中→测试中→已解决→发布并通知用户→重复问题→提醒问题。

bug管理.png

bug管理1.png

处理流程为：提bug人员将bug输入到“收集”状态，由产品助理/产品经理集中处理，视bug具体情况将bug拖拽到其他集中状态。如果拖拽到“确认”，在该bug下添加技术人员让其处理，技术人员会在日事清协作系统内收到通知并且bug同步到其收纳箱，方便技术人员集中处理，解决后由技术人员拖拽到“已解决”状态卡片。

如果bug是由用户反馈，那么在bug详情中记录其联系方式，由提bug人员跟踪该bug状态，修复后告知用户。如果产品助理/产品经理甄别bug时需要和相关负责人员沟通，不会直接联系技术人员，而是在bug评论中评论沟通。

相比上面三种解决方案，利用日事清计划模块进行bug管理具备如下优势：
1、日事清是团队成员办公平台，不存在增加团队成员使用成本问题；
2、由产品助理/产品经理集中甄别bug并和技术人员延时沟通，杜绝其他成员直接联系技术人员询问打扰其工作；
3、如果bug状态发生改变，比如“已解决”、“评论沟通”等，提bug人员会收到通知，可以实时跟进bug状态，提bug人员更可阶段性点击“bug管理”模块查看实时状态；
4、无需单独购置一套bug管理系统，直接在办公平台流畅解决；
5、相比独自开发的bug管理系统，具备更优秀、顺畅的使用体验。

作者 henu王凯

关键字：产品经理, bug

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！