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

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

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

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

这样的例子我见到、听到和读到太多了。我做互联网12年了，从雅虎、淘宝、新浪、盛大、1号店、1药网、创业公司转了一圈，大小项目、不同团队真的是身经百战，别说996了，连续通宵、过年不回家在公司带团队加班都有。从2010年开始，我学习和实践了一堆敏捷方法论，我以亲身经历负责任地说，没有什么公司有像样的工程师文化，敏捷方法论从上个世纪60年代首次提出没有银弹，到80年代出现scrum方法论、90年代出现xp极限编程，2000年提出敏捷宣言，再到之后出现精益看板，看似发展了好几十年，其实根本没在国内扎下来过根！

连product owner和scrum master都不区分，让产品经理兼项管，就充分说明了软件项目过程管理从来就是缺失的。最最能检验一家公司研发流程是否健康的问题是：当不切实际的工期被提上日程时，有没有项目经理有权力跳出来讨价还价?当研发进入迭代周期时，中途插需求改需求，有没有项目经理有权力挡住?当项目dead line到来时，研发团队是否可以准时高质量交付不延期?

一个直观的识别方式：team leader是那种项目启动会严格估时排里程碑，研发过程拦需求插入，不惜顶着巨大压力也要搞得需求方不舒服的类型，还是那种不扛需求方压力，拼命晒加班的类型?前者在救公司，后者在害公司。然而讽刺的是，公司老板往往是不懂技术更不懂软件工程的，所以会讨厌前者喜欢后者，你找谁说理去?几乎没有公司高管能认识到软件过程管理是个重要的技术活。你费力推行成熟的敏捷方法论，搞不好还会被扣个工作态度不好的帽子。

我悲观地认为，再过二十年，真正的敏捷也依然落不了地，依然是管理不行态度凑。深层次原因无他 —— 没人在意软件工程，包括程序员群体自己。别怨公司老板简单粗暴地要求996，先问问写了这么多年的你自己，你系统学习过scrum、xp和精益看板吗?也许你听过甚至用过TDD和结对编程，可你知道它们打哪儿来的吗？连天天写代码的你都不关心这些成熟又经典的软件过程管理方法论，你指望谁关心?谁都不关心，既然不能保证高效，可不就简单粗暴用996来延长劳动时间罗。

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

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

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

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

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

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

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

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

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

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

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

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