为什么“赶工”没有收效

2004 年，某国际电子游戏公司员工的家人某 blog 中的述苦，引发了一系列的媒体报道和在线讨论。Evan Robinson 为 IGDA （International Game Developers Association）写了一篇文章，阐述了“赶工”没能收到效果的六个原因：

1. 在一个工作日中，生产效率随时间发生变化。在前四至六个小时里，生产效率最高。随着时间的流逝，生产力会降为 0，甚至会变成负数；
2. 对于脑力劳动者，生产效率很难量化；
3. 经过上一个世纪的研究表明，每周五天且每天八小时的工作时间，从长远看其产出将会最大。有什么理由让我们认为：我们这个行业可以不遵守这个规则呢？
4. 在每星期工作 60 小时的情况下，由于长时间工作而导致的生产效率下降抵消了几个月超时工作所带来的产出；
5. 每连续工作 24 小时，会使认知能力下降 25%。多个连续开夜车的人会产生严重的叠加后果；
6. 错误率会随连续工作的时间而攀升，尤其是在占用睡眠时间的情况下。最终，失败会找上门来，灾难也就发生了。当时间紧且预算大时，你真能承担这个风险吗？

的确，对于“每天八小时、每周五天”的工作制，是有据可依的。实际上自从 1926 年：

当 Henry Ford 在 1926 年采纳每周 40 小时的工作制时，着实被国家制造业者协会（National Association of Manufacturers）批评了一番。但是，他的试验（已经进行了至少 12 年）使他确信“将每天工作时间从 10 小时消减到 8 小时，且每周工作六天消减为五天”这一举措提高了总产出，并降低了生产成本。Ford 还热心地提到由于缩短劳动时间而增加了人们的消费时间，从而带来社会效益。但是其论点的核心仍就是“减少上班时间意味着更多的产出”。

那是什么因素让“赶工”最终对软件行业产生了如此大的影响呢？一般来说，项目计划是建立在某种有缺陷的假设基础之上的，即“要做的工作是定量的”，即被称为“劳动总量固定”的谬论。而敏捷方法论如Scrum 就不做这个假设。尽管它无法最终消除迭代的赶工，但它把赶工的时间按百分比加在了迭代上。因为不适当的计划制定或者是因为根本没有计划，频繁学习未知的知识会占用项目70% 的时间（参见" The Secret Sauce Of Software Development "）。

那么，假如我们（管理者）知道这是不对的，为什么还总这么做呢？Evan Robinson 的观点是：

管理者决定赶工是因为他们想告诉他们的老板“我做了我能做的事”。他们赶工是因为他们评估的是放在椅子上的“草人”而不是那些能开发游戏的“大脑”。他们赶工是因为他们没有认真考虑要做的工作，或没有考虑做工作的是人。他们赶工是因为他们只知道要表现出自己在尽力做好工作的重要性，而不是真正去做好工作。还有，他们赶工是因为他们回想到当他们还是程序员、测试人员、“助理制片人”或“副制片人”时，他们也是被要求这样做的。

Esther Derby 却有不同的观点，即：我们错误地计划了可能出错的东西：

我们来仔细回顾一下理解问题的各阶段。我们收集需求、开发分析模型，然后设计软件解决方案，并制订计划去构建和部署这个解决方案。我们提出一系列有序的活动合理地引导我们最终走向目标。
然而，当我们却跳过了一个重要的步骤：没有坐下来思考一下哪里可能会出错。当不良后果发生以后，我们才知道这些计划和设计中的缺点。即，“撞了南墙”才发现自己的疏忽，钱也花没了，也推迟交付了，还在质量上打了折扣。

似乎引起赶工的因素完全是人。您用什么方法与赶工现象做斗争？仅仅是工程学中“人”的一面吗，抑或，它是根本不必要的呢？

查看英文原文： Why Crunch Mode Doesn’t Work