1. 事件原委
事情是这样的，厂子搞性能优化，有个同事在一个季度中完成了好几个不错的指标，并兴高采烈地加入到了将要发布的版本中。但是Team Leader知道后，直接让先下架几个指标，让等到下个季度再上线。
2. 原因
2.1 根源
对于上述事件，一些职场老鸟可能秒懂，尤其是长期在中大型厂子就职的开发老鸟们。其实要理解这个事很容易，以前经常听到这样的一个段子：
在外包公司，经理让程序员故意制造几个小问题，如某个重要功能数据加载迟缓。虽然客户仍然能正常使用功能，但是每次使用想必都是骂骂咧咧的。然后用户在交付使用若干日后，实在受不了这样的体验，找到公司提出优化。经理欣然同意，但是得加钱，而实际工作量可能就是注释掉故意留下的问题代码。
上述的段子其实并不仅是个段子，笔者朋友也真实遇到过。外包公司为了多赚几笔，故意制造小问题，等待二次收割。那么这个段子与文章开头的事件有什么关联呢？这就不得不提到在中大型厂子中非常流行的几个词：OKR、KPI，也就是所谓的绩效考核。
2.2 长远考虑
一般在厂子业务旺季时，大家伙的绩效大都会与业务挂钩，绩效一般也相当体面，毕竟老板赚钱了，不会太严苛。而到了业务淡季也是有绩效考核的，这时没钱赚了，那么绩效从哪里来呢？很多Team Leader第一反应绝对是性能优化与技术升级。但是性能优化指标也是有限，那么从长远考虑，为了防止下次的绩效考核没有成果，有的Leader在本次考核完成指标后，不会再继续锦上添花，而是把剩余成果留到下次考核使用。现在是不是感觉和上面的段子有几分相似的味道了，一波成果，多次收割。
个人观点
其实上述现像一直是个争议较大的现象，那么我们是否应该把本来能一波上完的优化，分批次上线呢？个人看法这取决于优化对象的优先级，如果是那种直接影响用户使用体验的优化，例如崩溃、卡顿等，需要快速上线；如果是类似电量优化这种不会直接影响用户使用体验的，可以分批上线，毕竟绩效可关乎着工资与奖金呢！同学们，对这种操作你们怎么看？
