当为一家主要不是编程公司的公司开始一个项目时，人们的期望之一是最后会有一个成品，其中没有任何错误，并且可以立即完成所需的一切。但是，这种情况很少发生。
有什么方法可以管理期望并向非程序员说明软件开发与其他类型的产品开发有何不同？
Answers:
我发现成功的一种方法是：
我们都知道，一台计算机只能准确地执行其操作。
编程是我们现在告诉计算机以后要做什么的方式。
这意味着您的行为现在的行为方式是由于编写了计算机上正在运行的任何代码的每个人的共同意图。考虑到操作系统，驱动程序，编程环境，库等的复杂性，不难发现，在大多数系统中，涉及的人员必须超过2万，而涉及的人员可能超过10万。
每个人编写的代码反映了他们自己的理解，动机，意图和能力。鉴于该系统的正确的操作要求，所有这些20K人写的代码没有错误互动-即所有的代码必须在内涵和要求的行为的解释达成一致，suprising事实是不是因为我们的错误，但我们很少。
IMO，我发现敏捷过程（例如Scrum，Crystal等）提供的透明度在向普通利益相关者展示开发方式方面大有帮助。
用隐喻来解释是一个漏接的抽象，但是这里有一些对我有用的想法：
请注意，所有这些解释都不能作为草率工作的借口。
可以将计算机程序视为机器，其中每个变量都是运动部分。这甚至使琐碎的程序也变成了由数百个运动部件组成的机器。
当这种方法失败时，我会回到一个事实，即虽然可以从数学上证明程序没有错误，但是这会花费大量时间，因此不值得付出努力。
最后，我问英特尔和微软是否无法避免错误，他们对我们的期望如何？
传统的说法是项目管理三角：范围，成本和进度这三个相互竞争的标准；通常表示为“便宜，快速，良好-选择两个”。
在结束一家集设计，开发和部署过程中，一个产品的期望是相对自由的设计缺陷和运行与指定的功能是完全合理的。对于项目，过程或专业，相同的期望是完全不合理的。
那些基于科学的硬性或软性专业人士不会经历探索，形成不准确和不精确的概念化过程，遵循非最佳（或纯属错误）策略，通过反复试验发现有效的方法并重复进行一遍又一遍地处理，直到资源用完或性能达到足够的水平？
尽管过程可以渐近地达到更高的质量水平，但是没有任何过程没有缺陷。
对于医疗行业来说确实如此，因为战术经常涉及猜测和协议，而且大部分活动基本上都是在调试大多数为湿器的机器。对于土木工程和建筑业来说，确实必须对新工程材料的应用进行现场验证，尽管严格遵守标准，但经过多年的服务后，它可能突然失效。对于汽车领域而言，确实如此，因为老化和操作条件的变化通常会通过所应用的工程或维修服务无故障而影响性能直至故障点。在这些方面，软件开发与这些专业在本质上并没有什么不同，它的重点只是设计新颖的，有目的的机器。
您可以将其与他们可以看到的东西进行比较，如果可能，请每天使用。
例如，汽车。汽车起步时要比我们今天使用的精致和可靠的设备少得多。尽管汽车制造已有100多年的历史，但软件的使用寿命可能只有其一半左右。可提供具有重大定制功能的汽车，其中一些包括在价格中（例如颜色选择），其他一些包括引擎尺寸，变速箱类型，车轮/轮胎，内饰水平是重要的成本驱动因素。
汽车和软件有许多功能，质量和成本驱动因素。然后，您可以讨论软件技术，专业知识的可用性，甚至可能是在何处构建的，都将产生很大的变化。适当的开发周期（例如，每年更改很小的模型，大约每三年更改一次车身/引擎/平台）是由客户需求和复杂的设计过程共同驱动的。有些产品看上去小巧而笨拙（例如本田雅阁（Honda Accord）），但每年都会得到改进，直到获得最高评价为止。
汽车具有召回（通常比软件升级贵得多）并且通过对零件清单进行更改（例如修正错误）来进行逐步改进，并且经常需要长期支持（例如向后/向前兼容）。汽车的大部分成本是在您开车回家之后产生的。在您更新和升级客户时，大部分软件成本来自初始产品发布之后。
在某些情况下，您可以引用包括软件或其他软件产品的知名产品。例如，电话在首次销售后就有发布周期，更新和添加功能的方法，以增加收入。电话很好地说明了向前/向后兼容性。太多了，人们不会抛弃旧的去买新的。太少了，客户迫切希望拥有一部在合同到期之前就不会讨厌的电话。
Windows，Microsoft Office，Web浏览器和网页等产品都是可以在讨论中使用的软件。它们已按年度或三年周期进行更新，但可能会更频繁地进行自动更新。它们具有漏洞和安全漏洞，这些漏洞和安全漏洞会在不同程度上影响客户，但尽管我们已尽力而为，但它们仍是其中的一部分。客户可以免费获得修复程序，但通常会以捆绑形式（有时是单独模块或通过许可证密钥）来支付增强功能。
微软，苹果，谷歌和亚马逊等行业领导者都为用户提供了相对便宜的客户。但是他们有巨大的费用使那些产品成为可能。他们的经验表明，软件价格昂贵，但有价值且有利可图。他们经常在质量，拥有所需的所有功能以及在适当时机进入市场之间做出折衷。并非他们生产的每种产品都是成功的，有时他们会通过重命名，改善营销和销售，或减少损失并利用他们在后来的产品中获得的知识，将狗变成赢家。
也许尝试以一对一的方式或以小组的形式逐步浏览它们，这些是您必须开发的软件用例。当他们描述用例时，请确定可能发生不同情况的情况下的要点（意料之外但并非不合理的情况）。开始列举它们，要求一些澄清，并说明需要做出或确定的所有决定和方向，以及这样做时的权衡。一直走下去，直到它们被绊住，无法给您答案。让他们了解，您现在与他们一起正在做的事情，就是您整天要做的事情，可能是您自己做的，可能是方向不明确的，无论是决定课程还是编写代码，都要花费数百或数千个任何人可能会或可能不会布置的用例。当有 如果您没有想到自己，就不能保证程序会做什么。也许它做“正确”的事情，也许要注意。这就是一个错误。这就是为什么编写软件需要时间。您所花费的时间越少，您考虑和适应的案例就越少，在未知情况下该程序更有可能无法执行“正确”的事情。
成本和时间。
时间
设定期望在Y的时间内交付X。它将仅此而已。然后告诉他们下一个版本在什么时间会有什么。最初，他们可能会惊讶地认为构建X会花费Y的时间-在这里您可以解释花费的时间和构建软件的复杂性。如果他们不感到惊讶，那么您要么会花费更少的时间，要么他们会比您想像的更了解构建软件。
成本
这是史蒂夫·麦康奈尔（Steve McConnel）的《代码竞争》（Code Compete）书中的内容（引用内存，因此，如果我不能以相同的效果传达它，请原谅）-客户很容易要求新功能。作为产品经理，您不应说出客户的要求。您应该估算构建该新功能所需的工作量和成本。他们会慢慢理解，新功能确实不值得花时间/金钱，或者甚至根本不需要。我不建议您使用此武器吓e他们，但请诚实地使用它，这可能有助于将重点推向目标。