第81期 | 还在 996？说白了就是能力问题
你好，这里是卖桃者说，今天和你聊聊研发效率的问题。
前天在我的社群里分享了一篇吐槽国内互联网公司的文章，本意是：这么吐，姿势有点偏激了。说起来也是辛酸，大家都在疲于奔命，谁能比谁跑得姿势更帅呢，大部分留给别人的都是狼狈的身影，这也能理解。结果有个读者再次痛批 996，大意是：
996，互联网行业真的带了很垃圾的头，很多公司都这么明目张胆这么干，没有羞耻心，把程序员真当机器用，好的不学，坏的传播的很快。
这句话是不是政治正确不说，逻辑肯定有问题。996 泛指长期过载加班状态，这是互联网行业带的头么？没有互联网之前，我就知道，很多行业比我们这些在办公室敲敲键盘就以为改变世界的工程师辛苦多了。我哥 93 年大学毕业，进入设计院，从一个工程师做到设计总工程师和院副总工程师，到现在依然不分节假日全国各地跑着做项目。更多我们不熟悉的行业，比我们辛苦的多，只是那些群体不爱发声或者没地方发声而已。
至于把程序员当机器用，我工作了 20 年没遇上，我周边的朋友也没有一个是被当机器用的。你可以说我是认知偏差，但国内外很多公司都是推崇工程师文化的，这个不是骗人的吧。如果你没遇上，要么是公司的问题，要么是你的问题。
为什么会 996？因为有需求，因为正常的工作节奏完不成工作，因为恐慌，因为怕被竞争对手超越等等，就像技术进步、人类进化、社会发展一样，每一种形式都是对应需求出现的。一棵大树突然出现在你家院子里，肯定不是凭空冒出来的。996 最根本的原因是什么？
能力不足，或者说没有意识到自己的能力不足。
不仅是企业的能力不足，个人的能力也不足。当一个公司的研发效率、组织结构、员工能力无法支撑起有效率的研发和产品工作的时候，996 这种畸形的东西就会自然而然的出现。
比如说 Code Review，实践证明了这东西一定可以提高效率和代码质量，但很多企业就是不做或做不好，为什么？要么是驱动力不够，要么是能力不够。做了没效果，还不如不做，出了 bug 只能加班解决。我以前在各种团队里推动过 CR，效果都很一般，终于轮到自己创业做产品了，我告诉团队，我们必须把这件事做好，否则我们就不要做了。现在我可以说，Code Review 在我们的团队研发中起到了至关重要的作用。
如果你想了解足够多的 Code Review 相关的知识，可以打开极客时间，搜索 Code Review，文章和视频任意看。
CR 只是冰山一角。通过组织级的工程能力，团队的研发效能可以提升到一个不可思议的程度，比如我们来看这两个案例：
Facebook 的研发效能非常高，更是硅谷公司中的一个典范。比如，早在 2012年Facebook 月活达到 10亿的时候，后端服务及前端网站的部署，采用的是每周一次全量代码部署、每天一次增量代码部署，以及每天不定次数的热修复部署，但部署人员就只有三个，达到平均每个部署人员支撑3.3 亿用户的惊人效率。
又比如，社交网络出现 Bug 的时候，调测起来非常麻烦。因为要复现 Bug 场景中错综复杂的社交网络数据，困难并且耗时。但在Facebook，它采用开发环境跟生产环境共享一套数据的方法。这就使得开发人员可以非常方便地在自己的机器上复现这个Bug，进行调测。当然，这样的数据共享机制背后有着强大的技术和管理支撑来规避风险。
这两段话来自极客时间新上线的专栏《研发效率破局之道》中的内容，作者是前 Facebook 内部工具团队 Leader。
Facebook 能够做到这一点，就是不断提高研发效能，他们有内部工具平台，还会不断迭代自己的效能模型，持续改进。2017年，Facebook 引入了持续部署的概念和工程工具，进一步优化上线效率。试想一下，如果 Facebook 选择堆人堆时间的做法，那需要多少人，加多少班才能做到这种效果呢？
无论是你是团队管理者还是工程师，在业务方向正确的前提下，应该着力关注研发效能，从效能模型、研发流程、工程方法、个人效率、工程师文化等角度帮助大家远离低效加班的场景。
但现状是什么呢，很多程序员更多的兴趣和关注点在某个技术上，而不是研发效率，公司不去推进或者企业文化就有问题，团队 Leader 也会有心无力，最终大家的想法可能是，还是自己学好一门手艺要紧啊。
这种现象在极客时间上也有体现，比如架构、算法、网络这样的课程会有四五万的订阅，软件工程、10x 程序员、研发效率的课程订阅量就差不少了。
但是把时间线拉长，以后能活下来的团队，肯定都是高效能的团队，大家一定会越来越认识到有效性、效率和可持续的重要性。事实上无论是硅谷的顶级互联网公司还是国内的阿里华为小米，内部都有研发效能平台，如果你还在泥潭中挣扎，看看别人怎么做的，应该是非常明智的选择。
除了团队流程、工程方法，做为程序员个人，同样需要提高除了编程之外的效能，比如，深度聚焦最有价值的事，使用优秀的效率工具，Vim、Git、VS Code 这样的常用工具，你只是了解皮毛，还是行家里手。那么多命令行工具，你会用几个？你有为自己或者团队开发过效率工具么，有用自动化工具替代繁琐重复工作的经验么？
普通的太祖长拳，在乔峰手里即可以一当百，而寻常武师，也就是强身健体罢了。做为工程师，个人提升效率之路，漫长而艰辛，但总会有少数人走下去。优秀的团队和个人，也就是这一群人。
关于研发效率的话题，今天就聊到这儿吧，卖桃者说，明天见。
（编辑：成敏）