加班能解决交付的期望么？

大小周、996，近年来不绝于耳，由于雇佣双方对此的态度各异，是个很敏感的问题。近期有一些感悟，把这个老生常谈的话题聊一聊。



团队A，业务的需求一般是第三方接入，发布后就可以见到收入，期望是一两天内上线，而研发团队的交付期常常是四五天，大小周的工时制度还是赶不上进度。期望和结果差异悬殊，而团队保持着按点上下班的模式，必然招致管理者的意见，第一个被想到的办法就是加班。



团队B，产品迭代的版本节奏，能按期发出，但每个发版日都会熬夜至半夜，上线后各种问题频出，不得不先灭火。回顾时却各有各的情况，抓不住头绪。



团队A的结果不得而知，不过从团队B的经历可窥见一斑。

从过往的讨论看，这在很多团队是普遍存在的情况。



管理者带队时，不自觉地会选择加班或压时间这种“低效的勤奋”，汇报时美其名曰“团队氛围好，非常努力”，而对结果和效率的最终产出却毫无所知。



员工在这种体系中，加班写需求、加班上线、加班排查线上问题、加班救火，陷入忙了很久，回顾却没有任何成就感和能力进步的怪圈。



团队很难满足不断增长的交付要求，在某个高压节点扛不住，士气下降、换人再来。



如何破局？回溯根源，拆解一下问题的本质。职场的每一项行为都是面向商业结果的，或者是按岗位拆解后的中间结果。

产出  =  效率 *  时间



想要提升产出，无外乎效率和时间增加投入。提升效率需要更多的功夫和时间，见效慢但是天花板高。增加时间见效快，但是瓶颈明显。因而从不同角度，有如下的方法。



当得到加班的要求时，先应该区分这是个短期还是长期的目的。



一个突发需求或重要任务，而日常产能不满足时，这是一个短期行为。管理者应当以面向结果的交付内容为方向，使用任何方法去达到商业目的。包括增加工作时间（加班）、提升工作密度（加人）、保证核心交付物（砍需求）。



如果是从长期的角度看，那意味着需要分析团队面对的真正矛盾。每个行业都有客观规律在内，很多表面的事情，实际的原因大多隐藏在背后。



以团队B为例，解决的方式出人意料。版本排期由研发人员给出，但是在团队review时总会被压缩一天。当不再采用这个方式后，第一个迭代就恢复正常。以此为基础，产出非但没有降低，每个迭代还不断提升产品技术质量。

体系建设是管理者最重要的任务，寻找影响工作效率的问题，提升团队的单位时间产出。在我个人的经验中，认知、信任、协作、工具、个人能力，这是几个循序渐进的方法，贯穿在其中的重要台阶是解决每一个细小的问题。



如果一个团队总是在加班处理各种事务性的工作，大概率是有核心矛盾没有解决，无非是流程、制度等协作方式，或是工具、平台等的效率杠杆，亦或是历史债务、体系架构的陈旧负担。



“什么是当下体系建设的主要矛盾，做什么事情，可能让团队有 10 倍的效率提升？” 



不怕有问题，怕的是没有深度的思考。有充足的依据和胆略做出相关的决策，相信团队会给予 10 倍的正反馈。

对于个人而言，我自己认为在大多数的情形下，加班都不是个考虑的必要问题。



可以看到在疫情期间，医护人员无眠无休，基层干部社区拉网放弃家庭，教师花样备课教学，哪样都不是在正常办公期间的要求。



干一行爱一行，短期倾情投入的回报从长期来看没有差的，时间是我们唯一可以掌控的东西，以时间换回报也是最有杠杆的方式。



从长期看，应该关注自己是否在不断提升效率。过去需要三五次重复才能做好的事情，是否可以一次搞定。过去需要思考很久的工作，是否能够快速下手。



在这背后，投入的时间应该有足够的比例是思考，转化为经验的积累、方法论的沉淀。有复用价值的获得是我们唯一要关注的，而不是投入的时间或者加班这个行为。



至于大小周和996，我们国家的现实是工程师红利，尖兵和突破要有各项资本的加成投入。周瑜和黄盖，按自己的承担能力去选择和规划吧。

回答题目的问题，面向结果，加班只是一个短期的手段。为团队为个人，积累可复用的价值，是不断提升交付能力的唯一方法。