译者注：原文 How Product teams should set deadlines，作者 Dana Levine
几个月前我写了篇反响不错的《The Why, What, and How of the Modern Product Team》，有位读者指出我应该再谈一谈 When 的问题。这就比较棘手了，因为我觉得没有什么正确答案。
应对截止日期有两种方法。一种是自顶向下，先确定一个交付产品或发布新功能的时间节点，其他事情都按这个截止日期倒排。这种方式通常考虑的是商务层面的需求，比如已经向客户做出了承诺。
有两种方法可以应对这种无法变更的截止日期；一种是逼迫团队努力工作。一些经理相信只要把团队压榨到位，就可以在任何期限前解决问题。这听起来是个让所有人精疲力尽的好办法，但是也有一些道理 —— 设置截止期限会让人更专注。
另一个应对截止日期的方法是调整交付范围，直到确定这个时间点到来时能交付承诺的内容。一旦确定了截止日期，你就可以算出有多少时间可以用于完成工作，这可以迫使人去思考哪些功能是必要的，然后聚焦于构建一个最小功能集。
而且这种练习还可以重复多次。团队应该频繁地检视现在和未来的工作，问问自己"我在截止日期前能不能完成这些工作"。如果答案是"不能"或者"也许吧"，就应该缩减交付范围，直到这个问题的答案变成"可以"。有时候人们也会选择推迟交付日期，我们很快就会提到这方面的内容。
事实上这两种方法并不互斥。你可以一边考虑减少交付内容，一边考虑鼓励人们加把劲。我参与过的重点项目中，几乎每一个都会偏离原先的时间计划。即便一开始就估计的保守了，团队也可能接到吃不下的活，这时候就要考虑使用这两个方法了。
对应从截止日期倒排这种自顶向下的方法，还有一种自底向上方法。先估计各个模块的耗时，然后把他们加起来。听起来是很可以，但是预估工程花费是一个容易出错的过程，不仅是因为实践过程中充满了未知，还因为耗费的时间总是因人而异的。
一些经理用非常复杂的方法计算成本。如果是熟悉的团队，任务也是容易量化的，这个方法就能用。但是推广过程中就会发现各种各样的不确定因素。一个好的成本核算系统可能能够区分一个月和两个月的项目，但也就这样了。
大多数团队应对未知情况的方法就是给预估工时加一些浮动值，一般是 50% 到 100%。我通常会要求工程师乘以系数 2，比如 1 天的工作排 2 天，1 周的工作排 2 周。一位工程师告诉我她最近交付的内容实际花费时间是预估的三倍。这听起来有点走极端，却确实是一种常用的方法。
适当浮动一点时间有益项目健康，我个人倾向于每个项目都多给点。设定目标的意义不在于确定一个项目必须要在什么时候交付，而在于给出一个时间计划，让所有人乐于按这个计划实行。项目经理有很多手段可以强迫团队冲击任何目标，我并不赞成这些做法。我认为负责回答 How 的人应该有能力去搞清楚达成目标需要多长时间，而团队的其他成员应该尊重这个过程。如果这个数字太大了，他/她应该去找负责回答 What 的人，讨论哪些内容可以被削减。
最好的情况是，截止日期是由自顶向下和自底向上的方法共同决定的。一个来源于商务需求，一个来源于达成目标需要投入的资源。如果这两个相差太多，那么总是需要调整优先级或者功能集的。毕竟一个达成不了的截止日期是毫无意义的。