谈谈996

bg
最近团队凉了,下一份工作又还没有完全落实,除了帮着处理一些公司解散的琐事之外,基本赋闲在家,每天遛狗、吸猫、看书、写代码、玩游戏、做饭、打扫卫生,累了就困会儿,精神好就出去遛个弯,过着令人实名羡慕的生活,也算是个Gap Month吧。最近GitHub上有个996.ICU的项目大火,我最近参加了几场面试,也读/重读了几本书,借这篇文章谈谈我的看法和一些思考。

面试经历

一周前我去某西二旗知名大厂面试,三轮技术面从两点聊到了晚上七点多,最后一轮的面试官在最后问了我两个问题:

  • 你能接受24小时随时待命吗?
  • 你之前工作的上班时间是怎样的?

我知道如果我渴求这份工作的话,我应该回答可以接受,甚至谎称我之前就996以证明我有足够的“自驱力”,但是我的回答令她失望了,当时的对话内容大概是这样的:

  • 面试官:你能接受24小时随时待命吗?
  • 我:紧急情况下可以,但是长期24小时随时待命我恐怕不能
  • 面试官:你之前工作的上班时间是怎样的?
  • 我:我之前九点左右到公司,没有紧急的事情晚上七点左右走,偶尔晚一点
  • 面试官:我觉得你的工作时长偏短啊,我们这里自驱力比较强的同学早上六七点就出发来公司,晚上一般都会九点以后才走
  • 我:如果确实有工作未完成的话,我也会加班去做,紧急情况处理到凌晨的经历也有,甚至周末也会处理。
  • 面试官:那你周末加班的情况多吗?
  • 我:不多。
  • 面试官:……

面试这种事情就像考试,如果你情商达到平均水平、对自己有清晰的认识并且不抱有侥幸心理,你其实可以得出结论,这次我不抱任何希望。回到前台归还临时身份牌的时候,碰到一个面试者过来告诉前台他约了七点半面试,希望他十一点之前能结束吧。

996是谁的错?

关于996的讨论非常多,有人提出了一个“不正确”的事实:

996是个市场选择,不是某个企业家,某个企业可以只手遮天的,没有谁有这个本事,给他们底气的,是那些排队等offer的应聘者。

上面是从经济学的角度得出的一个结论,但加班这件事不一定全是企业的问题,我观察到的加班分几种情况:

  1. 公司强制或暗示必须996
  2. 项目人手紧缺,项目时间紧任务重
  3. 自己承诺的计划未完成而加班
  4. 在项目中获得巨大成就感,加班一时爽,一直加班一直爽
  5. 回家没事干,在公司还可以享受一些加班的额外福利
  6. 并不想加班,但是Leader或者其他同事没走不敢走,担心与绩效挂钩

当你选择了情况1的公司,你唯一要做的事情就是权衡一下收益,你是否得到包括但不限于优渥的薪酬、个人能力及影响力提升、附属资源等,而你又不介意做出一些牺牲来换取这一切,那这是你自己做出的决定,你不愿意还有其他人排队,这就是市场选择。如果没有诱人的福利待遇,没有加班费没有调休,也没有什么成就感,只是你没有更好的选择而被迫996,你应该考虑尽快提升自己的能力,然后换一家公司。

偶尔出现情况2这样的情况是可以理解的,但是如果长期如此则是团队和公司资源的问题,通常是下面几类问题:

  • 对接客户时给了客户太多让步导致需求激增
  • 产品经理提出了太多反复修改的试(垃)错(圾)需求
  • 项目经理对成本核算有误,人员配比不当
  • 公司资源太过匮乏,一个人掰成两个人用
  • 团队凝聚力太差,效率太低

遇到这种情况如果你做的事情让你觉得有成就感或者有较大的个人能力提升,可以坚持一段时间,给出恰当的建议期待后面类似情况变少,否则你可以考虑换一家公司;

如果是情况3,说明你是一个言而有信的人,但是同时你错误的估算了周期。也有可能是你个人能力不足以至于需要花费本该用于工作的时间做知识储备,这种情况下你不应该计较加班,毕竟公司没有义务去付费培养你,而你有义务完成本职工作。坚持下去,后面类似的情况会越来越少。另外一种情况则是你给出了一个过于乐观的承诺,那你应该学会如何更准确的估算开发周期;还有可能是你轻易的答应了在原有的周期内增加新的来自客户或产品经理的需求,你应该学会处理这种情况。

情况4大概是最为理想的加班,你可以全力以赴投入到你热爱到事业里,不过如果你是领导,我觉得有必要告诉其他人,他们可以不必这么做,也不应该把下属员工是否加班与绩效挂钩;

情况5和情况6我认为是没有职业素养的表现。

学会拒绝与承诺

坚持原则

产品经理的需求一变再变,原定的计划增加了很多内容,但是deadline没有发生变化,那你很可能要加班去完成了,这时候我们经常会听到类似这样的对话:

  • 别在意那些细节了,我们没有那么多时间
  • 这里可以先“写死”
  • 后面再重构吧,先复制粘贴
  • 单元测试代码就先放一放吧
  • ……

如果你此前并未有所保留,如果你没有新方案,如果你不会改变你的行为,如果你对自己原先的估计有充分的自信,那么,从本质上讲,承诺“尝试”就是一种不诚实的表现。你在说谎。你这么做的原因,可能是为了护住面子和避免冲突

更具职业素养的做法应该是坚持自己的原则,去协商一个更合理的需求和期限。

专业开发人员不随便承诺,除非他们确切知道可以完成。如果你被要求承诺做自己不确定的事情,那么就应当坚决拒绝。如果要求你承诺在某天完成,但是需要每天加班,周末加班,取消休假,那么最后的决定取决于你;不过,不要违背自己的意愿去勉强

做出承诺

承诺是必须做到的。如果你承诺在某天做成某事,就必须按时完成。即便它意味着你必须每天工作12个小时,放弃周末的休假,也不得不如此。既然承诺了,就必须兑现

对比一下下面两种口吻,你觉得哪个听起来更靠谱?

  1. 应该可以在这周完成
  2. 我会在这周五之前完成

显然第二种才是真正的承诺,对自己将会做某件事做了清晰的事实陈述,而且还明确说明了完成期限。这种信心来自于对需求和个人能力的合理估算,你应该尽早掌握估算的方法,避免因为估算错误导致无尽的加班。

如果你无法兑现承诺,那么最重要的就是尽早向你的承诺对象发出预警,越快越好,越早越好;如果你不尽早告诉他人可能的问题,就错失了让他们帮助你达成目标、兑现承诺的机会。

如何估算开发周期

提到估算,可能就让人想到被制定甘特图支配的恐惧。无论你是作为项目组的一个成员还是领队,给出尽可能准确的估算无疑是一项重要的技能。我在《The Clean Coder》这本书里了解到了计划评审技术(PERT,Program Evaluation and Review Technique),据说是为支持美国海军的潜艇极地航行计划而诞生的。PERT的一部分内容就是对预估的计算方法。这种技术包含了一个非常简单而有效的办法,把预估变成概率分布。

你可以根据3个数字预估某项任务:

  • O:乐观预估。这是非常乐观的数字,如果一切都异常顺利,你可以在这个时间内完成。这个数字对应的发生概率应当小于1%
  • N:标称预估。这是概率最大的数字。如果画一张概率分布的柱状图,标称预估就是最高的那个。
  • P:悲观预估。这是最糟糕的数字,它应当考虑到各种意外,这个数字对应的发生概率也应当小于1%

例如我们有一个任务,最乐观1天就能完成,不过大概率需要3天,而最悲观的情况下可能需要12天才能完成。我们可以用这个公式计算出期望完成时间:

μ = (O+4N+P)/6

代入公式后计算得出期望时间约为(1+23+12)/6 = 4.2天,然后用下面的公式计算概率分布的标准差:

σ=(P-O)/6

即标准差为(12-1)/6 = 1.8,所以这项任务大概率需要5(进位取舍)天完成,但是也可能需要6天(μ + σ),极小概率下可能需要8天(μ + 2σ)。如果你有多个任务,只需要计算总的期望时间和总标准差即可。例如三个任务期望时间和标准差分别是:4.2/1.8、3.5/2.2、6.5/1.3,则

μ = 4.2+3.5+6.5 = ~14

σ=√(1.8^2+2.2^2+1.3^2) = ~3.13

即大概率需要14天,可能需要17天,极端情况下可能20天。

德尔菲法

上面的方法主要是个人计算,不过在团队协作中,综合周围的人的意见能更为准确地预估任务。其实也很简单,我们可以让大家一起讨论任务,针对每个任务,参与者根据自己的判断同一时间说出数字,如果没有太大的分歧就讨论下一项,否则讨论分歧。如此重复直到统一。德尔菲法有很多种玩法,具体你可以参考维基百科

拆分预估

你可以把一个大的任务拆分成较小的任务结合上面的方式去评估,最后再汇总到一起计算,通常这样会发现更多的细节问题,使得结果更加精确。但是也要把握好这个度,否则会适得其反。“度”听起来很玄学,因为这没有固定的标准,你需要你花时间去练习摸索,积累经验,这也是为什么资深工程师预估开发周期会更准确的原因。刚开始时你预估的周期也许会出入较大,坚持下去误差就会逐渐减小。


文中提到的方法来自于《The Clean Coder》一书,我认为这是一本工程师的必读手册,推荐大家阅读和践行。

更多

坚持原创技术分享,您的支持将鼓励我继续创作!