技术管理之如何协调加班问题

时间:2022-11-22 13:09:11

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

1,不加班的基本原则

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

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

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

2,管理上的权限问题

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

3,工期上的管理

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

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

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

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

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

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

4,紧急程度的分级管理

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

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

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

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

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

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

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

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

5,日常的一些细节

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

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

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

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

 

5,作为员工怎么向上管理

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

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

以上就是关于如何处理加班问题的建议,如果大家感兴趣的话,我可以再出第二期讲更多细节。