更多内容关注微信公众号：fullstack888

今天刚好跟一个前同事聊一些以前加班的事情，他跟我吐槽公司加班的问题，但我管理的技术部门一直没怎么加班。就想起来之前为了达成这件事做的一些努力，本来想细说，但他好像不太感兴趣，结果我自己憋了一肚子话，不吐不快，不如分享给其他人吧。所以特此写了这一篇。

1，不加班的基本原则

原则上尽可能不加班，是为了把加班的时间用在刀刃上，用在非常紧急的事务里，我们不是为了“完全的不加班”，而是不希望把加班常态化，如果加班是常态的话，遭遇紧急事件的时候，就没有可用之兵了。

针对程序员这种职业来说，状态低下时的工作效率慢并不是主要问题，而是出BUG的概率提升了很多，而BUG 的修复时间又是不可度量的，又会因为需要修复加班时产生的BUG而加班，这就陷入了加班的死循环里了，对项目来说是得不偿失，并且无端端的增加了很多风险。

所以不把加班常态化，才是重点。而为了达成这件事，需要在管理上调整很多细节，不太能一蹴而就，如果没有合理的方法，只是一味拒绝加班，那反而会有不好的效果。

2，管理上的权限问题

首先最好的办法是技术管理权限最高的那人来推动这些方法，如果只是普通员工的话，也可以向上建议，但权限问题是很重要的，作为技术管理，一定要事先跟老板取得认同，让公司的主要话语人理解不加班原则，主要的说明方向是上面一条“不加班原则”，围绕这条原则跟老板解释不加班的合理性，只有先做到这件事，你才能推行下去，否则你的管理办法没有得到上级理解的前提下，是很难推动的，有时候会被误解为整体工作效率不高。

3，工期上的管理

工期管理是达成不加班的重要事项，一定要让所有参与者，包括你的客户，明白一个无可争议的道理，谁做事，谁对工期的判断最准确。当然这里有一个大前提，就是要有信任关系，如果不信任，别人就会怀疑你是不是虚报工期，这是很致命的问题，所以一方面你要掌握工期的主动权，另外一方面还要如实汇报，不要虚高，也不要虚低。否则一旦形成不信任，那么你就会立即失去报工期的主动权，不要因小失大，禁忌耍小聪明。

如果你没有掌握工期的主动权，那么客户就会自己报工期，但是他们并不是做事的人，他虽然有个期望时间，但实际上完成时间他是不知道的（除非他自己做，如果他自己做的话，又何必找你们），所以最合理的工期一定从做事的人说出来的，没有人比你自己更理解你的工作效率，当然一开始你自己也不能确定工期，这没关系的，他们只会比你更不确定。而且团队内的每个人都需要经常性的做工期判断，这样的锻炼能够让大家越来越准确的估算自己的工作效率，而准确的工期判断又会促进项目按计划完成，不准确的工期判断常常是加班赶工的主要因素。

而且你的客户会试探你的工作效率，你如果把加班常态化了，你很难在同一个客户项目上去掉这个习惯，因为客户已经掌握你加班过程里的产出率了，他只会按照原先的工作模式继续试探你的极限在哪里。这样对团队的压力就会越来越大，而产出的东西质量也会越来越差，最后虽然你满足了客户所有的幻想，你的客户却拿不到好的产品。这个合作关系也就到头了。

有时候你报的工期超出客户的期望时间，这时不是调整你的工期去符合客户的期望时间，这是一个坑，如果你的工期可以随便调整，客户只会觉得你报工期的准确度不高，又容易滋生不信任，解决办法就是调整项目工作量，或者加大人力，因为你报的工期是 N（日/人） 而客户的期望时间是N（天），这两者本身就不是同一个东西，比如你报的是10 日/人 ，客户希望5天内完成。那么切记，你的解决方案就是叫多1个人做，变成2人就行了。而不是调整你的工期变成5日/人，或者人力紧张的情况下，跟客户协调，调整一些需求。

调整需求的策略有三：下策是砍需求，把一些性价比低的需求协商砍掉。中策是需求降级，把一些复杂的需求降级，变成一些简化版的需求。上策是更好的替代方案，有时候客户提需求的时候，会假定某种解决方案，他不知道达成他的核心需求的方案有更简单更优秀的方案，这时候我们应该充分沟通，明白他的核心需求，刨除他的假想方案，给一个更好却更简单的替代方案，当然上策也不是时时能用的，看你能不能找到这个更好的替代方案了。

这个时候可能有人要问：如果有些事真的超级急，今天早上提，当天晚上就要。这种怎么办？那么接下来我们讲紧急程度

4，紧急程度的分级管理

如果你去问客户，或者PM，这件事急不急的？比较老道的PM会知道紧急程度，但是经常遇到不明就里的PM怎么办，他会说所有事都很急，因为你不是他的专属的程序员，他希望他自己的需求排在前面先做，客户也希望自己的需求先做，但是你没办法处理每一件紧急的事，而且有些事情是真的很急，有些事并没有他们口中说的紧急。团队里的每个人都应该明白这样一种紧急程度的分级管理，要非常具体的，能套用大多数情况，而且没有争议空间的紧急。

我按照我们之前的工作内容分了三个级别：中 高 极高

极高：就是跟一些时间节点高度相关的项目，比如圣诞节，情人节，游戏上线时间，宣发时间等

这个级别的紧急程度，代表一旦超出这个节点，这个项目就没意义了，或者大打折扣，做个情人节的网页，你不在情人节上线，前面做的事情就白搭了。或者宣发的资源都安排在这个时间点，钱都花出去了，如果不在这个点上线，就打水漂了。所以这种节点是极高的，其他所有项目都需要为这件事让道。

高级别：比上面那种低一个级别，就是承诺性的节点，客户有要求比如十月底必须上线，公司已经承诺出去了，或者PM已经协商好了，是某个具体的时间，但没有跟这个时间点相关的事项，其实超出的话也没多大问题，会损害一些商誉。或者这个节点有承上启下的作用，后面有其他团队需要在这个节点继续推进项目，如果你交货晚了，他们也会延后。

中级别：就是不能归类前面两种的其他事项。

这个级别管理是根据我之前的业务范围定的，是非常符合我前公司的日常工作，但不一定符合其他公司的，有一定参考价值，实践的时候要因地制宜，做一些调整。

分紧急程度的主要意义在于：有些事情虽然说得很急，但实际上今晚回家睡一觉明天做也可以。有些是真的需要加班了。

5，日常的一些细节

上面的方法论讲完，我们再说一点日常的细节，作为一个管理岗的职位，没事的时候你最好到点下班，要自己贯彻自己的原则，既然你希望团队不加班，你自己就别加班，否则你老是不走，其他人想走也显得不合适，还得陪你加班一样。

另外一个如果晚上遇到早下班的，也别顺口就问“怎么这么早下班？” 潜台词就是说别人不应该这么早下班，应该加班到很晚。如果遇到晚加班的。

你可以问“怎么这么晚？遇到什么事了吗？” 这句的潜台词就是，你怎么不早点下班，是有什么紧急得非做不可的事情耽误了吗？如果不是的话，不建议加班。

不要鼓励加班的员工，而是鼓励那些提高做事效率的员工，允许他们懒，鼓励他们为了懒而采取高效的办法。可以懒但不能拖延，懒有时候是一种做事的动力，而拖延只是把该做的事无限期的滞后，没有什么实际意义。

6，作为员工怎么向上管理

当然很多人不是技术管理，作为员工的时候怎么做向上管理呢？首先理念要一致，把加班的不合理情况尽可能向上汇报，实际工作中，多用数据跟实例来证明这个理念。

多做一些提高效率的办法，可以先在团队内传播正确的加班理念，然后在一些融洽的时机里一起向上反映，或者多利用工作汇报的时候夹杂一些工期管理建议，在例行谈话的时候，分享工作中的加班问题，收集其他人对加班的实际看法，然后输出给领导，在问及解决方案的时候把这套告诉他。

- END -

往期回顾

◆从 Java 8 升级到 Java 17 踩坑全过程，建议收藏！

◆关于Redis Bigkey问题看这一篇就够了

◆双活数据中心建设要点

◆中国工商银行基于 eBPF 技术的云原生可观测图谱探索与实践

◆轻松搞定亿级用户中心系统架构

◆流程引擎的架构设计

技术交流，请加微信： jiagou6688 ，备注：Java，拉你进架构群