全文约1200字 阅读需4分钟
后台回复【今天的天】获取题图
———————————–
1\\3 产品分析
之前写了一个文章，是产品经理必须要做的25件事。但其实如果粒度再细一点，250件也不为过。这也就是为什么说产品经理不要浮于表面，而是落地到实际的项目中去，一个一个踩掉那些隐藏的坑。
这里我给大家讲四个故事，这四个故事都是属于25件事中1件事的范畴内的，却以小见大，反映出了很多问题。
2\\3 故事
第一个故事叫兼容性测试。
很多时候在回归测试的时候，可能对于某个UI的实际效果不满意，想加一句提示语或改一下控件大小。但其实前置前端开发和走查的意义就在这：UI的改造必须经过广泛的机型验证。前两天的项目中：因为一个新增了一句提示语，安卓机型没有做好适配，导致华为的机型因为底部“下巴”按键的存在，挡住了按钮。一个小小的问题直接导致了某些华为用户的瘫痪，从而被迫重新适配打包下发紧急生产版本。这件事情其实算是生产事故，无论是前端开发还是测试还是产品都有责任，但是这也体现了流程的意义：
再小的事情也要按流程做，流程保障了逻辑和质量。
第二个故事叫压力测试。
在功能扩大前期，我们与保障部门沟通好了，配好了2台服务器，支持了500并发量，同时也将统计口径和费用都一一确认，但上线的时候还是出了问题。
起因是上线的时候，我们并没有采用逐步开放，而是信任关联方和前期工作，直接开放。但不幸的是，几个不应该发生的2件事情一起发生了：
1、原本支持的机器临时故障
2、服务器供应方没有分离处理各需求方
这就造成了一项很严重的事故，前期过于顺畅的沟通，让供应方认为是小case，就没有安排专人现场支持。同时也低估了我们的并发量，没有考虑到超限情况下的处理办法，直接导致了我们的服务拖垮了整个服务器，造成了其它团队支付业务的宕机。而此时，对方只能按量级和紧急程度进行决策，临时关掉了我们的服务。这个做法直接造成了我们服务的中断，大量用户上报问题给运维。而此时关联方的情况没有知会到我们，导致了2个小时左右的恐慌，后果非常严重。
所以，不管如何约定，一定要在上线前回归压力测试，站好最后一班岗。
第三个故事叫极端情况处理。
极端情况的处理其实决定了运营、客服的压力；项目初期上线，大部分压力都集中在运营，需要时刻监测用户反馈，同时协助查找问题。
第一点，如果产品的异常情况处理很差，就会导致问题增多。比如当用户没有登录权限时，仅仅提示“您当前没有权限”是不够的，需要给出用户明确的指引来化解这个难题，让流程得以延续，比如“您当前没有权限，请联系上级授权”。
第二点是产品要做好监控机制，一旦发现某个流程数据异常，马上查找问题。用户往往会认为是网络问题而选择不断尝试，真正主动上报问题的用户并不多。而且等用户上报这个时效性肯定是无法保障的。所以做好某些关键数据的实时监测，是解决这个问题的必要手段。一个简单的例子：比如上线开放时，实时监测注册用户数量及登录用户数量，就可以判断注册登录机制是否有效，是否有大量用户被卡在BUG中。
所以，我经常喜欢和运营一起讨论极端情况，这样充满利益相关的讨论可以让团队贴的更紧密。
3\\3 总结
最后，这三件事情都是发布上线阶段的三件再小不能的事情了，但是如果三件同时发生，几乎是可以让负责人走人的。
所以，有些成功可能是因为幸运，产品经理也需要幸运，但不追逐幸运、不认同幸运。
总结踩过的每一个坑，让它不再发生。
———————————–
你的分享和评论会成为我的动力 让我们一起成长
评论(0)