如何回答“何时完成？”

我们所有人都有它，这些问题很难解决，很难通过模糊的代码和奇怪的意外功能来解决。缓慢地，逻辑地尝试查找模式，错误和错误。此过程需要时间，并且客户通常不容易理解问题。

当被问到“何时完成？”这一问题时，如何回答，特别是当客户可能不了解软件开发的内在复杂性时？

您可以诚实地回答问题。

您告诉他们这是一个棘手的问题，解决方案并不明显，而且您不确定解决该问题需要多长时间。承诺每隔[时间范围]对其进度进行更新，以便他们知道您正在努力，当然，实际上是将更新发送给他们。

开发人员通过将其分解为较小的问题并分别解决来解决复杂的问题。

在理想的世界中，解决问题将是一个复杂的问题A，您将能够在给定的时间内将其分解为小问题A ₁至A _n的简短列表，因为每次评估的时间都是简单的解决最初的复杂问题所需的时间为：

与d被分解本身的过程。

在现实世界中，唯一的问题是t（D）实际上比您解决这些小问题所花费的时间更长。换句话说，为了达到此问题的分解水平，您实际上需要解决问题本身。

您仍然可以：

• 将给定的任务（解决问题）分成较小的块，每个块仍然是一个复杂的问题，

• 评估每个块的预期时间和相应的风险。

  例如，任务1需要大约。5小时，但这样做的风险很高，因此请给您12小时作为您对客户的期望。

• 评估依赖关系以及它们如何影响时间。

  例如，任务19需要2个小时，而风险是如此之低，您可以肯定地说是2个小时。不是1.不是3.但是任务19依赖于任务24：任务24可能会以某种方式影响任务19，您将需要使用另一种方法完全重写任务19的代码。

• 将所有这些详细信息提供给您的客户。不要给总和。

最后一点很重要。如果给出总和，比如说192个小时，客户认为这是一个非常精确的指标，那么您将花费的时间为189到195个小时。

相反，如果您提供详细信息，

• 关心的客户会明白这不是192小时。考虑到评估过程中确定的风险，如果一切出错，则是192个小时。如果一切变得更糟，那也需要238小时。如果一切正常，也需要85个小时。

• 对于不在乎的客户，他不会在所有情况下都阅读您的答案。他只想要一个数字，以后再能怪你。通过给出一个他将永远不会阅读的非常详细的答案，您知道他无法再询问您要花的时间：您已经回答了。他以后也不能怪你，因为他没有读答案来计算总和。

无论您估计什么，都不要忘记包括霍夫施塔特定律：即使考虑到霍夫施塔特定律，它的花费也总是比您预期的长。

通常，我使用CPM / PERT中的修改公式。就像这样：

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

（我不确定如何进行所有奇特的数学格式化；如果有人要对此进行编辑，请放心。）

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

我要强调的是，根据项目的进行情况，它可能会有很大的不同。如果您每隔几天重新评估项目，甚至可以提供每周更新。满足烦躁的客户有很长的路要走。:)

向非技术用户解释模糊的时间表非常困难。在项目的创作阶段和跟踪讨厌的错误时都是如此。在这两种情况下，传统的“将工作分解为较小的部分”都无法正常工作。

最初的任务侧重于后一种情况，因此让我们对其进行详细说明。如果您无法提供时间表，请告诉用户您将尝试什么以及何时回到他们那里。当您达到自己设定的时间表的中途时，请提供简短而诚实的电子邮件更新。在截止日期前至少一个小时给出您的正式答复。现在您有了信誉。如果问题仍未解决，至少您可以发光。看起来似乎是在浪费时间，但事实并非如此。

由于您无法解释未知的障碍和无法预料的意外，因此自信地进行估计可能会很困难。想法：

• 尝试一个范围-“我确定至少需要N天（例如3天），但最多可能需要4N。”
• 在估算和维护估算中寻求更多高级工程师的支持。
• 以较短的迭代（敏捷/ Scrum风格）工作，以产生最少的代码来增加业务价值（获得信心和信任），然后重复执行。
• 从经典的入门指南（http://www.amazon.com/gp/aw/d/0143118757）等书中学习谈判技巧。

对于新开发，尤其是敏捷开发：

“达到完美，不是在没有其他可添加的东西时，而是在没有其他东西可取的时候。” -圣安东尼（Antoine de Saint-Exuper）

如果您要估算在一个极其丑陋，过于复杂的系统中修复几乎几乎无法重现错误的精力和时间，而很少或几乎没有开发人员拥有该系统的领域知识，那么唯一正确的答案是“何时修复”。

通常，我只会告诉他们真相。我会告诉他们我现在不知道，一周后我也许会有更好的见解。然后，我会给他们一个棒球场，前面有尽可能多的花鼓，可以容纳在纸上，以表明这是基于直觉的猜测。如果他们开始硬着头皮，只要在每个句子的开头都加上“可能……”，通常我愿意为之做的任何人都会对“一周左右回来，但现在我只能说大约2个月”感到满意。或类似的东西。

个人软件过程（PSP）专注于改进估计。这是通过对任务进行有纪律的记录来实现的。从本质上讲，这将“加速”估算的“经验”部分，因为您将获得有关典型任务的实际数据。当然，该行业仍然需要针对许多问题的独特解决方案，但以我的经验，使用PSP后的估计会更好。