文章源自略懂百科-http://wswcn.cn/19128.html
导读：产品研发上线之后，难免会出现BUG。当发现BUG，我们应当如何去定位问题、排查问题、解决问题？本文作者从四个维度进行分析，希望对你有帮助。文章源自略懂百科-http://wswcn.cn/19128.html
产品研发上线运行，难免会有BUG。文章源自略懂百科-http://wswcn.cn/19128.html
BUG的发现，可能是内部人员（项目团队成员、领导等）、或者外部人员（甲方爸爸、用户、合作方等）。文章源自略懂百科-http://wswcn.cn/19128.html
BUG从优先级角度可分为：高、中、低。文章源自略懂百科-http://wswcn.cn/19128.html
严重程度可分为：一般、严重、致命、建议。文章源自略懂百科-http://wswcn.cn/19128.html
我们应该避免BUG被外部的人员发现，避免被投诉，应该内部及时消化。文章源自略懂百科-http://wswcn.cn/19128.html
当发现BUG，我们应当如何去定位问题、排查问题、解决问题？文章源自略懂百科-http://wswcn.cn/19128.html
以下一些思考，供交流探讨。文章源自略懂百科-http://wswcn.cn/19128.html
01 从开发/测试角度，面对BUG的想法？期望/顾虑？文章源自略懂百科-http://wswcn.cn/19128.html
关键词：信息的全面性、完整性。文章源自略懂百科-http://wswcn.cn/19128.html
直接说结论。为了更高效定位问题解决问题，提升沟通效率，可以参考以下维度进行问题反馈，进而提供更完整、全面的信息。文章源自略懂百科-http://wswcn.cn/19128.html
什么业务：某模块、某业务……什么时间：具体几点几分具体问题说明：谁的账号或单号，什么时间，什么业务，做了什么动作，发生了什么，出现的问题是什么，正常/期望应该怎样设备终端（XX 小程序、XX app、XX 管理后台等）以及软件版本、机型、设备系统版本附上操作视频/截图/步骤说明（甚至补充语音解说便于理解）自我检查是不是自身配置影响导致的（比如优惠券设置了使用时段、限制了使用菜品、自己手机消息接收设置没有打开等）紧急度、提出人、提出时间、希望何时解决等文章源自略懂百科-http://wswcn.cn/19128.html
对于BUG提出人，通过以上的自我检查后，就能相对全面完整的提出BUG，极大程度提升技术同学排查问题的效率。文章源自略懂百科-http://wswcn.cn/19128.html
从甲方爸爸角度，02 面对BUG的想法？期望/顾虑？文章源自略懂百科-http://wswcn.cn/19128.html
关键词：影响面、问题本质、解决时间、临时方案、解释词文章源自略懂百科-http://wswcn.cn/19128.html
此异常会影响哪些业务正常运转？我应该做哪些动作才能保障各业务口正常运转？有哪些临时的解决方案？（eg.发通告、转线下处理、临时下架服务…）到底什么问题导致这个BUG？为什么出现这个问题？技术团队要如何解决这个问题？如何避免下次再发生？什么时候可以解决？我要怎么跟领导解释？文章源自略懂百科-http://wswcn.cn/19128.html
从项目负责人角度，03 面对BUG的想法？期望/顾虑？文章源自略懂百科-http://wswcn.cn/19128.html
关键词：影响面、问题本质、解决时间、临时方案、协同流程、责任追溯问责文章源自略懂百科-http://wswcn.cn/19128.html
前3条同上鸟览全局分析：全盘考虑临时方案的衔接、上下游、影响业务范围、甚至影响哪些人物利益反省项目团队的协同流程是否有问题，从而导致这个BUG的发生？谁的责任，谁的问题，导致这个BUG发生？要怎么做才能避免再次发生？04文章源自略懂百科-http://wswcn.cn/19128.html
产品经理接收到BUG反馈，有哪些注意事项？如何妥善分析处理？文章源自略懂百科-http://wswcn.cn/19128.html
1）几个注意点文章源自略懂百科-http://wswcn.cn/19128.html
特别对于新人，刚上手业务，对于BUG，不急于下结论做决策，凡事存在，必有理由。事前先了解事物来龙去脉，当时的干系人在什么场景、基于什么理由、数据、事实考虑了哪些因素，做了哪些利益权衡，最后才做的某个决策，导致了现在某个问题。理想的业务流程是如何，目前出问题的是如何，两边的差异在哪里，是什么导致的，追溯本质识不足则多虑如果你是新人刚接手产品，理论上产品相关的信息，那些开发、测试同学比你理解的更多更深刻。处理bug前，先保证你的认知和对方的认知达成一致，再开始思考解决方案，这样可以避免一些坑。其次，方案定稿后，一定要同步相关方日常要花时间全面理解、熟悉需求背景（是什么？为什么？过去、现在、未来）设计目的、业务流程、功能范围、干系模块之间的关系等。在没有达成共识前，不要着急下定论，多把时间放在思考和沟通上，否则你的解决方案很可能适用性不强也会有BUG最后再多问一句，你的方案一定是最好的吗？你抓到需求的本质了吗？能够适应未来灵活的变动吗？找相关方交流探讨了吗？不要闭门造车哦文章源自略懂百科-http://wswcn.cn/19128.html
2）BUG问题应对思路文章源自略懂百科-http://wswcn.cn/19128.html
获取登记干系人所反馈清晰、完整、全面的BUG问题描述（图文视频）判断是否相关系统配置问题（如职员在A系统的离职状态，影响了在B系统的正常运转）判断是否相关系统异常（第三方对接的短信欠费、SDK对接的im欠费）判断是否使用者操作不当（必现问题还是偶发问题）定位具体哪个终端、系统版本、设备版本确认业务模块开发负责人、测试责任人，将反馈问题给他们，此时要站在解决问题人的角度提供必要的信息数据（由测试同学登记tapd跟进）排查得出问题本质是什么确定修复方案、复测时间、更新时间答复客户，以及给出临时解决方案（信息同步：留档、记录、依据）复盘未来如何避免此类问题？改进原来的协同流程，沉淀原则文章源自略懂百科-http://wswcn.cn/19128.html
作者：洋葱，产品经理一枚，分享产品思维、职场干货，微信：cctvqqwwee，公众号：洋葱锦囊文章源自略懂百科-http://wswcn.cn/19128.html
本文由 @洋葱 原创发布于人人都是产品经理。未经许可，禁止转载文章源自略懂百科-http://wswcn.cn/19128.html
题图来自Unsplash，基于CC0协议文章源自略懂百科-http://wswcn.cn/19128.html
文章源自略懂百科-http://wswcn.cn/19128.html
评论