为什么计时软件总要你先猜一件事要花多久?

打开一款计时软件,它通常不会先问你在做什么,而是先问一个数字:这件事预计要多久?这次记到哪个预算里?你打算对着哪个目标时长记账?事情本身还一秒都没发生,你已经被要求预测它了。

那个数字是为了跟另一个数字比对

秒表单独跑出来的一段时长,其实没多大用处——四十分钟这个数字,得先知道它算快、算慢还是刚刚好,才有意义。提前要的那个预估,就是为了给后面这个数字找个可以比对的对象:预计和实际,预算和实报,计划和真实发生的。很多时间追踪的价值恰恰就在这个"比对"上,而要比对,系统就得在钟表启动之前先存一个预测,不然实际数字出来了也没有东西能拿来对照。

对某些场景来说,这套逻辑完全合理。工作室按固定报价接一个项目,得知道当初的估价站不站得住;团队排下一个冲刺,想看看上次的预估偏差在哪,好让这次估得准一点。这些情况下,提前要的那个数字不是多余的手续,它就是整件事要测量的核心。

问题是,大多数事情根本不愿意被老实估算

你通常是在还没弄清楚这件事究竟是什么样子的时候,就被要求给出那个数字。一封"很快就能回完"的邮件,后来变成三轮往返加一通电话。一件"一小时能搞定"的杂事,撞上一个谁也没法提前算进去的排队。写报告的某一段,在思路清楚的那天十分钟就写完,在脑子发木的那天要磨上九十分钟。预估之所以不准,不是因为你不擅长估算,而是因为一件事真正的样子,往往要等你真正进去做了才看得清楚,而按定义,那个数字偏偏要在这一切发生之前就交出来。

提前认下的数字,会悄悄开始指挥这件事该怎么做

一个时长一旦被写下来,它就不再只是个猜测,而开始变成一个必须够到的目标。一件被估成三十分钟的事,哪怕那天它注定不可能三十分钟做完,也会被硬掰成三十分钟的样子——要么砍掉一些本该有的步骤去凑那个数,要么下次干脆把预估往上抬一点,好让自己更容易达标。不管往哪个方向走,这件事的做法,某种程度上都开始围着一个在信息还不够充分时就仓促定下的数字打转。没有人是故意在钻空子,只是一个提前认下的数字,一旦存在了,就很难当它不存在。

日志从来不用在故事开始之前先知道结局

这些困扰,日志一个都碰不到,因为日志从来不要求你先开口。你不会在写下一条记录之前,先去预测这段时间里会发生什么——你是等事情真的发生过、你也确实知道它是什么样子之后,才把它写下来。没有需要担心猜错的预估,写下来的那一刻也没有什么需要维护的数字,因为写作这个动作本身,永远只往回看。"这个下午都用来改报告了,比想的慢,因为第二段来回重写了好几次"这样一句话,不是一次失败的预估,它只是如实发生过的事,被记下来一次,前面不需要任何一个必须先猜对的数字撑着。

关于 TimeMap

TimeMap不会在你能写下一件事之前,先问你这件事打算花多久。它没有预估这一栏,后面也没有什么数字需要拿它去核对——你只是在一件事变成事实之后,把当时在做什么写下来,这就是一整条记录。

这是记录这种方式一贯的取舍:你放弃了拿计划时长和实际时长互相比对的能力,换来的是,永远不用在一件事刚开头的时候,先去猜一个当时其实根本猜不准的数字。