在工作中，产品经理经常会遇到重复类似的case，不过每次的解决方案都是治标不治本，占用了产品经理大量的时间与精力。而本文结合这一现象，总结出了如何更彻底地解决单点case与系统case的方法。
上周我发起了一个投票，大家最想了解的topic是：如何从杂乱的case和数据中提取优化点。
遇到case，常见的思路就是先定位原因，再设计方案。难的是如何更科学的定位问题、更彻底地解决问题。
被动解决单点case
小林正在准备会议需要的数据，运营同学小贾就急匆匆地跑过来。
“小林，你咋不看消息？同一个用户签合同，价格差了不少，快看看什么问题？”
“不会吧？”小林心里不信，但还是认真在看小贾扔过来的case。
“赶紧处理一下吧”小贾很是急促，“一线正忙着签单呢！”
“可能是重签合同手机号不一致，我找研发查一下”小林赶紧拿着手机去找研发。
这样的场景是不是很熟悉？很多产品经理每天都会花很多精力在类似的case上，初入职场的同学更是常见。
那么例子中为什么会出现价格不一致的case呢？
因为在之前的产品设计中，价格是通过合同中的手机号进行获取的。因此，同一个用户，签了2次合同，获取了两次价格。用户使用了两个手机号，因此被视为两个用户。
类似的单点case，大多是因为需求设计有漏洞，测试时也未曾覆盖完整的场景。需要我们优化产品方案，根本性解决问题。
俺么如何设计彻底的解决方案？具体如下：
因为同一个人可能拥有多个手机号，因此按同一个手机号定义，会出现手机号不同，就被视为不同用户。
在同一个用户才对应同一个价格的设计下，显然不合理。
有些朋友说，那就同一个身份证号，这总不会错吧。但真的可以吗？
如果丈夫签完合同信审不通过，需要换妻子签合同呢？是否也会面临价格不一致的问题？
看起来，真实场景中，我们需要定义的是同一个合同，而非同一个用户。这可能是最初设计时被忽略的点。
用两次的合同号进行关联？只要重签的合同id与之前的合同id在系统中进行关联，就可被视为同一份合同？从而享受同一个价格优惠？
好像问题到此为止了。真是这样吗？
你就不好奇：为什么要重签合同？
是不是买卖双方在合同的后续流程中遇到了问题，需要更改合同内容。但是更改合同内容需要重新签订一份新合同。而需要更改的合同内容又可能影响了价格的获取。
既然如此，是否可以考虑在合同流程中，用合同中填写的手机号进行优惠券申领，领取后自动计算合同价格？而不是把申领价格优惠和签订合同两个流程断开后再进行匹配关联。
设计彻底的解决方案，需要打破砂锅问到底——case真正产生的原因是什么？这样真的可以解决问题吗？
在最初设计时，调研清楚线上真实的闭环场景，列清各节点可能出现的情况。
在产品方案中进行针对性的优化，大概率可以规避掉上线后的case频发。
单点case需要具备批判性思维，追求根本性解决问题。
主动定位系统case
一大早刚到公司，小嘉就开始例行监控盘点。嗯，整体数据表现比较稳定。
“小嘉，你看看这个宝马3，价格有点异常啊！”
“还有这个五菱宏光，怎么放了这么久还没有卖掉？”
“对了，昨天那台东莞的奥迪A4L，到底怎么回事？”
“……”
突然一下子，微信窗口跳出小蔡的夺命连环@。小嘉整个人都不好了。
这些问题无非就是那些原因，都给她解释很多遍了。每次换一个case，同样的问题又会被再问一遍。小嘉耸肩表示无奈。
看到这里，你不禁会问：小嘉如何确认这些问题都是之前的原因呢？
小嘉也没那么确定，只不过查的次数多了，自然重复原因的复现概率比较大。
另外，小嘉还有更重要的事情要做，怎样才能从这些工作里面解脱出来呢？
这类看似散乱无章的问题，其实都可以通过定义一套指标解决。系统地归类case，就可以帮助小嘉和小蔡清晰地定位问题。
在上面的例子中，就可以考虑设计一个价格水平的指标，以及在不同的业务节点中指标的计算逻辑。
这里需要深入思考：
价格水平在业务中的真实含义是什么？
在这样的指标定义下，什么是good case、normal case和bad case？
它们分别对应了业务上的什么场景？边界是什么？
这样的归类合理吗？
其次，拉取出不同类型的case详情，通过单个分析、同类整理等方法，梳理清楚他们产生的原因。good case需要持续跟进占比变化，normal case需要转化为good case，而bad case必须尽可能降低其占比。
最后设计一个可视化的工具，支持不同场景下的查询、解释和监控。
这样，小蔡发现异常问题，就可以在查询工具中进行查询，知道宝马3的问题是什么类型的badcase，以及产生它的原因是什么。
小嘉也可以监控不同case类型的分布和变化，并针对不同问题的比例和优先级，进行方案优化。
最重要的是，小蔡和小嘉的合作更愉快了。
系统性的定义一套指标，就像科学家设计的关于世界观的拼图；互相依赖，自成体系，不断修正。
重要的是，可以从中更全面地找到不同case之间的关联，在边界范围内考量问题，从而优化整个体系。
批量case需要拥有创造性思维，能系统地定位问题。
写在最后
实际的工作中，很多单点case即便知道根本原因，受限于优先级、资源限制和改造ROI，解决方案往往也只是停留在表面，做一些浅层修复，缝缝补补又三年，万不得已再重构。
而系统性定位问题，需要设计非常合理的指标体系，并定义好badcase的边界条件。很多case按照不同的公式，可能一会good，一会bad。
一个好的建议是，不妨先run起来，根据实际的业务表现，不断调整指标的定义和公式逻辑。
关于系统化定位的例子涉及工作内容，没有详细展开。感兴趣的可以私聊。
