之前我常常是希望做出来的产品功能完美，逻辑清晰，可越当我追求“正确”的时候，总会有那些小概率事件引起的“错误”，让我不得不重新思考和调整原来的逻辑；当我改变了原来的逻辑以适应那些小概率事件时，却又觉得整体流程太过臃肿和复杂。我常常把自己卡死在这里，容忍不下逻辑上的小漏洞，又怕复杂的操作带来用户的不便，同时又加大研发的成本。之前也反思过自己这个问题，告诉自己要权衡利弊，可有时候还是会不自觉跳进这个逻辑怪圈。有的问题，一旦你试图精确的去剖析它，就会掉进“怎么证明你妈是你妈”的流程中。越是试图精确描述，就越会迷失在无穷的细节中，有时候这些边边角角的小细节真的会影响你对这个功能这个方向整体的判断，从而忘记了最初的目标。
其实只要保证大方向是对的就可以了，小事件的解决方案正确与否都不应该影响产品整体的规划和战略。一旦被一些小事件左右，就应该马上跳出当前的场景，从产品大方向上来看待这个问题。现在自己总结了一套方法，以防止再次掉进这个逻辑怪圈。1，这个小事件是怎么发生的？首先分析这个事件在线下的发生场景以及线上的操作路径，线上是否可以还原线下的解决方案？线下是否可以容易的解决线上不方便解决的问题？事件发生之前是否可以及时制止或加以提示和警告？如果可以，应该抑制这种小事件的发生。2，这个小事件的发生概率大吗？然后判断引起你纠结的这个小事件在整个功能的操作流程中发生的概率有多大？个人感觉，低于10%的可以不必太在意，10%-30%之间的尽量找合适的方案去解决，高于30%的说明整套逻辑有问题。3，这个小事件会产生严重的后果吗？接着考虑这个小事件发生后导致的后果是否很严重？个人感觉，A级的后果比如会导致用户数据错乱，数据丢失等一系列严重问题的，这个必须解决，功能设计中是必须考虑这个细节的；B级的后果比如用户操作不便等一些中级的问题，可以适当做一些小优化以解决；C级的后果比如显示上的问题等，可以忽略。4，这个小事件有替代方案吗？最后，如果这些小概率事件发生了，但是主流程不兼顾，那么可以考虑产品其他功能是否也可以解决这个问题，如果有，则应该引导和提示用户使用XX功能来进行操作以解决用户的根本问题。如果没有，可以向用户解释说明，不然用户会带着一堆“怎么不能删除？怎么不能修改？”等等疑问来用产品的话，效果自然也不会太好。
做对的事情比把事情做对重要
网友评论