从起点到终点，其间的过程可能会因为外界因素的干扰而走向不同的预想路径，善意的出发点甚至可能带来性质不同的结果。当下，我们熟悉的电商场景中也上演着这样的“眼镜蛇效应”——“价保”规则的设立似乎并不能保障消费者的利益，商家已然走出了自己的“套路”。
电商发展了这么多年，已经形成了成熟的商业模式了，头部电商平台近几年也在不断推出新的玩法政策，促使消费者购买，同时也在保障了消费者的权益。但是好的意图不一定能产生好的效果，本文我们来谈一谈电商价保规则带来的“眼镜蛇效应”。
跟大家分享一个小故事。
印度还是英国殖民地的时候，印度本地眼镜蛇泛滥，经常出现眼镜蛇伤人的事件，当地政府想要解决眼镜蛇的问题，于是发布了一项计划：只要抓到了眼镜蛇，就可以领取对应的赏金。
出于赏金的诱惑，印度民众大量捕获眼镜蛇换取对应的赏金，短时间内，眼镜蛇的数量大幅减少。
眼镜蛇是减少了，可是那些“薅政府羊毛”的民众不开心了？善于投机取巧的人们想到了一个办法，野外没有眼镜蛇了，我们可以自己养呀，政府又无法区分野生还是家养，于是抓蛇变成了养蛇。
很快，政府就发现了事情不对劲，明明数量已经减少了，为什么拿蛇换赏金的还有这么多？经过调查发现了其中的猫腻，政府只能叫停了赏金计划。
没有了赏金，那些养蛇的人自然就失去了养蛇的动力，于是将养的蛇全部放生，眼镜蛇在野外再次泛滥，而且比之前更加严重。
经济学家霍斯特·西伯特基于这个事件创造了“眼镜蛇效应”这个术语。
每当你做出一个决定的时候，你的出发点通常是好的，但结果一定会好吗？
近几年，电商平台为了保障消费者的权益，防止商家恶意标价，设置了“价保”规则，我们先来看一下某电商平台对于“价保”的规则说明：
我看到这套规则的第一个想法是，太好了，平台终于出手治理了这些无良商家，原本购物节后价格更低的行为被遏制了，消费者可以放心购买。
我所理解价保的规则是，商家肯定会遵守平台的要求，不敢随意调整价格，如果调整价格导致消费者权益受损，就会被平台查到，并返还差价给消费者，商家店铺考核分会受到影响。
事实真的如此吗？消费者所理解的“价保”规则和商家所理解的“价保”规则是一致的吗？
近几年活动是从.-.一直持续的，平台上商品价格每天都在发生变化，我一时间无法确定哪天的价格是最优价，所以持续在关注，在.的时候，我预感价格可以入手了，在与客服确认了有“价保”的规定后，就进行了下单。
在.当天我重新登录平台查看商品最新价格，我瞬间懵圈，说好的“价保”呢？
带着质疑的口吻，我询问了客服，得到了下面的回答和解决方案：
商家态度很好，回复得很快，提出解决方案是我按照最低价格下个订单，无需付款，然后将两个订单号发给他，他确认两个订单的价格差，给我补差价。虽然最后没有走平台申请“价保”，但还是顺利拿到了补偿。
回看整个事件，细思极恐，从商品调价、到售后处理，这是一套完整的方案，针对不同场景的问题，早已设定好了对应的解决方案：
卖家在市场推广策略制定上面，已经对价格进行了多种方案设置。一开始，商品已经进行了预热，不停地调整价格，升高降低，要的就是让消费者琢磨不透，时刻关注，害怕失去最优的价格，无论任何时候下单，都是商家的预期；
商品lisitng可以在瞬间完成价格、图片、文案的变更，绝对是软件进行了支持，提前设定好了整套方案，全自动调价；
加入平台“价保”的活动，降低消费者防备心，消费者以为商家都会遵守平台“规则”，并不会无视平台“规则”，殊不知商家有自己的“规则”理解；
若消费者发现后，询问客服，客服及时响应，并给出完整的解决方案（已经设定好的话术），消费者拿到补偿，不再追究。
从前到后，所有场景全覆盖，他们赌的就是部分消费者下单之后不再关注商品信息，Z的是这个信息差。
“赌”是有风险的，商家为什么能确定他能够Z到这份信息差？其实这是一个概率的问题，商家掌握了消费者的下单行为，已经有完整的消费者画像，和消费者行为路线图，经过大量的分析，得出消费者对类似事情的关注程度，从而得到了最优的配置方案。
我们看起来很Z，但商家永远不亏！
这就是“眼镜蛇效应”，平台的规则制定初衷是好的，但是却被商家钻了漏洞。要特别提醒从事电商的产品经理，警惕商家套路，多考虑方案设计，怎么才能进行合理优化，让“价保”方案发挥该有的用处，造福消费者。
作为软件设计从业者，我们要不断反思我们的每一次方案设计是否存在漏洞，是否覆盖了全场景。
方案的优化并不是拍脑袋、一时一刻就能设计出来的，需要我们持续跟进优化。
产品上线后，及时进行跟进使用效果，查看数据、分析行为、复盘使用场景，并不断优化。
我拿一个负责的项目给大家举例。
我负责了“供应商管理系统”的整体设计方案，上线之后，供应商管理部负责审核信息的同学给我反馈，他发现其他部门的小伙伴在引入供应商时，会对一家母、子公司进行重复引入。我司是杜绝马甲供应商的，所以他们希望做一下校验，使用手机号、地址等信息，发现重复地进行提示，人工核实。
这个需求我们评审很合理，于是我就规划了一个产品方案，与业务方进行评审。在评审过程中，业务方提出最好是填写信息的时候不进行相关提示，只有在审核的时候提示。
我表示不理解，如果我们在填写信息的时候就进行提示，那么新建的同事不就知道了是马甲供应商、避免重复引入、停止资料填写了吗？这也减少了供应商审核同事的工作量。
业务呵呵一笑，道出了真相。由于某些无法诉说的利益原因，新建的人如果发现了信息重复，他们会找供应商替换手机号和资料信息，绕过判断，从而成功入驻，这样的话我们的校验其实是帮助他们，不能实现这个功能的初衷。
我表示震惊，还有这种操作。软件方案并不作恶，但却会帮助别有用心之人。
于是我们设计方案进行了调整，只在审核的时候校验提示，并且不对公司其他部门公开我们的校验逻辑。没有了明确的规则，新建的人只能靠猜，虽然他绕过了我们第一道检测，但不一定能绕过第二道检测。
上线第二天，通过我们的检验，就发现了一个马甲供应商，并反馈给了对应的审核人员。
如果业务方没有意识到这个问题，上线后的需求，被某些同事巧妙运用了规则，我们就陷入了“眼镜蛇效应”，系统的数据还在观察，方案仍需优化……
作为“产品经理”，我们都有可能会陷入“眼镜蛇效应”，即使是一个小需求，我们也不能放弃对需求的研究。不断去发现、去深思，把每一件小事做好，小事的成功也可以造福一方用户。
成为合格的产品经理，道路且长。
