何谓用户需求?

      最近需要重构“红包”模块, 1000w次/日的http请求发送量对系统的性能提出了挑战。于是技术线屁颠屁颠的开始研究并发、简化核心业务,考虑分app机器,DB分库。。。

 

     上周五过需求的时候,讨论到最后支付环节。通常电子商务的支付流程是“下单-支付-确认收货-交易结束”。在下单步骤,红包为冻结状态(买家可用红包数减少,但是并未真正消耗。一旦取消订单红包就会返还)。类似银行的转账流程:

汇款人去柜台填单汇款,银行是先冻结该笔金额,直到汇入方确认收款或者汇入失败,才对该笔钱进行操作。但是在此期间,汇款人账上可用余额确实是被减少了。

 

      这点在我们看来也很容易理解,不过跟运营同事讨论需求的时候发现了一些趣事:)不少买家在一笔订单未付款的情况下,去产生另外一笔订单交易,然后投诉反映自己的红包数变少了(被另外一个订单冻结,取消即可返还)。于是最终结论是在下单页面,我们做一次判断:有冻结态的红包将给出提示+链接,引导用户回收红包。

 

      这就是活生生的用户需求,在用户看来,实时发放,实时对账是天经地义,无论系统支持2000w还是1000w均只是“满足基本使用”的要求,更多的增值点,还是体现在业务流程、交互、视觉上。 当然,这次能和运营的一起PK需求,还是让我受益匪浅。技术线走的久了,总有一股冲动去了解运营知识,甚至想尝试产品岗位。。写出完整的需求文档,让自己更多的改变世界。。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值