简单记录一下工作中的感受（具体事件不展开了）。
关于评估工作量
今天与不同角色的人一起评估处于非常早期的产品构想的实施成本，深切感受到了邓宁-克鲁格效应，简单说就是：人们会低估自己不熟悉的领域的难度。产品经理无法感性地评判一件事情技术实现难度有多大，有多少能复用，有多快能上线；前端同学也无法用自己的经验感性地评判客户端实现一个页面、一个动效需要多大的开发量；一线的同学也无法用自己的片面理解感性地评判 leader 应该如何做决策、如何分配精力等等。
关于时间预期
侯世达定律：做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。
侯世达在讲递归的时候，给了这么一个递归形式的定律，非常有意思（未来可以考虑整理一些《GEB》的读书笔记）。我在读书时，老师也常常会灌输一个理论，软件工程中，delay 是常态，因为我们评估过于乐观，有太多的风险和问题在前期被忽视了。而另一个极端是如果一件事 deadline 是在很未来的地方，我们还是投入这么多人力进来，我们也未必会提前完成这件事，而是或者降低它的优先级，或者我们把这件事变得无比复杂，总之这段时间不会有人闲着，最后在临近 deadline 的时候，或许依然有严重的延期风险。
其实在快速迭代的当下，对于研发同学评估一个具体需求的工时，已经可以比较准确了，但面对一些宏观任务时侯世达定律依然适用，比如产品的提升市场占有率、提升自然流量、培养团队成员、提升研发效率和质量等等。
进一步地，在很多事情中，时间这个维度被成本取代，要做的事情被最终收益取代，我们关注的逐渐转变成了 roi。一些进行中的事情 roi 的计算并不是稳定的，预期收益是动态变化的，投入成本是逐渐增加的，如果为了达成 roi 的目标，可能将 deadline 前移（比如倒排期）以削减成本，从而加重工时矛盾。我认为这样的事情难以避免，甚至局部会越来越严重。
关于 deadline
这边的 deadline 与上一个话题不相关，源于与一位同学聊拖延症。对于做富于创造性的工作，拖延症是非常正常的情况（当然对于缺乏创造性的机械工作，拖延症就是懒）。这种情况把 deadline 向后延是没有意义的，多延一周，就是多拖延一周而已，更应该守住 deadline，甚至通过某种监督机制，把 deadline 人为前移，以释放自己的创造力。