您是否应该承诺提供不确定是否可实现的功能？

在HN的一篇文章中，我遇到了以下建议：

即使不确定，也请始终对客户/用户说“是”。90％的时间，您会找到一种方法。10％的时间，您会回去道歉。以小价钱支付个人的主要成长

但是我一直认为，在对客户/用户做出任何形式的承诺之前，应该先进行可行性分析，以使它们在任何时候都不会被误导。那么，在什么情况下上述建议应适用？

这是该文章短时间内引发的第二个问题。

• 好的程序员：我优化代码。更好的程序员：我构造数据。最佳程序员：有什么区别？
  这个还有另一个名字：过早的优化。

• 切勿使用早期出口。
  这就是“单入口点/单出口点”规则。这是解决实际问题的补丁，那就是提早离开可能会造成混乱。正确的规则是“清理混乱”。更好的规则是使用可自行清理的数据构造，以便程序员不必担心清理其混乱情况。

• 现在，即使您不确定，也要始终对您的客户/用户说“是”。90％的时间，您会找到一种方法。
  这也是非常糟糕的建议。

有时需要告知您的客户不，或者“您要在哪个千年中做到这一点？” 不要承诺会破坏您的架构，成本远远超过客户愿意花费的东西，或者您不知道如何实现它。您知道技术，而不是客户。如果您不知道该怎么做，请不要说您可以做到。如果不确定，请说您需要时间研究是否可行。老实说最好，这样可以避免麻烦。

如果您无法兑现承诺，那么客户很快就会成为前客户。10％的故障率听起来可能很小，但是您的客户将专注于10％的故障率。有时，他们在您无法兑现承诺时提起诉讼。你真的不想要那个。在其他时候，确保您履行诺言会使您破产，精神错乱或失去配偶，因为您每天工作18小时。您也不想要那个。

这样想：如果90％的飞机着陆成功，您会对航空业产生什么看法？您是否认为回头道歉并为崩溃的10％道歉能够解决问题？

最好说“我认为可以做到”。或“我会检查并与您联系”。我曾经有几次我拒绝或反对提出建议。如果客户希望“基于浏览器的应用程序能够正常工作，而无需连接到Internet并使用触觉反馈”，则可能是可行的。但这很昂贵，讨论实际需求是有用的。

如果您诚实，客户将尊重您。在问题的建议中，人有10％的时间是错误的。如果我与经常犯错的人（十分之一）一起工作，我将完全不信任他（她）。那是一个糟糕的记录。

承诺月球和运送石头是一种推销员的方法，不应容忍。如果您不知道是否可行，请进行研究。或者，请给他们提供您需要花费的调查时间的报价。这样，您就不会承诺无法交付的任何东西，但是您会花大量的时间调查它。

这个问题已经被正式研究，并由联合出版的IEEE计算机协会/ ACM道德规范解决。

2.01。在他们的能力范围内提供服务，对他们的经验和教育的任何局限要诚实坦率。

3.04。通过适当的教育和培训以及经验的结合，确保他们有资格从事任何工作或提议从事的项目。

3.09。确保对他们从事或提议从事的任何项目的成本，进度，人员，质量和成果进行现实的定量估计，并对这些估计提供不确定性评估。

5.05。确保对他们从事或提议从事的任何项目的成本，进度，人员，质量和成果进行现实的定量估计，并对这些估计提供不确定性评估。

承诺无法交付的东西肯定会带来商业和法律影响。通常这些来自其他地方的客户，拒绝付款或起诉您的公司。如果您与他人合作，如果您的零件没有交付，他们可能会要求赔偿。诉讼甚至可以来自竞争对手。

关于超级计算机的早期故事，西摩·克雷（Seymour Cray）和Control Data Corporation的团队即将推出产品，而另一家超大型计算机公司告诉其客户，该产品也即将推出。谎言使CDC付出了很多生意，并演变成诉讼，大公司无法提供任何可信的证据证明其要求。结果就是当时的巨额和解金，价值1970年为8000万美元（按通货膨胀调整后，2012年约为2.23亿美元）。你可以在这里读到它：

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

只要有足够的时间，资源和灵活性来定义成功，一切皆有可能。如果您只希望获得优于50％的准确度，并且拥有用户的地理位置和少量统计数据，则白色x-mass示例很容易。

在大多数项目中，真正的首要问题不是是否有可能，而是在一定条件下是否合理。

该功能是否增加了足够的价值以保证尝试的费用？

即使这个想法很棒，如果需要很长的开发周期或购买一些更奇特的硬件，在大多数情况下，让客户更好地了解这一点，然后将对话引导回更合理的目标会更好。

如果有人疯狂地给您一张空白的支票而没有最后期限，则一定要告诉他们一切皆有可能，只是让他们知道您必须发明和分发在实现目标过程中涉及的几种技术。

另一方面，当与具有合理资源的合理客户打交道时，有时候没有什么比告诉客户必须同意的某些功能更糟糕的事情了，因为他们可能已经流失并花费了时间/金钱/资源来促进或记录下来，那可能是10％的事情使该项目最初成为绿色。陷入这种情况，您就失去了客户，并且很可能在整个市场中获得了非常口头的坏参考。

扮演恶魔的拥护者

具有分析心态的技术人员可以倾向于认为，他们的表现主要是根据已完成请求与已提交请求的记分卡来进行判断的，但实际上，情况并非如此。

在开发甚至开始之前，客户就开始根据其信心水平和承诺意愿对团队绩效形成意见。

造成这种情况的部分原因是，客户可能很难评估承包商的犹豫是否是由于请求的绝对困难或承包商的能力不足所致。

由于没有绝对标准可以衡量请求的难度，因此对客户而言更重要的是，通常要相信承包商在付出100％的努力，而不是满足90％或100％的请求。

假设客户必须在以下两种情况之间进行选择：

承包商A：

• 有信心他们可以满足所有要求
• 结果：交付的请求中有90％
• 客户很高兴承包商付出了100％的努力
• 客户认为未完成的请求是由于不可预见的问题造成的，可能是承包商无法控制的

承包商B：

• 致力于兑现90％的要求。不确定他们能否兑现剩余的10％
• 结果：交付的请求中有90％
• 令客户感到失望的是，承包商没有尝试完成其他10％的要求
• 客户认为未完成的请求的10％是由于承包商的努力或能力不足

在这两种情况下，都传递了相同数量的请求。但是，客户认为“超额使用”的承包商A付出了100％的努力，并以此来验证剩余的请求确实很困难，这要归承包商A所称。

另一方面，客户感到承包商B没有付出100％的努力，并且由于承包商B缺乏努力或能力而无法完成所有请求。

免责声明：我不是在提倡过度投入作为策略。这只是对现实世界中可能的过度承诺可能产生积极结果的一种观察。

您应该告诉他们给您时间来创建“峰值解决方案”。

尖峰解决方案是一个小的程序，在编码时，它使您能够弄清楚该怎么做，甚至根本不可能，这会在项目中造成不确定性。

例如，假设您从未以编程方式发送SMS，但是您知道有可能。一个棘手的解决方案是制作一个发送SMS的小程序。这样，它不再是不确定性，您可以进一步评估可行性。

这是eXtreme编程文档说明的内容：

创建尖峰解决方案以找出解决棘手的技术或设计问题的答案。峰值解决方案是一个非常简单的程序，用于探索潜在的解决方案。建立峰值只是解决所检查的问题，而忽略所有其他问题。大多数峰值不足以保持，因此请扔掉它。目的是减少技术问题的风险或提高用户故事估计的可靠性。当技术难题威胁到阻碍系统的开发时，请一对开发人员解决该问题一两个星期，并降低潜在的风险。

根据我的经验，当用户请求某项内容时，您应该要求他们详细说明用户的实际需求。通常，您永远不会再听到有关该请求的信息。