大千世界，我们眼睛所能看到的几乎都是表象，真正的本质是不容易触及的。大虾这里要探讨的是工作中的一些表象，以及如何触及本质。这里的本质并不是世间万物的本质，不要偷换概念哈，大虾也远达不到这个境界。举个大家最熟悉的例子：加班。之前看过一篇文章说的是金融公司来了一位职场小白，每天都非常努力加班到很晚，后来领导找他谈话了，大家以为这是一个励志的故事，错了，领导说：这几天我观察了你所做的事情，本来一个Excel公式就可以搞定，但是你每天都在重复着进行人工操作，所以大家干完活都下班了，但是只有你还在继续加班，你每天花很多时间加班，但是却不会创造出更多的价值，对你的能力也没有提高。你没有主动学习新的更高效的方法，只是沉浸在自己所了解的世界里，这样不但不能进步，反而对你的职业观会产生很不好的影响。
由此我们可以看出，加班没有好或者不好，因为TA只是一个表象，只有透过表象达到本质我们才能做到明辨是非。大虾公司也免不了加班，如果经常看到下属加班，我会跟Leader了解下具体情况。当然可能是自己能力跟不上，所以多花些时间在处理；也有可能是任务安排很多导致加班。针对不同的“本质”我们需要用不同的应对方法。如果是能力跟不上，就需要找团队Leader沟通，是否有给予TA更多的帮助，安排的任务是否符合TA的能力等等。当然如果已经无药可救的话，还是要放弃治疗的。如果是任务太重导致的持续加班，就需要了解这种状态大概需要持续多久，有张有弛才能保持团队的长期稳定和强大的战斗力。
聊到这里同学们对表象和本质有了大致的了解。那么我们什么时候需要去分析表象呢，该用什么方法来触及本质呢。下面我们展开讨论，由于人的精力是有限的，我们不可能对所有的表象都进行分析，我们只需要分析“异常现象”即可。什么是“异常现象”呢，同学们可能会想到：持续加班；bug率（比如：每1万行代码出现的bug数）太高 等等。其实这个理解是片面的，bug率过低也要引起我们的注意，这也属于“异常现象”。要判断是否是异常现象需要找一个基准。比如：来自组织的数据（大型公司会收集沉淀每个项目的数据，这些数据又能反哺新的项目。），历史数据，参照同行业等等。
下面我们还是用“bug率”来进行更深入的探讨。比如：根据组织提供的bug率数据一般在0.5~1.5%。那么如果我们项目的数据也在这个范围可以假定他是正常的。如果不在这个范围我们就要分析TA的根本原因了，即之前提到的本质。那么要怎么来分析呢，除了大家耳熟能详由日本管理大师石川馨先生发明的鱼骨图，大虾在这里介绍另外一种方法，这个方法来自于之前大虾公司使用的一个模板。就是不断的追问“导致TA的直接原因是什么？”，直到发现“根本原因”。一般问1到3次就可以发现根本的原因。让我们再次回到bug率问题，如果我们项目的bug率只有0.3%大家是不是很开心呢，别高兴的太早了。如果分析结果如下图所示，那么问题还真是不小啊。
当然分析下来也可能是非常好的结果。如下图所示，这种情况，我想可以让那几位工程师开个分享会了。
这里大虾只是简单的举了几个例子，其实TA的应用范围非常广泛，特别是做各种汇报时，如果出现了异常现象，一定要做分析，否则领导可不是那么容易糊弄过去。比如：项目结束后的，项目总结PPT上显示实际投入的成本比预计的高，但是最后实现的范围却比预计的小。就是说跟原计划相比，花了更多的钱却做了更少的事情。你简单一笔带过，领导肯定是不让的，也会对你的专业性和人品打个大大的问号。
文中bug率百分之几只是打个比方，一般千分之几或者万分之几。感兴趣的话，大家可以在网上查询CMMI不同级别对应的Bug率。
大虾出品必属精品，每篇文章都是十多年工作经验的总结，后续会持续更新更多质量，流程，工具方法，管理等相关软技能。无论走技术还是管理路线都可借鉴。如果您看完文章能有所受益，或者引发思考共鸣。请关注，点赞，评论哈，您的支持是对大虾最大的鼓励，也是大虾持续输出更多优秀原创的动力，感谢！
