关于互联网公司的加班文化

怎么看互联网公司的加班文化呢?

是这样，一方面我特别理解创业阶段对执行力的迫切需求，这关系到公司的生存; 另一方面，我也亲见了以加班为文化的互联网公司，会遇到哪些致命问题。

在软件工程方法论中，有很多的方法论和经典书籍流传下来，指出在软件工程领域，研发力不能以”人数*时间”来计算，有本著名的书叫做《人月神话》，说简单用人月来计算研发力是个神话。简单通过增加人手或延长工作时间来企图增加研发力，都是错误的思路。其结果是什么呢?就是质量的下降和人员的流失。很多非IT领域的人，难以理解质量下降和人员流失对软件项目的危害性有多大，因为不像别的东西可以直观地看到。

那么危害是什么呢?IT有一个领域叫做设计模式，将IT项目比喻为建房子，而低质量的项目就像豆腐渣工程，没办法通过修修补补来弥补。典型的表现就是研发速度前快后慢，越到后面越接近崩盘。前人离职时往往留下巨坑一走了之，后人填坑填不好，又不好责怪，一逼人又走了，还得接着找人来修补，最后形成一个“恐怖地下室”，无人敢修改和接手。直到有一天，推倒全部重写，而这个过程，绝大部分公司承担不起这个成本。

这样的例子我见到、听到和读到太多了。

那么，什么样的方式才是正确的呢?

1、招优秀的人，发高薪，要求不加班但高产。所谓招3个人，发4个人薪水，做5个人的事。招不到，也要自己有机制培养优秀的人。

2、用正确的软件工程方法论，正确的流程，正确的角色平衡机制，比如scrum迭代或精益看板。这些敏捷方法论，都讲究一个“流”的概念，追求工作节奏没有波峰也没有波谷，不会一会儿特忙一会儿特闲，更不会长期连续处于加班状态。那是“看起来忙”，实则“出工不出力”、“效率低下”、“抵触情绪”、“流失率”和危害巨大的“低质量代码”，留下巨坑，最后还是让公司自己买单。问题的关键是效率的提升，而不是工时的延长，考验的是管理者的管理能力，而不是团队成员的工作态度。

3、做好项目的架构设计，高内聚低耦合，易扩展，易维护。将项目的必要文档要书面留存下来，让每个人都”面向离职”而工作，做到什么时候什么人员的离开都不会留下黑盒的隐患。架构设计很重要，必要的文档review也要形成机制。

这些全是管理上必须要做的功课。问题是，真正合格的管理者并不多，而这些人通常通过秀工作态度来掩饰管理能力不足的问题，实则害了团队也害了公司。

所以我个人是不鼓励加班文化的，很大程度上，这是管理者失职。对技术团队来说，尽可能在不延长工时的基础上，通过提高效率减少熵值来提高产出，才是真本事。如果哪位老板看到IT的team leader带着开发团队长期加班，而产出欠佳的话，不该想”他们尽力了”，而该想”这个leader能力怎么回事”？不该给他升职加薪，而应该把他开了。管理是个技术活，不是个态度活。

听到句话:“管理的本质是信任，不是监督”。不完全认同，也不完全反对。

“培养员工，让他强大到可以离开；对员工好，好到让他不舍得走” 这种观点看起来很美，其实实操的时候会有很麻烦的问题。

1、大多数人其实并没有清晰的职场发展计划，他们的追求仅仅是”钱多事少舒适区”。没有发展计划，也就没有主动工作，为自己而工作的念头了。这种类型的员工在绝大多数公司里都是主流，我们很难期待他们的主动性和投入度。用OKR代替KPI，其实难度并不小。

2、对于那种缺少”为自己而工作”精神的员工，把他们培养成能独挡一面，甚至能带领团队的核心骨干，会相当花精力，而员工一旦翅膀长硬了，上升空间、薪水奖金、大公司光环等等需求都会随之而来，这是人之常情。但公司要考虑成本，考虑组织架构等问题，不是所有需求都能满足到的。”对员工好，好到让他不舍得走”只可能针对少数员工，不可能普适所有人。

当然，我们可以用一系列的方法来尽可能解决以上问题，比如说，让员工有清晰的职业目标感，扁平化组织架构，招3个人发4个人薪水做5个人的事，阿米巴模式的跨职能团队等等等等。只是这样的文化必须自上而下达成共识，享受这种模式的好处，也承担这种模式的风险。

“管理的本质是信任，不是监督”，话说起来简单，真要落地，有一堆的配套事情要去做，”管理”从不简单。