高频问题的“生命周期”

见贤思齐

说到“生命周期”这个词的时候，脑海中首先浮现的是学习安卓编程语言的生命周期了。尤其是 Activity 这一块， Activity 生命周期的第一个方法-- onCreate() 表示创建，这个方法也是我们在 android 开发中接触的最多的生命周期方法。它本身的作用是进行 Activity 的一些初始化工作，比如使用 setContentView 加载布局，对一些控件和变量进行初始化等。但也有很多人将很多与初始化无关的代码放在这，其实这是不规范的：此时 Activity 还在后台，实际是不可见的。所以动画不应该在这里初始化，因为看不到……因此在合适的环节做合适的事情尤为重要。那么，高频问题在技术支持岗位管理中有哪些“生命周期”呢？我将其分为四个阶段：问题暴露阶段、信息传递阶段、问题解决阶段、问题回顾阶段。本文着重讲第一个阶段，后三个阶段欢迎阅读《如何推动高频问题产品化？》在问题暴露阶段，有两个场景的高频问题非常具有特色：新功能上线导致的高频问题，起始时间非常明确，就是上线时间，但反馈的问题可能较为分散，一般有使用姿势不当导致的咨询、不符合逻辑的反馈、在某些场景不适配、不兼容、未闭环的问题。在这个场景上，技术支持需要熟知产品逻辑、功能背景，抽茧剥丝，找到问题点，并收集相关反馈的数据。还有一种场景是在长期的问题处理过程中，商家反馈的问题是符合业务逻辑的，但是需要我们查询数据库等方式证明确实符合业务逻辑，有些问题查询一张表可以解决问题，但有些问题较为复杂，需要我们查询多张表，多个工具才能解决。这个场景，问题在于如何把繁琐高频的整个查询流程，缩短处理时间、简化查询步骤，甚至是让商家可以自查作为推进方向。如何发现问题在这个场景尤为重要。常见的方式是给问题做标记、做分类，举个??：我们把订单状态流转分为下单、支付、发货、交易完成、交易关闭、退款几个节点单拿退款这个节点来说，用户可能出现的疑惑点主要有：为什么没有退款入口为什么有了退款入口操作退款报错为什么我只能申请这个退款金额为什么退款还没有到账为什么退款的金额少了类似这样的疑惑点，背后可能存在多个原因，比如针对「为什么退款金额少了」的疑问，可能存在如下原因：下单的时候享受了优惠，部分退款的时候，本身享受到的优惠不会以金额的方式退回发起维权的时候使用了上门取件，需要支付上门取件的运费，运费需要扣除掉。那么根据问题出现的环节，以及将上述问题现象、问题可能的原因进行清晰的罗列以后，进一步站在产品的使用者的角度进行思考：消费者购买了商品，需要进行退货，发起维权的时候使用了上门取件这个功能后，为什么消费者还会来咨询退款费用变少了？是文案没有提示还是提示的不明显？是不应该从退款金额扣除，而是需要消费者自己单独支付运费？此时我们就能从实际的产品功能中得出可能可以进行产品优化的方向，并提供给产品研发我们的产品改进建议来减少这类高频问题的出现了。那么，如何锻炼自己这种抽茧剥丝的思考能力呢？我这里建议回归生活，从生活点滴中发现问题，发现解决方法。再举个??前几年我去银行办理业务的时候，需要先在柜台取号，取号之后在等候区等待被叫号的时候才知道自己可以在几号柜台办理业务，等候的时候会发现前面有很多号，呼叫三次后还没有人来办理业务，就继续呼叫下一个号，那么因各种原因错过了叫号的客户，只能重新取号排队，浪费了前面的等号时间，如何让排队叫号办理业务的客户拥有更好的体验呢？我最近发现医院是这么解决的：进入医院后，挂号的对应科室前有签到机，需要签到后才会排在叫号的系统中，并且叫号顺序是根据签到时间排序的当然，医院和银行不同的是，医院可以提前在各种平台上预约一周内的号子，银行则是现场取号，或者两个行业之间还有其他点的不同，导致银行不能借鉴医院的方法，但这不能阻碍我们去发现、类比、解决自己遇到的问题。在高频问题的整个生命周期中，如果你也有相关实践，欢迎后台和我们一起讨论交流～