layout: post title: "如何估算项目时间" date: 2024-10-20 15:54 comments: true
最近下前段时间和老板 1:1 的总结，重点是如何正确的估计时间。
<!--more-->SDE 总是要经常估计项目需要多少时间的，这个问题其实很难，原因不复杂，如果这个项目是一个常规的项目，那么大多数时候，计算机的行业经验是把这个任务做成一个服务，然后发布出去。剩下的任务就是按部就班地按照文档操作，调用就行。这种时间估计一般是很靠谱的。
但是如果让你去做一个时间预估，那么这个时候，很大概率是涉及到不少的未知元素，所以大家不知道。那么你的预估其实就是基于你自己的经验去给一个大概的估计，这个准或者不准其实很大概率取决于你的经验和实际的项目难度。
举个例子，你认为数据已经在上游 team 那里准备好了，所以你估计了剩下的 ETL 的时间，但是你真的去做发现，上游 team 并没有把你需要的数据准备好，这个时候就需要和上游 team 沟通，cut ticket 或者开 Sync meetings，这个往往就时间无法控制了。但是你不真正去做这个项目很多时候又很难发现数据又问题。
那么是不是就没有方法去解决了呢？
也不是就没有方法，下面总结下我的一些看法。
你大概心中会有一个时间估计，但是不要直接给出具体的时间。因为往往你给出时间，大家就会认为这个时间是可靠的，即使你强调只是估计。很多时候你给具体时间，大家就会按照着这个时间来评价你的工作，这样你就必须 meet the deadline。但是很多时候很多东西是你无法掌控的，所以永远不要给出具体的时间。
你需要给出这个项目的具体 steps，然后对于每个 step 给出时间 range 的估计。这个 range 有一个比较方便的方法就是， time by 2 and plus 1，如果你觉得这个 step 需要 1 天，你就给 2 ～ 3 天。这样如果你提前完成，大家会非常喜欢和你合作。
很多时候如果你来不及给出 list 或者不清楚，你就说你需要时间来研究并且列出 steps 并且给出估计，然后说 later today or after this meeting，I will send the estimate doc to you 等等。
因为你列出了一系列的步骤，所以你后面也会比较方便找出你的问题，比如按照计划我今天需要拿到上游数据，但是没有，你就可以考虑是不是找对面的 on-call 或者 升级到找对方的上级来解决。
如果出现了很多重大的问题，或者你的 time line 拖的久了，不要自己干着急或者只是抓紧干活，及时 call out 并且找别人帮助。同时有时候这个问题你没办法解决，那就及时 reset time line。