说明
最近在Quora 上看到了一个有趣的问题，What is the best way to communicate to a software development team that they need to work more hours to meet a launch date? (该如何与软体开发团队沟通，请他们加班以让专案如期上线呢？)
问题原文如下︰
My team has a launch date two months out that we need to hit. Over the past year I’ve been comfortable with them working 40 hours per week, but momentum is slipping with vacations, early weekends, etc. I need to communicate that they need to step up their effort and work more hours per week until we launch.
我的团队有一个专案要在两个月后上线，在过去一年，我与我的团队每周工作40 小时，但专案进度因为假期等因素而有所滑落。我需要与团队沟通，请他们每周工作更长的工时，直到专案正式上线为止。
My question is specifically about the best way to communicate this request.
具体来说，我的问题是，我该怎么向我的团队沟通这样的需求呢？
就问题来看，发问者在团队中应该担任的是类似PM 的角色，而发问的内容在实务上也很常见，所以引起了不少人的回覆。其中在众多答案中，评分***的，也是最引起我共鸣的答案，是由前Quora 工程师Edmond Lau 所提供的(答案连结)。
Edmond Lau 在回覆中，说明为什么他认为超时工作不可行，并且分享了他个人在过去专案执行中，所遇到的惨痛经验。整个答案内文比原始的问题内文要长得多，但又非常实务 且有趣。我在读了之后觉得非常喜欢，所以想说就干脆把它翻译出来好了，希望也带给遭遇类似问题的朋友一些思考。
要说明的是，我不是专业的译者，所以对于内文的翻译，或许有错误或是不到位的地方(这很有可能发生)，都非常欢迎大家指正。如果有相关的经验可以一起分享的话，那就更好了，这也是一开始我翻译这篇答案内文，希望带给大家的帮助。
译文
在要求你的开发团队加班之前，请先确定你们目前的上线计划是真正可行的。如果如期上线目前看来只是痴心妄想(wishful thinking)，那么你***的策略，要嘛是根据目前的专案状态，重新订定到上线日时，你们可以交付的成品内容；又或者是，根据专案目前的进度状态，重新设定更可行的上线日。
处理滑落的开发时程，在软体开发上是很困难，但却不幸地是非常常见的事情。我参与过两个大型、开发时程横跨多个月份的专案，在这两个专案中，雄心勃勃的专案经理总是要求团队加班，以向专案交期冲刺。
在这两个专案中，因为我们被告知，专案一旦无法如期完成，将会造成严重的商业损失。因此我们团队中许多有天份且愿意付出的成员，拼尽全力试着达成这样”乐观” 的交期。我们的每周工时从一开始的60 小时，到后来成长到每周接近70 小时。
而在长达数个月的加班后，专案仍然结束不了。***的结果证明，在这样的专案马拉松中，我们只跑到了一半，而不是接近终点。无谓的加班冲刺毫无意义。 (It turned out that rather than sprinting at the homestretch of a marathon, we had started sprinting somewhere near the middle.)
在这些专案中，烧掉了团队成员们的热情，他们当中的一些人相继离开。而这使得团队中的其他人，要再花时间来接手离职成员的工作。短期来看，做出加班的决策来追求更多进度似乎是合理的，但长期下来都会伤害开发团队。
这两个专案的经验，教会了我们一个沉痛的教训︰当你希望一个专案在可以指定日期内完成，并不表示这个专案真的可以在这个日期内被完成。不要混淆「一厢情愿」和「对事物乐观」这两件事！ (just because you really want a project to be completed by a certain date doesn’t make it any more realistic that it will. Don’t confuse wishful thinking with realistic optimism.)
为什么超时工作不可行？
你的思路可能是这样子的︰目前进度已经落后表定的进度25%，所以为了赶上原订的专案交期，你需要使团队多花费25% 的工时以赶上进度。这表示在在未来两个月中，团队每个成员需要每周工作50 小时。 (译注︰原发问者说明他们目前是每周工作40 小时)
在这里我提供一些理由，来说明为什么这样的思考逻辑在实务上并不可行，与为什么加班并不一定可以赶上上线日期的原因︰
1. 每小时的生产力，会随着工时的增加而下降
如果你的团队已经习惯一周工作40 小时的工作节奏，额外的工时带来的边际生产力，很有可能比一般工时来得低，甚至很有可能是负的。疲劳与睡眠的减少，最终会伤害认知功能与降低工作的品质。
近150 年下来，关于长时间工作如何降低生产力的研究，可以总结在Sara Robinson 的Bring back the 40-hour work week 与Evan Robinson 的”Why crunch mode doesn’t work” 两篇研究文章中。 1890 年代的员工，在每天的工时为8 小时情形下，每位劳工的生产力较高[1]。 Sidney Chapman 在1909 展示，超时工作下，生产力会快速下降，劳工开始犯他们在充足的休息下，不会犯的错误。而后续的成本在，他们的产出在后续几天也会接着下滑[2]。 Henry Ford 在1922 年开始采用每周40 小时工时制，因为持续多年的实验告诉他这样的制度设计，可以提升劳工的总产出。 [3][4]
Tom Walker 在”The Prosperity Covenant” 研究中写下以下描述︰
「工作产出并不会随着工时的提升或下降，而有等比例的变动，这似乎是每个世代都要重新学习的教训。」 [1]
边际生产力下降代表即使加班可以提升团队的每周总产出，但总产出提升的幅度不会是你所预期的25% (译注︰代表即使总产出有所提升，落后的专案进度仍然赶不上)。但1980 年代的一篇研究”Scheduled Overtime Effect on Construction Projects”，甚至质疑加班会提升每周总产出的这个论点︰
「每周工时长于60 小时，持续两个月左右，生产力下降的累积效应将导致完工日期延迟，而延迟后的完工日期，甚至可能与在每周正常工时40 小时状态下的完工日期相同。」[5]
这个研究也许不是以软体开发工业为研究主题，但这并不能成为，我们不学习这100 多年来研究成果的理由。
2. 有很大的可能，团队目前落后的进度比你们认知到的还要多
精确的专案估计是工程中最困难的一项工作[6]，目前专案进度上的滑落，代表你们之前几个月的产出是低于预期的，而与其乐观地认为只有先前的产出预估低于预期，更有可能的是对于整个专案产出上的预估都是错误的。这也包括你们对于未来的两个月产出的预期。
使时程估计不准的效应更加重的情形是，我们倾向在专案开始时就可以将专案时程估计得准确，而此时我们预估时程的依据，都是聚焦在我们已经知道怎么进 行的开发工作上，而不是整体的专案工作项目。团队常会低估整合测试所需花费的时间，而这些被低估的工作项目，通常会拖累整体的工时数周甚至更多。
Frederick Brooks 将这个效应写在The Mythical Man-Month (人月神话) 一书中︰
「没有留下足够的时间进行系统测试，在特定情况下会造成灾难性的后果。因为在测试工作上的延迟，会造成专案时程的滑落，而所有人只有在接近专案的交付日前才会意识到这一点」 [7]
3. 额外的加班工时可能会烧掉你的团队成员
团队成员的加班工时，来自于牺牲他们额外的时间- 也许是他们与朋友或配偶相处的时间、运动的时间、休息的时间、睡觉的时间或做其他工作以外的事的时间。当我们希望他们牺牲这些时间，而改用高压的工时来代替时，所燃烧掉的团队热情将难以量化。
在Peopleware (Peopleware： 脑力密集产业的人才管理之道) 一书中，Tom DeMarco 与Timothy Lister 将其中一个这样的现象，称之为「偷工时间」(undertime)，而劳工在超时工作时「总是会帮自己挪出相同长度的偷工时间，以使自己的生活节奏得到补 偿」[8]
在我们的经验中，加班的正面能量一向被过份地夸大，而它的负面效应则从未被考虑。而这些负面效应可以说是非常实际的︰容易犯错、燃尽热情、加速员工的离职、和补偿性的「偷工时间」 (undertime)。 [9]
4. 加班可能会伤害到团队的热情
并不是所有团队成员都有余力可以应付额外的工时，可能有成员家中有小孩要照顾、可能成员花费在通勤的时间非常长，压缩了可以额外用来工作的时间、或是有成员已经规划好了未来两周的假期。
而一开始团队中处在正面的状态，所有人都聚集在同一个地方，每周工作40 个小时。但现在所有人被要求投入更多他们不能或是不愿意投入的的工时，其结果可能会导致原本快乐的团队成员之间的痛苦或怨恨。
5. 仓促赶工会导致额外的管理成本
超时的工作，会需要额外的站立会议，来确保每个成员正在做正确的事情，而不幸地的是，这些额外的会议与沟通成本并没有被纳入当初的工时预估中。
6. 赶工可能会造成额外的技术债
有项难以避免的问题是，当你要求团队成员超时工作以达成交期时，他们通常会在开发上，采取抄近路的方式以达成目标。
或许他们会负责任地写下笔记，告诉自已在专案结束后，要回头来处理这个问题，但他们在A 专案结束后，通常又会接着投入B 专案，而无法如他们的预期回头处理问题。因此在赶工的专案结束后，团队通常会留下一大堆等着未来要偿还的技术债。
上述这些成本不是理论，而是实际发生在我参与的专案中。而且很不幸的，这些情形在软体专案中是非常常见的。
但这些事不会发生在我身上
撇开上述这些长期的成本不看，我也理解改变航道与向上线日期说「不」的困难度。也许组织中的其他人都在期待这个专案的上线好一阵子了；也许这个专案 相当重要，以致于如果专案延期会造成商业上的损失；也许你害怕如果专案延期的话，你的团队不知道会发生什么事(译注︰XDD)；或者，也许你认为你和你的 团队的情况将会有所不同。
不论背后是怎样的理由，如果你仍然执意想要求团队加班，我建议你与你的团队多著重沟通以下的项目︰
1. 与团队讨论并厘清造成目前专案时程滑落的主要因素
专案时程的滑落是因为成员的松懈，还是因为开发工作比预期来得更复杂与更花时间？如果你不了解专案落后的根本因素，那你就不能说服大家这些因素，在未来两个月不会再发生。
2. 向团队说明真正可行的新时程规划，并向他们解释为什么这次加班，可以真的让专案顺利上线
只是告诉团队成员因为进度落后需要加班是不够的，如果你们讨论不出一个更仔细且可行的上线计划，那么这将是一个警讯。因为很有可能接下来所需的工作，会比你们现在所认为的还要来得多，而加班并不是一种好的解决方式。
3. 确保专案成员都对新的时程「买单」(buy-in)
如果专案的关键成员(key person) 并不认同新的时程是可行的，那你可能要思考，你是不是将「某件事要在某天完成」和「某件事『真的』可以在某天完成」这两件事搞混了？ (then you need to consider that you might be conflating what you want to get done by a certain date with what is realistic to get done by that date.)
如果你不让所有人买单，那将只有部份专案成员会真正加班来追赶进度，就算不论这种情况会伤害团队的公平性，你也别想让专案在你所预期的日期上线。
4. 与团队说明整体大方向，说明为什么如期上线对于组织来说是重要的
如果你不能将所有团队成员凝聚在一起，那这将是另一个警讯。因为所有团队成员，将不是和你站在相同的出发点，进行加班赶工。
结论
***，如果在这两个月的加班期间，你们发现你们的进度又一次在新的专案时程中落后了，那你们应该准备放弃这次的加班冲刺。接受你们目前仍然处在 在马拉松慢跑的中段，而终点比你们所预期的还要远(Accept that you might have sprinted in the middle of a marathon and that the finish line is farther away than you thought.)。在这种情形下，要求团队更加努力解决不了这个问题。你应该要做的是摆脱你的损失，并且花心思拟出下一个可进行的应急计划。
无法如期上线可能很糟，但更糟的是燃烧光了团队的热情，而仍然无法如期上线，而对于新的上线日期仍然无法有效掌握。处理滑落的上线日期并不是件容易的事情。
[1]: Tom Walker, The Prosperity Covenant: how reducing work time really works to create jobs.
[2]: Sydney Chapman (economist), Wikipedia.
[3]: Samuel Crowther, Henry Ford: Why I Favor Five Days’ Work With Six Days’ Pay, World’s WOrk, October 1926.
[4]: Ford factory workers get 40-hour week — History.com This Day in History — 5/1/1926, History.
[5]: Scheduled Overtime Effect on Construction Projects, Business Roundtable, 1980.
[6]: What are some ways to improve your project estimation skills?
[7]: Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering, p20.
[8]: Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, p15.
[9]: Peopleware, p179.
