今天在网上又看到一件让人感到匪夷所思的事情。领导排查项目，发现代码注释率不足，结果同事为了提高代码注释率直接向代码插入数百章斗破。
第一眼看到这个新闻我第一反应是扯淡吧，但是转念一想还真的未必。
我不知道有多少搞开发的朋友们遇到过这样的领导：
- 根据代码行数确定每个人的工作量是否饱和。
- 根据每个人的BUG数量确定是否工作能力不够。
- 根据解决BUG数量确定当月绩效指标。
- 要求每行代码必须有注释。
- 根据日报的详细程度确定有没有在摸鱼。
- ......
虽然奇葩事儿天天有，但是像这样奇葩的也确实少见。
为什么领导总是用开发看不懂的指标来衡量
花样繁多的管理手段背后其实真正的原因很简单：压力！。
部分领导本身并不是专业出身，习惯于看报表，听汇报的他们并不懂得项目管理的有效手段到底是什么，所以他们就会自然而言的使用可以量化的指标来进行衡量。
但是项目进行过程中很多东西都是无法直接量化的。比方说一个关键性的技术问题带来了系统性能的翻倍，但是这个问题的解决者可能用了一天，也可能用了一周，这种指标很难呈现在纸面上。
而相反，代码行数、工时数、BUG数等等都是能够直接量化出来了，而且指向性非常明确。
这种指向性非常明确的量化指标呈现在PPT上就是非常显眼，并且可以向上级汇报的数据。
我想没有哪个领导不原因听这种汇报，原因更简单，无需再做权衡，数据的指向已经非常明显了。
而领导们听习惯了这种汇报也就自然而言的要求每一个下属都要做成这种指向性非常明确的汇报数据，避免自己出现错误，也避免自己背锅。
开发到底应该怎样应对
总结一下：兵来将挡，水来土掩。
作为底层开发人员，我们很难将自己的声音传递到上层去，所以大部分时候我们能做的就是维护好中层。
他们提什么指标，我们就往那个指标上靠，这是最稳妥，也是最有效的办法。
如果他喜欢用代码行数去衡量，那么本身能够用三元运算的完全可以改成 if else，我想谁也挑不出理。
如果他喜欢用BUG数去衡量，那么我们就相应的减少其他方面的内容，只往代码稳定性上发力。
可能有朋友表示，这还用你说废话。这种根本不算是解决方案！
但作为底层开发人员，拥有向上管理的能力和方法本身就很难，更不要说你想要改变一个人的想法。
我们能做的仅仅是自保而已，升级一点的做法或许也只是能够在同事们的竞争中脱颖而出，自己坐到中层的位置上去。
结语
其实现在企业管理过程中，如果强调层层压实责任，那么在执行中一定是层层推卸责任。谁都不想背锅是人的天性，而底层员工推无可推，能做的就是背锅。
既然结果已经定了，那么剩下的时间就是找理由了。
当企业陷入困境，老板对于管理层的信任不再，那么管理者一定会选择风险最小、汇报最优的管理方式。
这时候数据的美观度其实超出了实际产出的重要程度，所以这些奇葩的事自然也就不再让人感觉奇葩了。
