技术

二缺运营配上苦逼程序员

前段时间情怀锤在假货淘上出了点事, 关注了的人应该知道大概是怎么回事, 为了方便笨狗吐槽, 再把事情简单说下

锤子手机在天猫上做预售, 让买家去预定, 页面上会显示一个当前预定人数
有好事者发现这个预定人数无论在什么时候都能被 3 整除, 而且新点一下预定, 页面上的数字会 +3 而不是 +1
然后有人翻页面代码发现是前端的 js 里做了这个 (order_num)*3 的操作

天猫那边开始调整, 中间还出现了 6xxxx.5 个人预定的情况, 被吐槽半个人是怎么来的, 应该是 *2.5 了
而且还有 *0 变成前端显示 NULL 人预定的情况, 最后这个地方变成了 (order_num)*1
发现事情闹大了盖不住, 天猫官方微博帐号发声明说后端丢数据, 程序员为了让数字看起来正常点自己乘了三

被愤怒的程序员吐槽扯鸡巴蛋并且翻出来金立等品牌这个地方也有乘系数等操作, 明显看是个模板配置
再然后有内部人士表示这个地方其实就是个可配置的公式, 运营就可以操作, 不需要过程序员和走上线操作
最后终于某高管私人微博帐号发个靠谱点的公告处罚了一堆人, 并且向程序员道歉, 当然还嘴硬只是显示问题

其实懂的人一看就明白是怎么回事了, 运营想获得一个更好看的数字, 就要求程序员在后端数字基础上做一个放大, 但是不同的时候放大系数不一样, 技术部门为了省事, 运营部门也想要更大的控制权, 就把显示的地方弄成一个可配置的公式

按阿里系运营才是老大的风格, 这事多半还是运营部门主动要求技术部门去做而且放开所有控制的. 不过阿里的技术那边也没做好, 比如居然能出现小数, 好歹也取个整吧, 比如乘 0 后前端显示异常, 这个也弄个最小值限制吧. 执行的运营也比较二, 乘三这个太容易被发现了, 你看看人金立, 乘个六后面还加个常数, 这边要是乘三加一或加二, 估计一下还没人能看出来, 当然, 乘七再加常数就更好了. 对运营的智商做乐观一点的判断, 可能他们还是考虑过为什么乘三的, 因为乘 2/4/5/6 更容易发现, 不过因为他们的智商也就只能数到六, 没有再往下试下 7, 也不知道在后面加个常数

这事被爆出来, 很大的原因应该是这次是给锤子做预购, 老罗一直满天下吹牛逼, 吹的很多人都路人转黑, 碰到出糗的时候大家都很兴奋, 虽然事后罗永浩说他们不知情是躺枪, 但是我觉得他们还是脱不了干系, 这事做成这样不可能不知道, 至于罗永浩本人是否提前知晓这个就不好说了, 反正作为一个喜欢看说大话的人出糗看热闹不嫌事大的笨狗, 表示老罗能吹出那么大的牛, 各方面也还是要做到无可挑剔才行. 至于金立什么的那才完全是莫名躺枪, 本来就是行业内的潜规则, 这下没得玩了

这一次的事情, 应该会让更多技术线的人, 在选择工作时会偏向非运营主导的团队. 因为在运营主导的团队里, 技术人员完全没地位, 运营说做什么就做什么, 说做成什么样子就做成什么样子, 长此以往, 技术人员自己也会变傻变钝, 比如这次如果技术还有点自己的思想, 就应该知道在满足运营要求的同时, 自己也不要对运营人员的智商有太高期望, 取整和校验还是要做下的

想起来以前在某家的时候的一次大事故, 也是运营配错个东西, 导致线上所有流量没有广告. 当时几乎整个公司相关的技术团队全部投进去查问题了, 还算快的响应, 半小时后技术这边查到是有 PM 配全局关键词黑名单的时候写了个 *, 就是所有的词都不行. 事后该 PM 也很牛气的说这个事情是我做错了, 责任都我来承担, 不过你们技术也有问题, 系统上也不做下校验就把我这么放过去了. 看看, 技术从来都这样好事轮不上, 出事要背锅, 当然了, 这次事故里技术那边做这个黑名单系统的时候加一些校验也还是有必要的

类似的需求一开始的时候多半是临时需求, 说做完以后就不用了, 所以先短平快搞个能用的. 等后面发现临时需求变成长期需求时, 现在系统能用, 再去完善的工作算不进 KPI, 那也没人有兴趣去搞, 反正之前的需求方自己也知道细节, 不会出事. 等需求方那边换人后有一些细节可能没交接好, 那就要出事了, 比如公式里一定要全部是整数操作等

扯了这么多笨狗想说啥? 一是团队里技术要有发言权要有地位, 而且这个地位要自己不断用事前正确判断来证明自身争取而来, 自己不去想只管做傻事那也别怪自己没地位; 二是不合适的 KPI 文化会害死人, 比如技术因为不算 KPI 不会去完善临时转长期的系统, 比如运营会为了 KPI 数字毫无底线的造假; 三是阿里系和锤子的品德还是有问题, 脑残粉会说做到这样已经不容易了你看看行业内其他家做的更脏, 笨狗的观点是你自己说成什么样就要做成什么样, 别管别人脏不脏

最后来个段子吧

上天猫, 乘以三, 就够了