试图做出技术决策的业务

我们经常在业务会向客户承诺一项新功能的场景中运行。企业将保证以特定方式实现该功能。企业承诺的这些技术细节通常很差。不幸的是，现在已经设置了客户端，并希望以业务描述的方式实现此功能。

最后，企业只希望在不考虑质量和可维护性的情况下完成此功能。有什么好方法可以后退吗？我们如何向企业解释在收集需求之前提供技术详细信息是一个坏主意？

那是组织上的问题。如果高层不了解这一点，那么您将无能为力。尝试向非技术老板解释这个问题，但是当您无所适从时，请不要感到惊讶。

对于无论出于何种原因而销售软件的非开发公司中的开发人员来说，这都是一个普遍问题。

这不是一个令人愉快的策略，但您可以凭证据大胆地批评他们。在项目开始时，准确写下失败原因（由于技术细节不完善），然后通过电子邮件发送给相关人员。在整个过程中继续向他们发送电子邮件，直到项目最终因惹恼了客户而陷入灾难时，请引用您在每一次机会中发送的电子邮件。它可能会产生一些恶意，但实际上并没有解决这种系统性问题的好方法。

从开发人员的角度来看，这是编写规范时失败的两种方式之一。可能发生的另一件事是，销售人员做出了很大的承诺，然后求助于IT部门来指定项目并交付可以转化为报价的内容。

问题是，通常这是大部分工作。实际代码很可能只是实现精心设计的规范中列出的方法的详细信息。

同时，销售人员发现很难为规范开发等预付费用。我们还没有和客户一起卧床休息，所以奇怪的是要他们赔钱以弄清要赔多少钱。

这就是为什么大多数与新客户一起进行的“首次”项目最终都是亏损领导者。如果您很幸运，则可以使用第一个项目来培训客户如何成为客户，然后您就可以从第二个项目或第一个项目的维护协议中赚回一笔。