为满足项目上线日期要求，如何让团队工作更多时间？

说明

最近在 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? (该如何与软件开发团队沟通，请他们加班以让项目如期上线呢？)

问题原文如下︰

就问题来看，发问者在团队中应该担任的是类似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]

#p#

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.

原文链接： Quora

译文链接： little lin