我问的是较小的工作：我认为对于较大的工作，您需要处理各种合同问题。对于较大的工作，如果您还没有考虑到进度延误，那么您基本上已经被淹没了。
较小的可交付成果（10 小时或更少）：如果您正在做一些您以前做过的事情，很容易估计这项工作需要的时间（而且可能需要的时间更少，因为您已经学会了如何去做“最好的”）。但是对于新事物，您如何处理初始估计中可能出现的时间延误？随意加20%的时间，以防万一？给出一个范围，然后在前进时给出更高的精度？做一些 HelloWorlds 计费几个小时并尝试找出未知数？
对于这个问题，我假设您为一个灵活的客户工作，他们需要尽可能多的信息来完成他们的工作，并且迟早需要一切。
在任何新的和不同的事物开始时，任何精确到优于 +/- 50% 的估计要么被填充，要么是猜测，要么具有很好的灵活范围。
也就是说，优先级和时间表通常是灵活的，并且取决于开发团队或客户以外的许多事情。
重要的是有明显的进步，对客户需求的响应能力（与请求相反- 一个灵活的客户会看到差异），以及一种迭代方法，如果必要的话，你可以使用不到 100% 的功能提前上线（它在第 1 天不需要全部），前提是修复和功能发布是频繁的，并提供切实的额外好处。
让客户摆脱“完成，在日期 X 准备好”的心态，进入“足够的，一直在改进”的心态，这是关键。
否则，你必须回到久负盛名的传统……你问四位值得信赖、经验丰富、可靠的同事的估计……
...然后将它们加在一起。
学习需要反馈，所以我建议跟踪你自己的准确性。
保留一个日志，其中包含每个估计任务、原始估计和实际所需时间的简要描述。因此，例如，如果您发现您的估计值少了 25%，请开始进行相应的向上调整。如果您发现没有高估或低估的模式，请查看任务本身的特征，看看您是否始终高估或低估某些类型的任务。
这是一个有点开放的问题，所以答案可能也是如此。
尝试提供尽可能接近所要求的内容，尽最大努力使其运行而不会出现明显的错误（例如，崩溃）。永远不要试图猜测要求，如果没有要求，即使你知道它是必要的，也不要这样做 - 当你需要更多时间来“正确”时，这会给你带来影响 - 这不一定被问到了什么，但你的客户在你交付后真正想要什么。如果你能早点，就这样做，但不要超过 10%——否则你会被认为是无法估计的人。