这是一个创建于 710 天前的主题，其中的信息可能已经有所发展或是发生改变。
一大早，技术 Leader 专门拉了个会把所有技术拉过来开会，没有指名道姓但是基本上主要就是批我。看来真把领导气坏了，hhhh
前情：
产品有个需求，我们开会对过，大概 1 前端 1 后端的小活动，具体为
在现有业务某个入口，根据一定条件展示优惠券。能领取优惠券的用户，发一下验证码，然后调用另一个团队领优惠券的接口。有部分黑名单用户不能领，还有些其他小限制，比如只能领一次，优惠券会过期之类的。
是一个低频活动，每天几千 PV 左右的入口展示量级这样。
我的思路：
Redis 里存黑名单用户，大概 1w 人，可以动态增删。
两张 Mysql 表
一张存优惠券，包括优惠券的名字，数量，金额，一些关联条件等等。
一张存领取记录，用户信息，优惠券 id ，时间，用来判断用户是不是领过。
写了大概一千字的设计文档，包含接口定义等等，预计 1 周开发时间吧，我觉得是个比较小的需求，产品的预期也是先简单做一下看看效果，毕竟量也不大。写完美滋滋发给领导，然后遭到（女）领导的狂喷：
我草你这啥啊设计的，完全不符合你的职级啊！
「什么东西都按需求白描，就不会有好的架构。」
「你现在设计的服务，最大的问题就是太沉浸在需求里了，不能高于需求，设计的太死了，自己给自己留的余地太少。」
「尽量要把每个能力都抽象出来，可配置，不然就又只能重构，设计阶段就是干这个事情的，如果只是需求 by 需求的做，随便找个外包搞就行了。」
我......
咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。
好的架构应当是随着业务的发展生长出来的不是么。
所以老板到底想要的是啥子呢？想满足用户的需求可真难啊。
前情：
产品有个需求，我们开会对过，大概 1 前端 1 后端的小活动，具体为
在现有业务某个入口，根据一定条件展示优惠券。能领取优惠券的用户，发一下验证码，然后调用另一个团队领优惠券的接口。有部分黑名单用户不能领，还有些其他小限制，比如只能领一次，优惠券会过期之类的。
是一个低频活动，每天几千 PV 左右的入口展示量级这样。
我的思路：
Redis 里存黑名单用户，大概 1w 人，可以动态增删。
两张 Mysql 表
一张存优惠券，包括优惠券的名字，数量，金额，一些关联条件等等。
一张存领取记录，用户信息，优惠券 id ，时间，用来判断用户是不是领过。
写了大概一千字的设计文档，包含接口定义等等，预计 1 周开发时间吧，我觉得是个比较小的需求，产品的预期也是先简单做一下看看效果，毕竟量也不大。写完美滋滋发给领导，然后遭到（女）领导的狂喷：
我草你这啥啊设计的，完全不符合你的职级啊！
「什么东西都按需求白描，就不会有好的架构。」
「你现在设计的服务，最大的问题就是太沉浸在需求里了，不能高于需求，设计的太死了，自己给自己留的余地太少。」
「尽量要把每个能力都抽象出来，可配置，不然就又只能重构，设计阶段就是干这个事情的，如果只是需求 by 需求的做，随便找个外包搞就行了。」
我......
咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。
好的架构应当是随着业务的发展生长出来的不是么。
所以老板到底想要的是啥子呢？想满足用户的需求可真难啊。
 |
101
zzzzzzZ 2022-12-19 09:59:39 +08:00
@xiaotianhu
#82 楼说的就很对，我也说过，不点名就不是针对你。 前途没有完，如果你能够马上「做出改变」并且能同步到。士别三日当刮目相待。 这在企业运营中很常见，很多时候因为信息差不同，大家工作的产出并不是往同一个目标去的，就需要及时修改让自己的 OKR 对齐，前面时间浪费掉了很正常。 单论工作来说，这种不同步很正常。我也经常向上同步战略或者向下分享一些。所以就需要让下面的人获得更多的信息，就是领导那个「批斗大会」，声明大家做的不是外包的那种交付，而是提前预留设计的可迭代演进的项目。 开会骂的确很拉，如果可以先自责一波定个调调，声明是她没有说清楚，效果会好很多 对你来说这些都无所谓，关键还是工作产出。把自己弄成一块金子，领导就不会怎么你，把你当宝还来不及 |
Select Language