领导专门拉了个会批斗了我一番。大伙帮忙看下，我的设计思路很离谱么

[xiaotianhu]

一大早，技术 Leader 专门拉了个会把所有技术拉过来开会，没有指名道姓但是基本上主要就是批我。看来真把领导气坏了，hhhh

前情：
产品有个需求，我们开会对过，大概 1 前端 1 后端的小活动，具体为
在现有业务某个入口，根据一定条件展示优惠券。能领取优惠券的用户，发一下验证码，然后调用另一个团队领优惠券的接口。有部分黑名单用户不能领，还有些其他小限制，比如只能领一次，优惠券会过期之类的。

是一个低频活动，每天几千 PV 左右的入口展示量级这样。

我的思路：
Redis 里存黑名单用户，大概 1w 人，可以动态增删。
两张 Mysql 表

一张存优惠券，包括优惠券的名字，数量，金额，一些关联条件等等。
一张存领取记录，用户信息，优惠券 id ，时间，用来判断用户是不是领过。

写了大概一千字的设计文档，包含接口定义等等，预计 1 周开发时间吧，我觉得是个比较小的需求，产品的预期也是先简单做一下看看效果，毕竟量也不大。写完美滋滋发给领导，然后遭到（女）领导的狂喷：

我草你这啥啊设计的，完全不符合你的职级啊！
「什么东西都按需求白描，就不会有好的架构。」

「你现在设计的服务，最大的问题就是太沉浸在需求里了，不能高于需求，设计的太死了，自己给自己留的余地太少。」

「尽量要把每个能力都抽象出来，可配置，不然就又只能重构，设计阶段就是干这个事情的，如果只是需求 by 需求的做，随便找个外包搞就行了。」

我......
咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。

好的架构应当是随着业务的发展生长出来的不是么。

所以老板到底想要的是啥子呢？想满足用户的需求可真难啊。

[seawing]

技术设计本身什么的不评价，只针对你领导的的措辞。
你领导这种不结合具体问题展开，只讲些放到哪都正确的务虚评论，甚至由一个小问题上升到个人能力的行为，一律可以理解成 PUA 。
当然也可能是有更具体地架构评论你没有复述出来，有的话另说。

[clowcloudy]

1.流程
2.你的职级
3.准备简历

[a554340466]

不要去想自己方案是不是对的，反正已经不喜欢你了，该准备准备

[ampedee]

感觉是沟通问题，设计思路如何反而不重要，真觉得设计思路差，也不至于拉会批斗。
从改善现状的角度（不代表我认可你 leader 的做法)分析，在开始写设计文档之前，你应该和她沟通一下：
1. 把你的设计思路简单讲一遍
2. 征求她的意见（毕竟她是技术 leader)
真正让你领导生气的，是你做事情的方式不对：你在没有提前征求上级意见的情况下，花了不少时间(毕竟写了一千字设计文档)，做出了一份与她意向不符的设计方案。
当然我个人是觉得她小题大做，不算是个好 leader

[zxcslove]

不教而诛谓之虐
要理解出题人的思路

[goodryb]

无论如何，感觉这种上纲上线的批判是大可不必

核心点在于对于这个需求的理解，你可能想的是怎么把需求做了，你主管可能想的是抽象成一个可复用的活动系统或者组件

如果你是架构师，那就要“学会”没事找事、小事大做

[dolorain]

女领导是重点。

[hefish]

你干这么多，搞这么详细，是为了显得你能是吗？

[zoharSoul]

这就是想批你, 找了个由头罢了

[tool2d]

1. 一部分码农只喜欢鼓捣自己的代码，缺乏合作性，后续领导想先加别的功能，发现代价很大。领导应该以前吃过楼主的大亏，才会如此反感写一次性代码。

2. 楼主可以把事情做好，但就是怕麻烦。于是设计上能省则省。领导还是看不过去，嫌弃楼主只拿钱不出力。

[jorneyr]

对错重要吗？
不重要！
想怎么对你才是最重要的。

[xuanbg]

架构师要善于以小见大，从小地方发现大需求，然后从结构上去做业务支撑。就这个点来说，你的领导水平相当高，OP 你应该多学学。

[hhjswf]

要做成拓展性高的，这个在需求评审会上就应该先对一下。把你的考虑提前说，别自作主张

[SchneeHertz]

不管你对不对，没必要讲什么道理
可以找下家了

[MoonWalker]

所以你到底是个啥职级？

[foolishnobody]

你的设计完全满足现有需求，
可能你的 leader 需要你考虑下未来这类活动的可扩展性或者自己的想法添加进去，做不做她来决定，
大部分 leader 都不喜欢一个“执行工具”，更喜欢一个有想法的“执行工具”。
还有一种可能就是你运气不好，纯粹想拿你撒气。

[brust]

反过来举例子
怎么把每个能力都抽象出来,全部要配置化,这么多抽象概念,这么多配置,我就给你一个需要,为什么整一个这么复杂的功能?

老板想说啥就说啥呗

[fredli]

技术不离谱，这么看待技术评审，思想很不凡，自己什么都对看不到别人的好意见

[rickll]

一句话对你有意见了， 如果没有意见的话不至于拉个会来批斗。

[sadfQED2]

卧槽，这这这。。太特么熟悉了。老哥哪个公司的。跟我当年的领导，说话口气一模一样

[huoshanhui]

不恶意揣度的话往好的想，我的理解是，你的领导是不是对你有期望的，而你做的事只是普通员工都能做的事，没从她的角度思考去执行，或许对你的期望是培养成她的得力队友或者左膀右臂。而你做的让她失望了 ，所以很气愤。我遇到过这种情况，有点理解。

以上仅是往好的角度想。

[yesterdaysun]

我稍微尝试代入一下你领导的视角: 你这个设计太没有前瞻性了, 我见过太多"按需求白描"的设计了, 优惠券这种东西我太清楚了, 以后肯定要大改, 为啥不一次性弄好, 我们系统其它地方都是按照一定余量一定灵活度设计的, 你为啥不照着那些来, 这才不是什么"过度设计", 而是有前瞻性的规划, 现在那些人说试验性需求, 过两天立马加大力度要你改, 看你到时候怎么办
我也尝试代入一下你的视角: 产品都说是小需求了, 加两张表足够了, 反正就两张表, 出问题改起来也容易, 字段不多, 没什么复杂的东西, 需求来了改起来轻轻松松, 余量刚刚好, 反正产品也要迭代的, 我这是"敏捷"的做法

以上纯属 YY, 反正我看来大概是沟通问题, 你们并没有一些共识, 你可能看不惯系统其它地方的"过度设计", 这次尝试一下"刚刚好的设计", 然后被领导发现, 就被批了, 那可以就这个机会讨论一下, 到底其他人怎么看待"过度设计", 如果能说服别人最好, 最差也可以知道其他人到底是怎么想的, 是真的碰到过坑, 小心谨慎的做法, 还是纸上谈兵, 夸夸其谈, 这个时候也不必说服对方了, 做你该做的就好了, 可以迫于领导压力, 按她的做, 也可以吸收你觉得好的设计用上, 也可以尝试坚持自己的做法.

我一般不上来把人想的太坏, 先当他是个"理性人", 看看确实有没有一些道理, 当然不排除最坏的情况, 就是领导看你不爽, 如果最终你的结论是这个, 那就只有第 36 计了

[vmoewill]

他想得瑟就给他台阶下。

卡券微服务，有订单就再来个订单微服务，验证码通知啥的一个微服务。不要 mysql 全 mongo ，微服务全无状态，代码全用 etcd 锁，用 DDD 思想写，黑名单限制、ip 手机号、只能领 1 次多次各种各样的限制用策略模式封装下。这样基本就不是数据驱动了。

行了，充分的设计，开整吧，然后开发两周，部署一个月，devops 哭死 -。-！

[vmoewill]

@vmoewill 她

[danhahaha]

再拖几天, 这几天不要惹领导, 有可能亲戚来了

[fuchish112]

沟通问题，如果一次性的需求且急，那随意，如果不是一次性的，也不是那么着急，这领导说的也不无道理。

[weizhen199]

那啥，首先假定 op 是一个能力足以胜任这个工作的人。
你和领导的冲突点就是你“眼界”不够了，至于为什么会这样，一般都是你掌握到的的信息太少。如果除开你应该主动去了解的，就是任务传达的不够清晰。其实就是“精神传达的不够好”。如果你是高级职业，前者你的问题，后者是任务发起者的问题

[nuanshen]

这需求能居然能要到一周的开发时间，搁我们领导最多给三天（也是一前端一后端）

[ForkNMB]

要是下次还有这种类似的小需求又要重新搞一套吗 redis mysql 这些又要再堆一次
评审之初就有问题吧 应该提前拉上 leader 给出短期方案和做中台的方案
工时给产品或项管去选择 这样才比较合理

[zilongzixue]

楼上的人看的我想笑，戏咋这么多，这么能你们自己来写啊，既然要做通用的就应该事先说好，别一口一个口诛笔伐的样子

[yufeng0681]

1 、这个故事听下来，就不是一个 20 30 人的小公司。 应该是个 100 人的中型公司
2 、做了这么久业务，还没有一个营销平台，说明公司又不是特别的大，还在发展期
3 、女领导这么喷，也许就是 [苦秦久矣] ， 运营类的定制需求老是层出不穷，烦不胜烦 [我推测的]
4 、如果不是 [苦秦久矣] ，就是第一次有运营需求，那其实运营那边也无法提炼出来更多的扩展性需求，那你的方案只要加上 产品运营侧研讨过，这是一次临时试点，还没有到做运营平台的时间段的结论。 就比较全面，表示你考虑过得全面，做到了深入业务需求和可能性。
4.1 、还是要结合你们的业务，把运营需求规划起来。 做产品运营的没经验，可能多来几次需求，就会把你们带到坑里去。 所以提前研究，运营类的平台应该怎么做，怎么借助开源的，有什么已有框架可利用的。 毕竟运营类功能不是新鲜事物了，都搞了 10 几年， 通过识别竞品的实现，你反向还能约束运营的天马行空，不切实际，任性定制。
5 、系统设计师里面有架构师和业务设计两种，架构师的水平确实高一个级别，因为他看得更远；业务设计师，确实大家都能做的。你多参加公司更高级别的产品策划，可能就会知道公司的远景。 如果老被动等着产品推动你，那自己也不可能快快的升级，去到更高的岗位。

[ho121]

不要相信产品，除了他写的文档。就算是文档，也不能全信

[NGXDLK]

哈哈，心情好就考虑下扩展，心情不好就一把梭

[heyleo]

@xuanbg 是的，然后设计阶段设计半个月，实际开发一个月，测试半个月，加起来 2 个月。要不咱就这样拿着排期去问业务接受不？到时候业务老大怼你的架构师，这个锅算谁的？

[xiaotianhu]

@yufeng0681
老哥说的是。
可我司好几万人。我职级对标阿里 p6 ，我认为就是个干活的吧，说架构师肯定谈不上。但是老板总要说，你已经是个高级开发了，应该 xxxx 了...

营销运营平台这种事儿，咱也不是第一天做头一次做了。讲真，后续的需求，如果真的想全面设计，就要有更高层面的通盘的信息。举个例子，我们 Team 有 10 个产品，5 个开发，她作为技术 Leader 当然知道所有业务后续的计划，哪块应该复用怎么发展，但我不知道啊。跟我对需求的就其中 1 个产品。

我也做过领导，带过十几个人，也做过决策。你得有信息，信息越全面才能做出越靠谱的决策。大厂里的信息权，信息层级，真的是把「阶层」跟「官僚」这种概念体现的淋漓尽致了。当然这是另一个话题了，不展开了

[joApioVVx4M4X6Rf]

这种职场问题确实很难评价，，关注后续发展

[zzzzz001]

系统的混乱并非业务本身之复杂，我们并不擅长处理『简单』

一群高智商青年在餐厅吃饭，餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉，而标识为胡椒粉的瓶子里装得却是盐，他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个空碟子。当他们叫来服务员，准备炫耀他们的天才想法时，只见服务员什么也没说，只是拿起盐瓶和胡椒粉瓶，互换了瓶盖……


‘复杂’总是伴随着光环，当我们解决一个复杂问题后，我们会得到更多人的肯定，向大家证明和展示自己的实力。而简单往往更‘暗淡’，如同上文提到的互换瓶盖，大家并不会因此认可服务生的能力，甚至觉得也没什么大不了。如此往复，让大家更青睐复杂，更远离简单。

今天刚看了一篇文章：
https://mp.weixin.qq.com/s/Rk49n_QgHKPpbSyDj-vvHQ

[zzzzz001]

不要轻易地离开技术领域的一线前沿，离开技术、放弃编码的决定很可能会像你高考之后放下的数学、生物、地理等知识那样，一旦放手，毕生就很难有机会再重新捡起来。

久而久之，你对代码、技术、产品状态与团队研发状态的理解，渐渐和团队成员产生了偏差错位，丧失了细节上给予指导的能力，丧失了专业问题上提出接地气解决方案的能力，只能在无法“Show me the code”短期难以校验对错的大战略方向提意见，在会议、流程及团队管理措施上下功夫，在职业经理人式的宣讲与汇报上寻找存在感，此刻，你便从团队的导师变成了管理者，最终你与团队的关系，从携手并肩奋斗的伙伴，完全演变成只能靠公司制度与管理职位的权力来维系雇佣关系。


是不是似曾相识？

[xuelu520]

你们说说这个需求要怎么搞，才能符合你们说的？
领导纯粹想搞事批人而已。一个活动需求而已，就要搞个中台出来？需要小题大做吗？

[yaocai321]

哄一下， 别试图用技术征服她 懂我的意思了吧。

[rxswift]

领导想批人了，估计早看你不顺眼了

[InHello]

@hefish 想起一个笑话忘记哪里看的了，大概内容是领导要你写计划的时候记得犯两个错误，但是错误不能太明显也不能太深，太深了领导发现不了，太明显了领导会觉得你是故意的。总之一句话让领导觉得自己还很牛逼。

[weak]

女领导 ！

[justplaymore]

“咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。

好的架构应当是随着业务的发展生长出来的不是么。”

问题不在于你的设计方案是不是合理，而是你和领导对这个产品需求的技术方案设计方向的认知出现了差异。
不知道你和这个领导是不是第一次共事。
如果是的话，那就是缺少事前沟通达成共识的流程。
如果不是的话，那就是双方没有形成“默契”。

假如事前就和领导沟通过，把上面你的认知表达出来，消除不确定性，交换意见达成共识，那就没有现在事后“批斗”的事情了。

[xuanbg]

@heyleo 假设按需求本身，不加以深层次的分析就进行开发需要 3 天的时间的话，你深入分析一下撑死再加 1 周。怎么就 2 个月了？这不是罔顾事实纯纯的杠吗

[lululau]

直接 dui 啊：你不要老想着搞个大新闻，把我批斗一番，我见识的多了，开源的哪一个工具我没用过?

[lyeka]

如何设计取决于团队（ leader ）风格：
1. 如果团队一直是喜欢抽象，通用，偏 hacker 的风格，方案可以 over desgin 一些；
2. 如果团队一直以快速业务迭代为主，就按这种简单直接的方案设计（但是偶尔可以按 1 的方式来露两手）。
关键是看人下菜

[lambdaq]

和 LZ 恰好相反。需求方是 ♂ 为主，问就是「别的扩展性我不管，你什么时候能把我这个做好上线」。。。。


两个极端了。

[Timzzzzz]

哈哈哈 喵了两眼火气已经上来了 这人就不能好好讲话的啊

[simo]

@你领导 来，多方参与的事件，过来还原下现场

[Bluecoda]

我觉得没啥问题
用最少的代价达成现在阶段应该做的需求，快速投入，快速迭代难道不是现代产品应该具备的团队表现？
搞什么前瞻性设计？过度设计就是拖垮团队的最大毒瘤之一，在现阶段做一些未来不一定会用到的功能，如果每个功能都这么做，以后代码怎么维护？
好的架构，不是提前设计，而是可以快速适应新需求，如果未来需求不明确，那就制作 MVP ，因为就算抛弃重新实现一套也无所谓。

[adoal]

给领导准备好热水和布洛芬吧

[zzzzzzZ]

「我的设计思路很离谱么」
是的，可以说是没有设计，纯粹就是理解需求。先拆分表预留一些渠道、发劵管理、类型、商品相关联的字段和表设计，它也算设计。
2 张表就搞定优惠劵，还是最容易薅羊毛找漏洞涉及钱的业务，你真的没有上心。

「一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊」
没必要二极管，别人只是期望你交付的东西对得起你的职级（ p6 ），至少对你个人（或你现在的薪资）是有高期望的

「把所有技术拉过来开会，没有指名道姓但是基本上主要就是批我」
没点名道姓就证明 [不是针对你] ，主要是批你 [的思想] ，团队所有人的思想跟不上。你俩都不在一个拍上。

「所以老板到底想要的是啥子呢」
想要的是你能跟上她的思维，交付点专业的设计，所有设计她一个个盯一个个出再落实会很心累的。

「好的架构应当是随着业务的发展生长出来的不是么」
架构是慢慢补充和完善。但不是你这种 2 个表去重构的，不配，不如直接删了重做，你自己觉得呢？


做不到别勉强，多看看市场，试试转岗，有轻松的活给你干的。

[JNotEnoughW]

我觉得领导的问题比较大，需求边界定下来后，剩下的架构和代码设计能满足需求就足够了。

如果领导当初的需求并不只是在于此，有可能涉及的人员和范围就不是目前所涉及的，还有可能需要跨部门协作的，如运营端。所以我认为最终还是领导的问题比较大。

[bantianys]

先不假设领导是不是老早就不喜欢你。只说一个职场大忌，不要给领导惊喜。

这也是我曾经犯过的错误，一般水平低一些责任心差一点的还犯不了这样的错误，哈哈。

既要出活，又要给领导掌控感，才是合格职场人。

[unco020511]

你让他给点具体建议

[super452]

沟通问题，在做这件事情过程中，没做好沟通，导致双方意向差太多，另外，这个领导说话有点 pua 的意思，做好准备把

[sky857412]

不要过度设计，满足需求就好，这个优惠券活动如果只做一起，有必要搞那么复杂嘛，领导只是找个由头搞你

[Anivial]

redis + 两张表，然后说你设计不够好，那肯定是两张表的问题了呗，设计太冗余，感觉这种东西要么
1. 你领导对你不满意鸡蛋里挑骨头
2. 你们一开始需求沟通的基本思路都没统一

[darkengine]

几万人的公司确实得注意了，搞个小需求要玩出花儿来才有机会往上走。

[yufeng0681]

这么多 team ，这么多子产品，，公司还不小啊！ 运营这么不给力！
感觉不是互联网公司，蛮像手机类终端公司，野蛮生长起来的产品，还没有真正的运营部门。

确实是你领导的锅 [如果你没有遗漏信息的话]
1 、做设计工作，领导就要先定基调
2 、你做好了设计，领导要先 check 一次，不满意，要及时沟通，让下属重新设计；而不是直接开会批斗。
3 、开大会，批斗设计维度不够高，其实是砸她自己的脚。在她掌控的范围内（设计部），叫嚣没有架构思维， 就是在打自己的脸， 她好意思自曝家丑， 而不是关起门来，一起修炼。说明她自己就不知道怎么去设计架构，让下面的人一起往好的方向去努力。 颇有郎咸平的风格

[fzy0728]

年底了，开始要给绩效了

[jeesk]

上家公司也做过， 要说复杂的话，你半年都搞不定。
比如你的奖品要不要做 sku ? 奖品要不要搞个上架管理后台， 奖品要不要搞个采购平台。 你这个活动页面 可以配置多少个奖品，每个奖品分为几等奖？， 每个等级的奖品的中奖率动态调整，黑名单是针对奖品还是针对活动页面，还是针对创建活动用户提供的黑名单表？ 活动页面要不要开发拖动工具实现自定义，让运营自己动手就可以配置一个活动页面， 活动页面统计 pv ，uv 卖点？ 再对接一波大数据，分析每个手机号码的喜好？ 活动页面 要不要提供 saas ？ 你们领导以为项目一开始就能全部想到， 做梦吧。

[546L5LiK6ZOt]

如果产品设计上没考虑复用，技术上强行搞个中台，后续业务迭代产品肯定会提出很多没法复用的需求，结果中台就成为一个大杂烩，还不如不搞。。。

[jeesk]

我们做过和你一样的项目，大约有 50 多张表， 有 9 个服务。

[holy_sin]

以后有需求在考虑扩展啊，现在没需求扩展个几把

[YuuuuuuH]

@yufeng0681 你跟 53 楼完全是两个相反的评价

[kfansup]

就这流量和需求，设计文档都基本用不上吧。

[Seulgi]

技术领导的想法, 永远都是, 你不要太以需求的需求为准. 你要带着需求去考虑以后. 因为需求只会考虑现在, 不会考虑后面, 当然只是大部分需求, 有一部需求还是很有头脑的. 你得引导这种需求. 但是你这领导, 我的意见, 还是跑.

[Znemo]

现在产品都不知道以后要做什么，第一步就走的这么复杂，不也是一种挖坑行为么？

[hai046]

这还用写设计和文档？

[hai046]

我感觉不用写什么设计和文档吧，需求和技术评审过一下即可吧，感觉你写文档的时间我们就开发完了

[locoz]

看了半天感觉就是个沟通问题，不同经历、不同经验的人碰到同一个问题时的解决思路肯定会有差异的，比如清楚地知道优惠券这种东西能钻的空子有多多的人，一看你的描述和你这“感觉没啥”的态度就知道你估计都没考虑细节，处理得太简单粗暴了...

你领导说的话如果主要只是所谓“狂喷”部分中「」这个框里的那些，那有一说一真不是喷你，人家是在替你着想、替团队着想，只是可能你自己带着情绪理解出另一种意思了...人家的意思只是让你给自己多留点余地，也给后人留点余地而已，也没说要极端化到“活动中台”的程度，只是让你把这部分设计得更灵活些。开会说这事但没有指名道姓地说你，大概率也是为了将她的思路告诉所有人，“避免年轻人走弯路”而已。

你认为量没有那么大，需求也不会太复杂，就算改也很简单，没必要做得太灵活化反而导致开发和维护起来都更麻烦，那你就私下列事实摆证据跟你领导沟通，告诉她你的这些观点不就好了...她如果坚持要按她的思路来，那你就说如果后面改需求产生了很多麻烦，你自己负责想办法在期限前解决，这不就完事了？

单从你的描述来说，她在处理这个事情上没有太考虑到你的感受，是有问题，或许是事情太多、或许是性格使然，这从你的角度是看不出的，只有她自己知道。但你如果没有去好好沟通就开始生闷气，也同样是有问题的，甚至严格、难听点说可以是“沟通能力欠缺，性格怪癖，不适合团队工作”之类的...

[xiaotianhu]

@zzzzzzZ
老哥说的中肯，感谢。
领导要是能好好说话，容易沟通点就好了。
我在这的前途肯定没了，anyway ，我也没有继续较劲，按着说的来被。就是想了半天真挺摸不到头脑，你这一说有点思路了。

[locoz]

@xiaotianhu #32
“如果只是需求 by 需求的做，随便找个外包搞就行了”、“你已经是个高级开发了，应该 xxxx 了”
这种话也确实没毛病。如果只是完成需求，方法多得是，经济实惠的方法也不少，为什么非要招人？总不能是公司钱多了做慈善吧？

专门招人、组个技术团队，核心还不就是为了能更适应公司的特有需求，或者达到更好的效果...单纯写个业务代码、做个简单设计太多人会做了，同样的东西大概率你自己的小弟也能做出来，你自己想想应该也清楚。如果你没有体现出你的价值，那最后招你的责任还不就是归到你领导身上...

而且你是被按照对标阿里 P6 的标准招的，从你的“营销运营平台这种事儿，咱也不是第一天做头一次做了”来看，工作经验应该也不算少了，如果表现出来的能力达不到你领导、你领导的领导的期望值，那她当然会觉得不爽啊。

---

“如果真的想全面设计，就要有更高层面的通盘的信息”、“她作为技术 Leader 当然知道所有业务后续的计划，哪块应该复用怎么发展，但我不知道啊。跟我对需求的就其中 1 个产品。”

你有做相关事情的经验，也知道你自己掌握的信息不足，你认为就那一个产品讲不清需求，而她能知道你需要的信息。那你跟她沟通，告诉她原因，让她给你具体讲不就好了嘛？这不是一个简单的“我不知道”、“没人跟我说”就能完事的啊...你既然自己也带过团队，那你应该也很容易换位思考：

如果团队里人人都不主动沟通，只自顾自地做自己觉得舒服的事情，发现问题也没人说、没人尝试想办法解决，只能等到你这个 leader 发现。那且不说你作为 leader 累不累的问题，这个团队的存在意义都不大了吧...

[laLuna]

我只想知道不能领优惠券的黑名单咋来的

[mapoor]

我觉得应该是你没有理解项目的重要程度，以及领导对这个项目的重视程度。

从结果分析：很明显是你 **预估的开发时间太短**了。 并不是你的设计方案的问题。

[mapoor]

设想下如果你是领导，好不容易谈了一个大客户。
准备用这个项目打入新的市场。
准备大干一场的时候。
一个开发同事给你出了一份这样的设计，你会不会发飚？

[locoz]

@laLuna #73 参考比如淘宝、京东的”黑号“？比如大批量刻意薅羊毛的非正常用户，发现了就直接拉进去。

[exploreexe]

是不是看你不爽好久了。还专门拉个会，搞批斗
我 QNMD 吧，至于么，哪里设计的不好私下说就完事了，还搞这么大阵仗，你 leader 是个傻逼吧

[christin]

@laLuna 看风控要求，举个最简单的例子。
大批量短期内同 ip 注册的账号就拉黑。

[chevalier]

如果你领导之前对你没有意见的话，那么你遇到了一个好领导。

我工作十多年，是那种悟性很差的人，就遇到过一个这种领导，什么东西都要讲究设计，讲究复用性 /业务扩展性 /横向扩展性 /安全性 /可用性，他要 review 技术方案，至少改两版。在被他折磨的一年多，是我成长最快的一段时间。

你的技术方案只写了大概，我一眼就看出来一些问题，比如你用领取记录表来判断是否领过，如果遇到爬虫刷优惠券的，岂不是很容易就跪了，如果活动进行中产品要求每个用户每周都能限领一次，是不是很难扩展？

领导拉了很多人来“批斗”，应该只是想让其他同事也跟着 case 学习一下。

[SekiBetu]

时间规定多久，紧急的那没必要设计那么好

[forgottencoast]

@xiaotianhu
我觉得你的想法和做法是对的。
当然了，你要想在这个公司混得好，得领导认为你是对的才行。
上面很多人说领导怎么样怎么样，说的好像领导就是绝对正确的一样，就不许有个菜领导吗？

[work220602]

n+1 到手就行

[needpp]

@sadfQED2 盲猜鹅厂

[chuck1in]

@foolishnobody 真的假的，有想法的执行工具难道不会出现反驳领导意见的情况出现吗

[dlmy]

盲猜是某手机厂，领导是福报厂或菊厂出来的，写个 CRUD 都要讲一大堆方法论，你跟他想的不一样，他就当着所有人的面叼你。

[wangritian]

重要项目只分配了 1 个后端开发，并且开会时也没预先讨论如何预留扩展性，发现问题后又采取这么偏激的沟通方式，纯纯是领导无能

[bigbyto]

设计可能稍微简单了点。但我不认可楼上很多对楼主的批判。对着需求来实现有什么问题，在这个公司你可能被批判需求 by 需求，去到另一个公司可能又会说你过度设计浪费公司资源。要实现一个复杂的系统，需求文档却一点都体现不出来，我只能说需求传达存在严重问题。

不过这也算是给我自己一个提醒，防止以后的工作会遇到这么恶心的 leader 。

这就是 PUA 吧，很恶心。

[potatowish]

女领导是这样的，喜欢脱离现实

[moioooo]

我倒是碰到过很多设计了太多冗余，结果被批没啥用。
不过建议你还是听听领导的话吧。毕竟翻工重做还是得你来干活。

[zjuster]

产品没有说啥时候上线吗 ：）

另外这个问题，听领导的。产品有意见让他找他们的领导去。

[encro]

我做一个能通用的优惠券申请和使用，也就两天啊。。。。


一：

优惠券无非：
1 ，领取条件（如活动开始、结束时间，每人限制领取一次）；
2 ，使用条件（如最低使用金额，品类）；
3 ，优惠规则（如满减，折扣，赠品）；

以上是抽象，最终涉及数据库设计。


二：

这种运营系统，如果是自家公司产品，确实应该和需求方好好聊聊，考虑未来可能存在的形式，长期运行的可能性。
不要相信需求方的话，学会思考分析归纳总结需求，是一个专业程序员的基本素养。

有点经验的程序员都应该知道：电商系统活动那是常年执行的，花样是每周都变的，怎么可能是临时的？


所以：

所以可能是你工资比你女领导还高了，估计不是她招进来的，现在不想要你了。
或者上面对你有意见了，她想办法赶你走，她只是一个执行者。
或者，只是防微杜渐，是你想多了。


所以：

- [n] 发帖吐嘈
- [y] 总结不足，虚心请教。

[chenshun00]

先相信，再质疑

[lyhiving]

准备简历吧，这样的针对技术的质疑基本上都是搞事。

[SmiteChow]

她说得不对，设计只能刚好 cover 需求，不能过度设计；业务需求在改变，重构是正常的，不能重构的代码才是垃圾。

[foolishnobody]

@chuck1in
会出现啊，一决定权在领导手里，二看领导的能力和气度，三看员工提出反驳的场合时间。
是人都想轻松点，怕那种一根筋、教不会、听不懂的，
喜欢契合自己，机灵主动、办事全面的。

人性本性如此

[janus77]

这个问题本身的对错都是各有各的说法，我不予置评
但是领导因为这事直接开会批斗，说明还是倾向于把问题定性为政治问题——也就是是否听话、是否按规章办事，所以技术因素的占比是不重要了。如果你想解决问题，那就听话认怂，如果你想搞清楚答案，那各有各的道理，暂时只有你的一面之词我还是倾向于你的设计是没问题的，但是不排除你的理解会歪的可能性，毕竟从产品嘴里说出的“验证性”可不一定是 100%的，你天天跟产品撕应该了解他们的尿性

[sadfQED2]

@xiaotianhu #35 老哥，我目测你是百度的？ 百度女 M 标准话术啊