打工人谁不知道 deadline，尤其是那句「Deadline 是第一生产力」。deadline 本身没什么问题，很多情况下它的确能够提高生产力，但 deadline 需要合理的理由来支撑。「只是因为」（没别的原因）可不是什么好理由，这会给开发者带来伤害。
12 岁开始编程、具备十多年开发经验的 JavaScript 开发者 Rene Pot 讲述了他的经历。
Rene Pot 自述：不合理的 deadline 给我带来伤害
我曾经在一家创业公司待过，当时的前端和后端团队都只有 3 个人。我们在开发一款移动 app 的新版本，当然公司设置了上线的 deadline。但 deadline 是公司 CEO/CTO 设置的，理由并不充分。
当然，说它完全不合理似乎也不对，deadline 的设置应该基于对开发者能力的估计。
如果你是一名开发者，或者经常和开发者合作，你应该明白问题所在：「估计」只是估计，通常并不准确。其背后的原因不是开发者能力不够，而是对整个项目作出估计是件非常困难的事，很多完全预想不到的因素会将你的事先估计完全颠覆。
当时对那个项目的预测是经过两天会议讨论得出的结果，会议探讨了新特性，并将每一个部分彻底分解。每一部分都经过了估计、交叉估计，UI 和 UX 设计已完成，所需时间也得到计算，再加上一些缓冲时间，最终得到了 deadline。
你可能会想，既然 UI 和 UX 设计已经完成，还考虑了缓冲时间，这个估计应该很不错了啊。
然而，事实并非如此。
最终的开发时间估计是 3-4 周，这对于小团队的新 app 发布项目而言并不算充足。
的确如此，两周后，项目进程已经跟不上日程表。原因不是开发者干活太慢，而是事情的发展往往与预期不同。
后端团队在实现移动 app 的 API时，发现该系统无法正确处理简单的 add-on 组件，这意味着他们必须将现有 API 的一部分进行重写，这就导致 API 端点的完成时间比预期推后了两天。
而由于重写，API 的运行与之前会议所探讨的略有不同，这又导致团队重写了 app 的一部分，花费了数个小时。
这类重写对于任意规模的应用而言都是惯常操作，没啥可惊讶的。但是，这个项目有 deadline！现在我们已经落后了。
该怎么办呢？第二天我们被要求在原有 8 小时工作时间的基础上再加 4 个小时，公司免费提供餐食，但一天 12 个小时的工作量实在是太多了。不过，我们总算赶上了进度。
一周后，app 更新上线了。但我们并没有特别兴奋，短暂的庆祝后，我们又回到了电脑前，像是无事发生。
该更新没太大的厉害之处，只不过它必须那天上线而已。甚至用户都不知道 app 更新了，也没有人依赖它。新特性确实还不错，但更新发布时间推迟一天会有什么影响吗？会伤害任何人吗？
而非按 deadline 完成项目伤害了开发者。开发者之间会互相抱怨，他们与领导之间的关系也受到影响。
而且这种情况并非偶然，而是经常发生。
那么我们从中得到什么教训呢？完全丢弃 deadline？
当然不是。deadline 本身是个好事情，但它应该是一个目标，而不是僵硬的死线。新特性发布时间比预期晚个一两天无伤大雅。产品负责人真的要为了 deadline 给开发者施加那么大压力吗？在加班状态下，代码还能保持高质量吗？
特别是加班状态下开发者的心理状态很可能是「赶紧把这个做完」。有时候开发者甚至会选择「走捷径」，工作看起来是暂时完成了，但之后还需要重构。有时候这些「捷径」会导致重写，有时候甚至会被遗忘，开发者自己都未必注意到这些捷径，因为写的时候已经太累了，只想着回家。
如果捷径还需要被重构，那么这意味着需要更多时间。此外，加班时间写的代码往往会出现bug，而在生产级应用中发现 bug 后开发者的受挫感也会增加。
我认为，加班带来的收益是短期的，看起来是赶上了 deadline，但是下一个呢？由于可能需要重写，下一个 deadline 会落后于预期。开发者的幸福感降低、挫败感增加。这还不包括那些在版本发布后可能对用户造成影响的 bug。
如何改变？
设置 deadline 的人应该把时间花在正确地做事上。他们需要倾听开发者，追踪项目进度。如果项目进度落后于 deadline，而项目本身并不紧急，推后！当然，推后不意味着无限期，而是在当下的节点上重新对项目时间进行估计。鼓励开发者注意风险和拖延，并及时告知项目负责人。如果开发者注意到某些事情落后于进度了，他们应该及时告知产品负责人，然后负责人根据具体情况调整发布日期。
如果超前完成项目呢？这当然是好事，对每个人来说都是双赢。首先，这给 QA 留出了更多的时间。其次，产品负责人还可以请开发者改进已有代码库。
deadline，想说爱你不容易
Rene Pot 这篇文章被转发到 reddit 后，引起了大量讨论。
有人引用了英国作家道格拉斯 · 亚当斯 (Douglas Adams) 的名言：「我喜爱截稿日期，我喜欢它们飞逝而过时发出的呼啸声。」
还有网友调侃道：
没有 deadline，我怎么知道什么时候开始工作呢？
没有 deadline，你怎么知道什么时候可以停止工作呢？
但评论区更多的是对随意设置 deadline 的吐槽，甚至出现了「摸鱼指南」：
我一般会无视 sprint（冲刺）计划，很多任务一周时间完全不够用。而且截至目前，我并未被辞退。
sprint 计划其实是：要求你在 deadline 之前完成任务，这样当你没有完成后就会因为愧疚而加班。解决办法就是，把 deadline 丢回给制定它的人。
作为开发者，你认为什么样的 deadline 是合理的，什么样的 deadline 带来了伤害。请留言告诉我们。
参考链接：
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。