产品上线后用户问题如何处理？

用户反馈问题处理流程
创建一个独立的项目，仅用来收集线上反馈的用户问题，可以以公司中现有的项目管理系统或缺陷管理系统为依托，如果公司产品较多，且相对独立的话，可以以产品为单位各自建立XXX产品用户反馈项目，如果产品之间相互依赖或是同类型的，则可以放在一个项目下，自定义字段设定所属平台或所属产品线（在统计时非常必要），所有的问题都会归属在相对应的产品线下。

用户反馈->提交登记问题->测试复现->测试负责人区分->优化或变更指向产品排期-缺陷区分是否必现->针对必现问题进行初步诊断->指向对应开发负责人->开发修复后部署测试环境->测试回归->申请发布版本->发布->通知对应问题提出人->复盘

以上流程的细节点：
1、用户反馈
要考虑不同用户的问题来源，
终端用户：如终端用户属公司外人员，则需要通过电话或聊天工具告知内部员工（客服、项目经理、产品人员或管理层等）内部用户一般口头或聊天告知项目组成员
项目组内成员收集
测试人员回归测试收集

2、提交登记问题
账号只开放给部分项目组成员，运维人员、客服人员等（依公司的职责分配）

3、测试复现
测试人员进行复现并初步诊断，并区分出问题，并将问题原因进行归类，并描述具体原因，部分原因可以由开发人员补充，对于前后端问题参考《如何区分前后端的Bug?》
对于典型问题一定要备注好问题类别，具体原因以及解决方案，下次翻出来时可以直接参考

4、申请版本发布
通常测试人员回归通过后需要发起版本申请，可以与正式版本合并发布，对于紧急问题可以申请临时版本。要注意关联数据和平台的回归。

5、通知对应的问题提出人
这一步可以分情况讨论，如是内部用户，可以在版本发布邮件中艾特对应人员即可，如是外部疑问用户提出，则艾特提出人后以反馈形式回复，如在平台支持的用户反馈通道或是邮件告知。（但无论问题能否得到解决，都一定要把结论及替代的解决方案告知到终端用户）
至此，整个问题从提出到解决已完成，实现了“从用户中来到用户中去”
那么，如果仅仅是重复以上的流程，即使响应再快，也一直是解决问题的角色。
对于测试人员及项目组成员来说，这些问题无疑是最宝贵的知识资产。那也就到我们的最后一步了–用户反馈复盘

6、复盘
如果测试组内已有固定的月度复盘会议，可以直接加入这一项；也可以在周例会中提出，总结下当周的用户反馈情况与状态，如：
（1）本周新增XX个问题，主要集中在XXX区域
（2）严重问题有如下XX个，如：连续两次修改审批预算金额时扣费数据为负数
（3）本周需重点关注以下问题：XXX
（4）结论部分：问题跟进状态，其中因业务流修改造成的误操作共XX等
（5）列出本周的问题分布图，可以根据实际情况来自定义维度，不同模块的问题归类，以为下一个周期避免踩雷。

每周邮件
复盘总结完成后，发送邮件给项目相关成员。
项目过程复盘也是一个长期收益的过程，尤其是测试人员，当我们坚持一年后，再回头过来看第一次的复盘内容，对比之下，是一个量变到质变的过程，除了提高测试质量及覆盖面外，测试思维的提升与站在用户角度的思考过程是附加值，目标导向与深度工作方式是可以终身受益的。

综上，我们已经了解了整个用户反馈问题的跟踪流程，但中间有很多细节还是需要灵活把握的，如问题的难易程度 ，优先级排序 ，项目组排期，以及偶现的问题与特定场景的操作，问题影响范围，以及与项目人员的沟通问题(如对项目复盘细节感兴趣欢迎来知识星球讨论交流~)