时间: 2021-07-30 11:39:51 人气: 24 评论: 0
如何进行逻辑练习并输出流程图？本文笔者给了我们一个很好的示范，以美团外卖下单成功后的送红包功能作为分析对象，深入思考后绘制流程图。
这是我的第6期逻辑练习的作品。
每周进行一次逻辑练习并输出流程图，坚持下去**产生什么变化呢？
我也不确定，希望这些内容，你能喜欢。
这次逻辑练习，我选择了美团外卖的一个增长功能作为分析对象，这个功能非常常见，相信你也遇见过很多次——
下单成功后的送红包功能。
在美团外卖里，每当你支付下单后，**出现送红包功能的入口，你可以将这个红包发给你的微信好友，同时，你也可以发给自己。
相信你对美团外卖的红包一点都不陌生：
站在结果的角度，我们可以发现 送红包功能有几个特殊点。比如，一定是订单支付后才出现入口，领红包前就已经知道手气最佳的位置。
既然我们都是这个功能的用户，那么和我一起来完成这次练习吧！
练习命题：
请绘制美团外卖下单成功后的送红包功能的流程图。
要求及补充信息如下：
1. 订单支付成功后，触发送好友红包的功能入口。
2. 使用用户视角构造泳道图
3. 逻辑并不复杂，但在好友领红包环节，至少包含3个判断条件
这是我的练习作业，分享给大家，我需要强调的是：这份作业仅仅是我们的练习作品，不代表任何产品的真实逻辑。
我把它分成了四个主要环节，分别是订单校验（发红包），红包金额分配（发红包），账号关联（领红包），逻辑判断（领红包）。
再次强调，输出的流程图仅仅是练习作品，不代表真实逻辑，实际上，真实逻辑过于复杂，并不适合我们日常的逻辑练习。
尽管我们每次完成支付订单的操作，都**触发送红包的功能入口，但我仍然在这里加入了订单校验的环节，这是一种简易的风控意识。
牵扯到钱的功能，都应该有风控机制，至少在设计产品时，需要具备风控相关的意识。
对于美团而言，这些送出去的红包都是真金白银。一旦出现异常，将产生极大的损失。
在今天，如果美团停止了该业务，单日即可增加数百万的收入，对于使用红包下单的用户而言，即使没有红包，也有很大概率下单。
对订单进行校验，可以提升我们对支出的控制能力，也可以增加我们的控制手段。
对于一些订单金额比较低的，又或者低质量羊毛党用户，我们就可以实现差异化的处理方式，且不被大众所知晓。
美团送出去的红包都是现金，可以真实抵扣的，是需要代替用户支付给商户的，这表示用较低的金额，可以“**红包”套现。
具体操作如下：
你需要激活美团外卖商户，将部分商品单价设置的极低，比如做到1元每单，或者0.1元每单。
将部分商铺单价设置的极高，以能够使用优惠**为目标。
准备非常多的用户账户，通过购买低价商品，获得红包，再通过购买高价商品使用红包。
此时，红包对应的金额，便**计为该商户的实际所得收益，可以从平台提走。
<仅为参考案例，相信美团不存在这样的漏洞>
订单校验是一种后置的处理机制，是一种最基础的保障，意思是可以通过后置添加的判断条件，来止损。
比如商户黑名单，用户黑名单都可以在订单校验环节判定为无效订单，不触发红包逻辑。
用户在分享在微信的链接**显示“第X个红包金额最大”的文案，其中明确告知了用户，手气最佳在第几位红包。
这表示金额分配的方式采用的是前置分配。
也就是生成红包时，已经将每个红包的金额同时生成好了，只有这样才能知晓金额最大的红包在哪个位置。
有的朋友**疑惑，为什么不是在分享完成后生成红包金额，毕竟现在的网络很快，计算速度更快。
实际上，最佳的做法是在分享完成后生成红包金额，这样可以节省很多服务器的计算能力，毕竟有很多红包生成了，但没有被分享。
问题在于 分享时显示的文案 “第11个人红包金额最高”，这里的“11”需要我们先传参给到微信。
换言之，如果分享前没有得到这个参数，那么文案就需要调整了。
也就是说，为了在分享前知晓哪个红包的金额最大，我们需要在订单生成后，同步生成红包，并分配红包的金额。
在这次的练习题里，我将红包金额的分配节点置于订单支付成功之后，这**增加服务器的计算压力，并不是最佳做法，但却是最方便的做法。
还有一种性价比更高的做法，订单生成后，随机生成最大金额红包的位置序号，当产生分享行为后，再生成红包的金额，这个做法比我在练习时提到的做法，性价比更高，将对服务器的计算压力降到了最低。
账号关联是指将红包的领取人与美团的用户信息进行关联，由于这个业务横跨了美团和微信两个产品，且两款产品之间数据无法同步，这就成为了必不可少的环节。
这里有几个问题，我们可以一起探讨一下：
a. 是否可以用微信登录代替；
b. 是否可以后置关联，也就是先领红包，再关联账号。
关于第一个问题，是否可以使用微信登录代替手机号码关联，这需要我们从场景思考出发，并不是非A即B的选择，而是找到更合适的做法。
在美团的账号体系里，是以手机号码作为主体，并且大部分业务都需要用户提供手机号码作为联系方式，核销方式等。
因此在这个场景里，手机号码比微信登录更加合适。
站在新用户角度，如果用微信账号领取了红包，在实际使用红包时，仍然需要绑定一个手机号码。
这个逻辑演延长了用户的转化路径，还不如坚守手机号码作为账号主体的核心理念。
关于第二个问题，单纯从用户体验的角度出发，自然是先领红包，再绑定账号更好，但实际情况却不是这样。
一方面，后置账号关联**产生许多无效红包，也就是红包被打开了，但是没有进行账号关联，这**极大的降低红包的作用面积，在账号绑定之前，用户可以开无数次红包，也许相同的1个红包，**被同一个用户打开10多次。
另一方面，也是风险意识，后置关联账号，表示用户拥有了放弃的选项，并且这样的放弃也不**减少开红包的次数，意思是我们可以打开N个红包，只有在红包金额让自己满意时，再进行关联。
我们在命题里特别要求了 领红包环节至少包含3个判断条件，如果这道题出现在面试或者笔试环节，那就尽量多的思考判断条件吧。
针对领红包环节有太多的判断条件，这里可以充分体现出我们的思维宽度，以及思维的深度。
这里，我提到了4个判断条件
（1）是否本人领取：
或许在显示层我们无法观察到这个逻辑判断，但在后端逻辑里，是有必要进行判断的，这对我们判定用户的质量显得特别重要，对于后期的微观调控也**有很大的作用。
比如，经常自发自领的用户，拉新能力比较低，他的红包金额就可以小一点，因为没有太大可挖掘的潜力。
（2）是否触发风控：
在生成红包前，我们针对订单进行了有效性校验，用来降低商铺及下单人的风险，而在领红包的环节，也需要针对领红包的用户设置风控机制。
我们可以将失信用户加入黑名单，这些用户将**无法领取红包，或者只能领取最小金额的红包。
（3）是否已领取：
这是比较表面的判断，每个红包每个用户只能领取一次，**被划分到两个状态里，每个状态在UI层面**出现差异，已经领取过的用户，无法重复领取。
若是缺少这个条件，表示用户可以重复领取多次，这个功能也就没有意义了。
（4）是否已达上限：
这里的上限是指用户今日可领取的数量是否已经消耗完毕，如果用户今日已经领取了足够数量的红包，是不允许继续无止境的领取红包的。
上限的设定是一种逻辑闭环，也就是有始有终。
产品向用户发红包是开始，但必须存在一个阀值，能够关闭或中止这个业务。
无上限的设计，在与金钱挂钩的项目里十分危险。
我们已经知晓这些红包的金额是可以被套现的，若是用户账户可以无限制领红包，毫无疑问**增加**风险。
而凡事**触发这些阀值的用户，**的概率更高。
除了用户每日可领取的红包存在上限以外，每个红包可被领取的次数同样存在上限。
实际上，在领红包的环节存在许多判断条件，原因很简单，这是向用户发钱的足后一个关卡，这是要将真金白银送给用户。
思考以下几个问题，看看你还能想到其他的判断条件：
1. 什么样的用户拿到的金额应该更低
2. 什么样的用户应该拿到金额比较高的红包
3. 如何让这些赠送出去的现金红包产生更高的价值
4. 如何减少支出的成本，提高最终性价比
通过对真实案例进行复**，我们设计了一个简单的可行的送红包业务流程，在这个过程中，也有不少感悟收获，总结如下：
1. 设计业务流程时，需要考虑到服务器的计算能力，必要时，要围绕降低性能耗损的目的，优化业务逻辑。
2. 与钱挂钩的项目必然需要具备风控意识，并且还需要具备风控机制。
3. 手机号码还是微信授权取决于应用场景，是一个 谁更合适的问题，而不是谁更好的问题。
4. 即使前端不需要某些判断条件，特殊的数据依然可以通过后端判断并进行存储，这些数据在未来能有助于我们进入更精细化的产品设计阶段。
5. 逻辑要有闭环，有开始的地方，就要有终点，轻易不要设计“无上限”的产品逻辑，这**留下许多隐患。
比如一些逻辑漏洞，又或者是一些计算路径过长导致的高计算并发。
如果你觉得这篇文章对你有所帮助，就分享给你的朋友吧。
也希望未来能与你一起进行逻辑练习，我相信，坚持下去，我们的逻辑能力都能有极大的提升。
枯叶，微信公众号：产品经理充电站。人人都是产品经理专栏作家。近9年经验的产品经理，擅长社交、社区、细分群体挖掘。
本文为平台独家约稿，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
