通过订单及售后流程的不同分析思路，看产品与研发思维的区别

电商产品设计中，订单状态及售后退款状态的流转是非常重要的一块儿内容。笔者在参与梳理和设计此流程时，自以为考虑得已经相当全面，到了技术那里依然会被称为“不全面”的方案。梳理的这些流程对于测试、运营、仓储、客服等人员来说确有很大帮助，但对于真正的研发人员并没有帮上什么忙。

然后技术人员当面给笔者演示了他的思路，顿时感觉拨云见日，仿佛来到了另一个世界！下面，笔者将重点以图示的方式，更清晰地展示产品与研发思维的区别点。

产品思维下的订单及售后流程设计

正常订单状态的业务流程图

可见正常订单的状态流转还算清晰简单，订单状态前端展示只有四种：待付款、待发货、待收货、交易完成。用户在付款成功后的任一阶段均可退款，但所走的退款流程却不尽相同。接下来将为你一一展示。

特别注意：笔者所在商城出于业务特殊性考虑，退款及退货流程与订单流程完全分开，互不影响。且退款流程综合用户需求和业务需求考虑，设置了一定门槛。

待发货退款业务流程图

待发货状态下，商品还未出库，一旦开启退款流程，立刻冻结订单，取消出库，以免增加成本。直至退款流程结束为止，若退款失败且申请次数使用完，则售后工单解冻，订单状态会继续正常流转，转换为待收货状态。

待收货，未确认收货时退款业务流程图

待收货状态下就涉及到物流了，属于退货退款流程，每一步都会影响进销存的变化。用户在申请退款时，可选择退款类型并提交相应信息，尤其是退货的物流信息，需要物流单号，以便仓储确认收到退货后，进行退款操作。

另外在此期间用户任意时刻点击“确认收货”，订单状态都会正常流转。因为有了上述提交物流信息的要求，即使未真实收到货，就确认了收货，对退货退款的流程也不会造成影响。

已确认收货，交易完成时退款业务流程图

交易完成是指用户已经确认收货，订单所有流程皆已走完。此时退货退款和待收货基本一致，只不过前端展示会有所区别。

好了，以上是笔者作为一名产品汪，做的流程梳理。接下来，要为大家展示程序猿同学教我的流程图。

研发思维下订单及售后流程设计

研发同学以更加严谨的方式，说明了上述流程的不全面之处，且利用了列联表的方式，将所有后台状态机需要的流转结果罗列出来，形成了下面的表格。

请注意，纵向是退款成功或失败后，订单和售后单返回什么样的结果。横向则是订单状态，以及不同订单状态下将订单与售后单拆分开来考虑。

这么一列举，16种结果一目了然。瞬间感觉自己的思路太局限而且弱爆了。当然这是后端状态机需要考虑的部分，我们平时只看到前端展示的内容，很少有机会理解后台的处理方式。

订单栏的部分是指部分退款，全部则指全部退款，仔细看退款成功或失败后二者返回的订单状态是不同的。而这点才是作为产品的笔者所遗漏的。

这件事使笔者很后悔当年大学期间没有好好学习统计学的知识。统计学里在算概率的时候经常会用到二联表-卡方检验、列联表这些工具。虽然不知道研发同学懂不懂统计学，但他的思路确实启发了我。我们考虑很多问题的时候，看似全面，实则不然，应尽可能地多角度分析，才能查漏补缺。

这还让我想起了数学里有关“排列组合”的知识，可以算作另一个角度，帮助我们思考其他问题时想得更全面些。

排列即和顺序有关，组合不牵涉到顺序的问题

举个例子，一个班级里有10名学生：① 每两人互通一封信，共通了多少封信？ ② 每两人互握了一次手，共握了多少次手？

分析：① 由于每人互通一封信，甲给乙的信与乙给甲的信，是不同的两封信。所以与顺序有关是排列问题； ② 由于每两人互握一次手，甲与乙握手，乙与甲握手，是同一次握手。与顺序无关，所以是组合问题。

所以二者的计算方法自然不同，使用加法原理还是乘法原理，均要看实际情况而定。本题就不做计算了，感兴趣的话大家可以自行解答。此处也是为大家提供一个思路而已。

当然现实中我们可能很少遇到比较复杂的情况。这些方法或许不仅在产品设计，在数据分析时也能起些作用吧。更高深的统计学相关知识，笔者是真的知之甚少啦。相信社区里牛人很多，期待与你们多多交流！