由一篇加班博客而反思的一些想法

最近看了一篇研发同学业内关于生病与前公司加班之间矛盾的文章，(在这里就不做引导链接了，因为我也不认识其人，但是与其前同事有利益相关。)描述了前公司是如何逼迫基层研发人员进行996甚至007加班的行为，由然而生很多想法。

关于加班

加班对于互联网公司来说基本上是常态。可以说除非“非常遵守劳动法”的公司，其他类型的公司都会疯狂要求员工加班。为什么会有这样的结果呢？据我这不到两年的中小型互联网公司内部观察来看，主要是几个原因：

1. 业内氛围
2. 上层管理层为了OKR
3. 人人都是产品经理
4. 业务多？
5. 假缺人
6. 真缺人
   下面我来逐一解释这些缘由。

业内氛围

因为这个社会是非常遵循“成功路线”或者说“成功模板”的社会，所以只要有为数不多的几家头部企业实行的“特殊”企业文化就会被逐渐传导到其他中小型企业中去，再逐渐在整个行业中实施。比如“35岁门槛”，“中台”，“KPI到OKR”，“抓手”，“996”等等一系列之前非常“时髦”的词汇逐渐推行到行业的各个角落。而我的前前公司之前都被誉为为互联网中的养老企业，部分部门最近也行业内卷到10点才能下班，有些也要求平均工时来迫使员工长时间“呆”在公司，逐渐Work-Life-Balance失衡。最近可能只有外企是研发人员的避风港了吧，可以让大家“躺平”。（说起躺平，在这里我想反驳一下那些说年轻人“躺平”文化的所谓的资深人士，请不要倚老卖老地说别人，有本事再来奋斗加班到007呗，现在大家选择的“躺平”又不是不工作，而只是在现有岗位上因无法上升而稳定工作，但是倚老卖老地人可能只剩下老了吧？你们有没有相过自己的医保还是我们交的呢？）

上层管理层为了OKR

正所谓新官上任三把火，在互联网行业也是如此。还记得在鞋厂的时间新CTO刚刚上任，要引入外部新的项目管理软件作为人员管理工具，并发送周报便于他选择性裁员。其实新管理层为了自己的业绩，在没有业务增长的情况下，最容易凸显自己价值的就是加班，让基层员工超负荷工作延长工时来达到整体工作处理量的提高。虽然大家都知道这些只是解决皮毛问题而带来一大堆负面效果，但是推手们为了自己的位置还是坚定不移的执行下去。

人人都是产品经理

这是几年前特别盛行的一本书，但是如今却是业内毒瘤。产品的PRD画得一届不如一届，对于问题的描述更是不清晰也不准确。对于开发而言，没有中间值之说，1就是1，2就是2。如果你跟客户可以协商，赔偿客户一些经济上的损失而缓和关系的话，对于开发而言，这个客户可谓毫不留情。他不会根据开发人员的言语而左右，只能根据“代码”所书写的逻辑而执行。但是产品PRD的质量之差可以说一届比一届差，并且令人发指。对于产品逻辑的定义不清不楚也就算了，有些甚至违背用户操作逻辑，更有甚者让开发人员定义交互，相同模块的需求还没有上线直接进入下一个迭代。这些问题在互联网的“高速迭代”中屡见不鲜。所谓的数据驱动最终做出来的产品也仅仅停留在UI、按钮的位置文案修改，并不能为产品本身提升更多的价值。所以我很建议一大部分公司的产品可以直接开了，直接让开发当产品，自我驱动研发。综上，产品考虑得不周全，可能导致研发估时时对于产品逻辑的理解有偏差，从而导致大量时间被浪费，并且产生估时与实际研发时间背道而驰。这是研发加班的最根本的原因。

业务多？

许多公司的产品团队可能几乎与研发团队的人员数量相平齐。这也导致产品的需求会成吨的涌向研发团队。此时堆成山的需求不断加入而没有项目经理把握时间成本就会导致研发团队不堪负荷。但是其实绝大部分小规模以上的团队都会有项目经理把控，但是研发团队还是叫苦连天。我目前经历的这几家公司的同事皆有此现象。如果非要让我归纳这一情形的话，我觉得从估时排期的任务就可以看出其实很多时候并不是真正的业务太多，而是由各个方面组成的问题：

1. 不调研直接估时
2. 对于业务不熟悉
3. 业务能力差
4. 别人叫累自己也不能显得闲

不调研直接估时

对于不调研直接估时并且喜欢把自己逼死的研发我真的无话可说，其实流程已经有让自己喘息的机会，可是自己不好好保证自己的研发环境，这还有什么好说的呢？

对于业务不熟悉

如果新接手的业务，当然需要多估时一点，研发的压力并不应该来自产品研发，应该来自自身能力的提升。经过资深的过渡，如果还不能实现快速接手项目，就需要对自我反思、归纳总结了。

业务能力差

在提升自身业务能力之前，需要先明确好方向与目标，然后是拆分任务与节点检查。当然绝大部分人都做不到自我任务拆分，所以即使有目标还是无法达到逐步提升的过程。业务能力差这个痛点可能只有换人能解决了吧？真正讲不听能怎么样呢？

别人叫累自己也不能显得闲

这种属于很鸡贼的人。但是研发团队有大部分人都是这样的人，大家逐渐内卷，但是还要陪跑那些比较落后的同学。如何可以避免这种风气？去除996，让大家在限定的工作时间内完成自己的工作，如果完不成自然就显现出工作效率差的人。

综上其实“业务多”并不是一个为加班定性的关键点。业务多，迭代多应该下班更快，既然已经“高薪”招人，为什么还使用低下效率的形式来实现慢迭代业务的流程呢？

假缺人

在团队发展的过程中，人员配置是让自己成为“大”leader的基本操作。带两个人做一块业务与带20个人做几条业务线是完全不一样的规模。很多比较有野心的团队Leader都是喜欢无限量扩充自己的团队，然后业务线拆分，最终自己快捷管理几个团队使团队逐渐阶级化，使自己Leader的位置更加稳固。所以业务线真的确认吗？连业务扩充都没有，业务量也没有增加，实在搞不清楚为什么需要招人，内心的小99谁不知道是在想什么呢？归根究底显示出自己团队管理能力的低下，无法为团队找出更关键的赋能点。

真缺人

随着业务的发展，业务线会逐渐扩充，管理层为了业务线可以多点开花，不免会提前产品发布时间，限定上线日期等条件，这时候是真正体现出“缺人”的状态。不过这也是产品形态生成的初期会是如此阶段，当然也有很多产品形态几年都徘徊在初期形态。当遇到初期形态时，经由几个版本可能会逐渐稳定，但是几年都徘徊于初期不稳定的形态时，需要考虑一下自己的团队管理是不是有什么问题，为什么不能在各个流程节点完成“需求调研、PRD评审、设计、技术评审、估时、排期、研发、测试、集成、回归”。

结语

本文是我一下午断断续续的时间完成。可能会比较凌乱，因为思绪并不是连续。但是也提现了当下互联网行业加班盛行的由上到下，由行业龙头到初入行业，由顶层管理到基层开发对于加班的应对及实施。

加班真的会让行业、产品发展的更好吗？在我看来可能5年的行业快速迭代可以以加班来解决初期发展问题，但是业内长期加班风气并不会对行业长远发展有什么帮助，为什么国外可以有更多的技术沉淀，而我们却只以技术实现为主？这应该是整个行业需要反思，加班到底给我们带来了什么，又剥夺了什么的问题。