其实， 他这才是评估工作量的正确姿势。

评估工作量尽量给自己留一些buffer。你不能保证在此期间不被其它工作频繁打断（现在互联网公司里， 一人同时跟进好几个项目很常见），你也不能保证这项工作不会跟其它需求的排期因为意外而冲突，你也不能保证你的修改不会引入新的意想不到的bug，所以，评估排期一定要有buffer。

改线上的问题不是说你修改两行代码，迅速的git commit & push，然后就直接线上发布了。完整的流程一般是

1.先设计好修改方案

2.跟QA以及相关同学同步/评审下方案

3.方案实现（开发、反复debug、反复自测）

4.提测，测试反馈问题给开发进行fix。

开发反复重复3、4两步， 直到测试验收通过。

正规的一般有日常（测试）、预发布、线上环境，你的修改至少需要在日常和预发布环境提测并验收通过， 才能走线上发布线上环境，一切以稳定优先，速度其次。除非是修复紧急BUG。

诚然，是有不少开发排期有划水的成分在，我工作中也遇到过不少。但我觉得改个线上问题，需要2天时间，还算正常。评估工作还是不要压的太紧，也降低一下大家对交付的预期。否则，你会把自己搞的很累，一旦有意外情况发生，你就会经常各种delay，久而久之，反而给别人不靠谱的印象