意外的复杂度
当你开始一个新项目时，你通常不会马上就很清楚整个项目应该怎么完成。尽管你是一名专业人士，你以前也做过类似的工作，所以你会试图搞定这个项目。
但现实情况中，你会发现有各种各样的因素会跳出来，比如：
- 你需要使用某些新框架或新的库去实现某种功能
- 尝试使用的 A 库可能会和 B 库产生冲突
- 你正在集成的 API 不起作用
- 单元测试和集成测试报错
- 还有很多……
工作量预估偏差
PM：“你能不能给我一个开发某某功能所需要的预估时间？”
程序员：“一个月”
PM：“一个月时间太长了，我们只有一周时间！”
程序员：“最好三周”
PM：“我只能最多给你两周时间”
程序员：“好吧，成交！”
其实你还是没有底气的，工作量估算基本靠经验，最好给自己留点余地。
复杂度累积
接手的项目越多，复杂度累积得就会更大。就算不会严重延期，也很难按时交付的。
我们用数学来看，假设你有 5% 的几率遇到意外的复杂度，而你的新项目是分为 10 个项目的，那么可得：
1 - (1 - 0.05) ^ 10 = 0.40
也就是说，在这个项目中，你有 40% 的几率造成延期。
感兴趣可以继续阅读：Why are projects always behind schedule?
创造性与机械任务
在「Software has diseconomies of scale」这篇文章中，有一个关于生产率差异的有趣论据。对于创造性任务，每个人都需要花费更多的时间，而机械任务则相反，它们通常能够在一定程度上实现自动化。
这句话的意思实际上就是，我们很难对创造性任务的时间进行准确地估计，甚至某些情况下没有过往的经验能够指导你。
