案例复盘O2O配送项目中我踩过的那些坑

　　想成为一条优秀产品狗，除了要掌握撕逼的技巧，还要有优雅的复盘姿势。在成为一条优秀产品狗的道路上，每做完一个项目，我总会花上一点时间，静静地回想那些踩过的坑，那不就是产品狗的修行之路么
　　公司的项目是一个O2O的电商平台，我负责的项目是用户与商家之间的桥梁配送系统。这个系统的主要用户角色是配送员和运营调度人员，so产品也分为配送员app及后端的运营调度系统。话不多说，先上菜，哦不，先上坑！
　　效率与体验的天平：强制更新机制
　　第一个版本考虑到app为内部员工使用，以及尽快上线的原则，没有设计强制更新策略。当迭代了两个小版本后发现，各个版本都有人在使用，甚至有较大功能缺陷的版本也有配送员在使用。发现这个问题后，我们紧急上了强制更新功能，为了这个有强制更新功能的版本及时覆盖所有配送员，整个团队也花了不少时间和精力。
　　填完这个坑，总算是明白了为什么前辈们总是语重心长的说“任何一款app一定要考虑好更新策略”。虽然做产品经理，要尊从二八原则，但并不是完全不考虑小部分的情况，因为没有哪个公司的执行力能做到100。强制更新的用户体验虽然差，但是对一个内部员工用的产品来说，效率比体验重要的多。即使是用户app，也因该预留强制更新功能，出于用户体验考虑你可能永远都不会用，但是以防万一总是好的。
　　当然咯，很多朋友会有疑问，iOS强制更新，怎么通过AppStore审核？哈哈，方法总比困难多嘛出于职业精神，我就不在公共场合讨论BUG啦（严肃脸）！有兴趣可以私聊探讨哈。
　　善意的小欺骗，让世界更和谐
　　配送员app抢单列表中，配送员可以点击抢单按钮进行抢单。但是，会有多种情况导致抢单失败，比如：
　　点击抢单时，订单已经被别人抢走
　　点击抢单时，订单已经超时（系统有自动派单机制，订单在x分钟内没人抢单判定为超时，系统会自动派单）。
　　对于这样的情况，我在第一个版本分别做了2种不同的提示：
　　订单已被抢
　　订单已超时
　　本以为给出了明确的提示，万事OK了。但是，上线后反馈却很不好：
　　明明已经超时了，为什么还要显示在页面上让我们抢，抢又抢不到！
　　确实，这样的做法很不好。配送是一个对效率要求很高的环节，在这样的反复抢单失败中，严重损害了配送员抢单的积极性。
　　不得已，只能在待抢单列表中增加了定时刷新的机制，每隔1分钟刷新列表。这样可以过滤掉部分已经被抢或已经超时的订单，但还是有部分订单因为超时而抢单失败。最后，没办法，只能做了一个小小的欺骗：将订单已超时和订单已被抢的提示都统一成了“手慢了，订单已被抢”。瞬间问题就解决了，再也没有听到有配送员抱怨了，世界又一下子和谐了！
　　从心理学来说：人们在归因的时候，更容易得出自己想得到的结论，而不一定是真实的结论。并且出于心理上的自我保护，人们会将导致失败的外界原因放大，而将自己个人的原因淡化。所以，当因为订单超时导致抢单失败时，配送员会抱怨产品的设计问题（外部因素）。但是同样的结果（问题本质并没有得到改善）；“欺骗”他是因为自己手速慢了，导致订单被抢，却没人再抱怨了（个人因素）。不但没有配送员抱怨了，反而看到订单的时候都及时去抢单了，不再挑三拣四，订单处理的整体效率还得到了提升！
　　填完这个坑，终于领悟，做产品，不仅要有很高的理性思维，也要有很强的感性思维。有时候，通过理性思维很难解决或解决成本很高的问题，换个维度，通过感性思维，说不定就不费吹灰之力。
　　设计是为了更好地传达信息，不要为了设计而设计
　　第一个版本的调度系统首页，我做了一个精美的欢迎页。一开始使用的同事们觉得还不错，但是过了几天，大家就审美疲劳了。因为同事们每天要登录很多次，去查看配送系统中的各项数据，欢迎页除了一开始的新鲜，对效率的提升毫无帮助。
　　认识到这个问题后，第二个版本优化时，我将欢迎页改为一个仪表盘。将工作中的配送员、待取货的订单数、待送货的订单数、报错订单数等重要数据在仪表盘实时展现出来。这样一来，工作人员一登录系统，就可以直观看到他们最想看到的重要数据，而不是一张“精美”的欢迎页，还要再经过几次点击，才能看到他们想看到的数据。
　　所以，我们在设计产品时，需要时刻提醒自己，产品的用户是谁。后端产品的用户是公司内部的同事，相比于美观，他们更需要的是效率。如金字塔原理一样，结论先行、重要的结果先行，登录后最先展现的是重要的数据，这对效率的提升就很有帮助。就如原研哉所说“设计的目的是为了更好的传达信息”，永远不要仅为了美观而设计。
　　没有绝对的平等，只有相对的公平
　　在设计智能派单算法时，一开始，为了体现公平，每个配送员被系统分配到订单的可能性只取决于配送员当前位置、订单路线、订单承诺送达的时间、配送员当前手上配送中的订单情况等客观因素。但是后来发现，这样一来配送员的配送速度、配送满意度等个性化指标没法贯彻落实，因为在派单机制中，没有将这些作为考虑因素。
　　后来在版本优化时，在智能派单算法中增加了配送员速度、满意度等个性指标对派单概率的影响。就这样在智能派单机制中遵从了森林法则，配送速度快的、满意度高的、超时率低的配送员被派单的可能性更大，相应的绩效工资也更高。增加了个性化指标对派单概率的影响后，解决了为了平等而一刀切的情况，形成了良性竞争，对整个配送团队的效率带来了很大的提升。
　　很多时候，公平不是平等，平等是没有条件的盲目平均，而公平是有前置条件的平等。平等滋生迂腐和低效，而相对的公平能带来良性竞争和高效。我们在设计产品时要避免平等，而是要用公平去设计规则，来达到产品目标。
　　复杂的问题，也能用最简单的基本原理来解决
　　一开始，设计调度管理系统的权限时，只设计了账号和权限2个维度。但是，在实际使用过程中发现这样很不方便，当要增加一个新同事的账号时，需要在好几十种权限中勾选出他需要的权限。不仅过程十分麻烦，还会出现多勾选了不该赋予的高级权限，或少勾选了账号需要的权限等差错。
　　得知了这样的情况后，在后来改版时，我将权限分了3个维度：账号、角色、权限。这样，先对不同的角色赋予不同的权限，如客服、客服主管、客服总监、调度员、配送总监等角色。当新同事加入时，只要将该同事的账号与对应的角色关联就OK，不再需要勾选很多权限，大大提高了权限管理的效率，降低了出错率。而且，当大要开通Boss的账号时，只需要将客服总监、配送总监等高级角色都赋予Boss账号即可。
　　系统的权限管理，可以类比到公司的组织结构管理上：员工由经理管，经理由总监管，而Boss只要管理各业务部门的总监就ok了。正如《简约至上》中所说，组织是简化设计的重要策略之一。将繁杂散乱的功能或元素，根据其特性组织分类，形成一个树形结构，这时候我们就更容易看清问题的本质。一但抓住问题的本质，复杂的问题往往就能迎刃而解。
　　篇幅原因，就先分享这么几个我踩过的坑吧，希望我的前车之覆，能为后车之鉴。
　　作为一条产品狗，我还在不断挖坑和填坑的道路上前进。复盘的目的只是为了不掉进同一个坑两次，未来还有更多的坑在等着我！但，那又怎样，万物皆有裂痕，那是光照进来的地方！