前言
近期项目由于时程规划偏差的问题因此对于「时程规划」这个主题挺感兴趣的，也想看看不同的工程师对于这个问题的看法，主要参考：The work is never just “the work” - Dave Stewart 文章。
发现身为初阶打工人其实通常只是看见问题并拼命解决它，但换个角度思考：“如果现在手上项目烧起来，主管定个超乎预期的时程但你也没有自己一套说法，要如何交代？”所以这是为什么我想研究这个主题的原因，最贴近实作的人其实是最能开出真实预估的人。
大家都希望项目能够又快又准时的完成，且当出事了我会希望能够分析出因果以及改善的方向。
为什么项目时间预估这么难？
你从来没有真实体验过相同的经历，你认为自己体验过，但没有。任何事物都会改变，同事、公司、客户、工具……你自己，不是已经改变就是在改变的路上……
这篇 Hacker News 來源 引起了我的兴趣，其中提到一些有趣的讨论：
我以前有个老板，总是选那些自信过头、不可靠、出价低的人。他完全不会用天或周来估算时间。对他来说，所有事情都是「一小时」到「一个下午」就能搞定。
所以当我说「完成整个流程需要两周时间」时，
那个人会说「我下午就能搞定」。但他交出来的代码根本跑不通，然后需要我、QA 和他一起花三周的时间来修修补补，才能真正正常运行。
结果是，原本需要两个人周的工作量，最终变成了大约 5 到 6 个人周的工作量。
问题还是在于无法预测需要做什么以及需要多长时间去完成，或许单纯多一点相似的经历有帮助？或许一些建议像是「预留 30% 给项目管理」、「添加预估时间的 n 倍时间」有帮助？但这些方式都只是仰赖大致的经验，而唯一准确的预估只会存在于制作完成的当下。
估算失败了，然后呢？
估算是失败的，但可以通过失败经验来分析学习，大多失败的估算不外乎有两个要点：
- 许多工作是「为了完成工作而做的工作」，而不是「实际的工作」
- 大部分工作因为不是「实际的工作」，所以被低估或未估计
我们喜欢估算事情如果在专业的执行下会有多顺利，而不是关心捉摸不定的变数，这也牵扯到自尊与压力等问题，所以与其盲目相信直觉上事情会多顺利，或许能够建立一套框架流程，用于将工作与其连带的附加工作也纳入评估当中。
评估框架
所有项目都有不变的特点，就是进行前、进行中、进行后这三种类别的工作，具体可以依照一个更详细的框架做细分：
- ⚫ 围绕在项目的工作（行政）：开会、评论、项目管理
- 🔴 为了得到项目而做的工作（获取）：研究、实验、定义边界、报价、说服
- 🟠 项目之前的工作（准备）：设置、基础建设
- 🟡 项目本身（执行）：实际产品设计、开发、测试
- 🟢 项目之间的工作（迭代）：迭代除错、重构
- 🔵 项目延伸的工作（改变）：遗漏、新变动、可额外添加事项
- 🟣 案之外的工作（问题）：意外事件、延伸任务
- 🟤 项目之后的工作（支援）：部署、安全问题、更新
事先将项目各方面的工作切分出来有助于用更客观的角度评估时程。悲伤的是每个项目的性质都不同，并没有一套适应任何问题的框架可以套用，但这样的框架可以帮助我们更好的留意项目的潜在复杂性。
总结
- 替结束的项目进行评估，将期望拉回现实
- 留意绝大多数项目都存在隐性工作
- 出事时与其持续埋头苦干，思考改进估计偏差和弱点
- 留意固定代价的项目
由于执行因素持续变动是不可改变的因素，因此关于这个议题我的想法是不需要太过于执着于估算的准确性，而是要学会如何在估算失败时快速调整，对工作的全貌有所认识。