如何说服非技术客户他们的应用规范需要简化？

通常，我遇到的情况是，新客户使用的应用程序实际上具有数百个不必要的功能，很显然，要使项目有成功的机会，就必须彻底简化事情。您如何说服客户采取更可行的最低可行产品（MVP）方法并进行简化？

编辑：

因此，当前的最佳答案是为客户提供庞大应用程序的时间/成本估算。我不太喜欢这个答案，因为它不能解决这种情况下的真正问题。那就是-选择一个大型应用程序然后尝试从头开始构建它是一个不好的做法。最初建立一个小型，简单的MVP基础时，我感到更加自在。然后在基础上逐个添加一些小功能。那么，如何说服客户以这种方式开发软件呢？

通过估算花费多少钱/时间来完成高质量的数百个功能。很少有客户会把钱放在他们的嘴上。

两个词：用户故事。

我了解到，帮助客户获得Aclue®的最快方法是让他们通过用户故事与我交谈，了解他们想要的每个功能或页面。发生了几件事，包括：

1. 他们必须考虑页面/功能实际上应该做什么。
2. 当您要求越来越多的细节时（“然后呢？…… 然后呢？ ……”），他们开始理解，让Magic Space Monkeys™飞入并完成整个事情并不会成真。在周末。
3. 他们成为创作过程中的真正合作伙伴。这意味着他们将理解为什么对已经完成80％的事情改变主意会导致a）进度延迟，以及b）成本增加。

说真的 所有者的用户故事 是我所知的最好的工具之一，至少可以使流程保持一定的理智。

在讨论成本和生产时间方面时，要求对要求进行排序（“必须具备”，“应该具备”和“很高兴拥有”），以使最基本的可行产品集成为必需在版本1中，“必须具备”，然后将其余需求放入待办事项中，这些积压工作可以在第一个版本之后以sprint的形式完成。希望那些非必要的“不错的”选项将排在后面，等到您冲刺时，更重要的新选项（根据产品的实际经验）将浮到顶部。

客户应该意识到，您正在考虑他们的业务成本以及快速获取产品的重要性，并且您不会直接将他们的积压的积淀视为他们的“好东西”。

编辑以响应OP编辑：为了说服客户，为什么尽早发布最低可行的产品是个好主意，请解释说，直到该产品被实际用户使用为止，很难知道它是否会成功（尤其是在可用性方面）。如果客户不愿向其整个用户群推出早期产品，建议进行“有限beta”测试，该产品仅适用于其目标客户群。告诉他们这种方法的另一面是一个漫长的，昂贵的开发周期，但后来又确定该产品不可用。37 Signals对此提供了一些很好的参考：入门和返工。“ Getting Real”可以在网上免费获得。

您对情况感到沮丧的主要原因可能是客户使用的感知和误导/错误术语之一。客户通常不会向您提供需求清单，而是他们可能想到的每件事的愿望清单可能对他们有用。这些并不是全部要求，因为客户尚未花时间来真正考虑是否真正需要每个功能。

不一定总是有问题

如果您的客户有能力购买所有这些功能，并且愿意花钱购买它，而您实际上并不关心解决客户所遇到的实际问题，那么这可能是一个非常有利可图的项目。它的发生非常罕见，对于大多数开发人员而言，这是一项令人伤心的工作，因为您可以提前感觉到该项目最终不会为客户带来成功（即使它对您作为开发人员而言在财务上也很成功）。这也是高风险的，因为您最终可能会遇到带有很多不确定性的固定成本项目，并且错误地判断大型项目的风险确实是一个问题。

如果有问题怎么办？

让我们假设您不在那种罕见的情况下。在这种情况下，您将要解决愿望清单中的两个主要缺点：

1. 客户不太可能对开发这么多需求列表的成本有正确的认识，因此您不太可能获得实际需要的金额的合同。
2. 该愿望清单不太可能准确，简洁地描述客户所要解决的实际问题。

以我的经验，您需要解决2来解决1。深入研究实际问题意味着您（开发人员）现在拥有必要的投入，可以创造性地飞跃地以客户自己从未想到的方式解决问题。这些解决方案可能比完整的愿望清单的实现更便宜，更快捷。

您如何解决？
就像Matthew Flynn在回答中所说的那样-首先要让客户优先考虑需求。这并不总是那么容易，但是强迫他们去做。如有必要，请使用短语“如果有人将枪对准您的头，您将保留哪个要求？”。在此过程中，您通常会发现客户对各个需求的含义并不十分清楚。在这种情况下，请执行Peter Rowell的建议，并通过“用户故事”吸引客户。您和客户将开始更好地理解问题和要求，然后您可以重新确定优先级。重复执行这些步骤，直到您感到足够了解解决客户的问题为止。

这如何回答开发解决方案的问题？ 有了优先顺序的需求清单后，便可以输入所需的内容，以向客户建议增量开发过程。您不必称其为“敏捷”，但是您可以建议针对每个需求（或不可分割的一组需求）将合同分解成更小的部分，并在客户确认的情况下逐一交付。或者，您可以全力以赴，使用在线和离线提供的许多资源来说服客户，以一种敏捷的开发方式进行合作符合他们的最大利益。无论如何，您都可以以一种形式提供您的合同/项目建议书，该建议书可以按优先顺序清楚地建议这些需求构建块，每个需求块都有自己的成本和结论。把那胡萝卜放在客户面前，

首先，我会先解释一下它们的要求是不现实的，并向他们提出一系列反要求。说明这将更简单，更快地解决他们的问题，从而降低成本和风险。不要试图将其纳入技术讨论范围，客户不会在意这一点。客户确实关心及时获得优质产品，解决其业务案例。如果客户不反对，要么接受合同并进行工作，要么拒绝并解释客户为什么您不能以这种形式承担项目责任。

与其他人所建议的相似，但略有不同，我建议客户的所有内容都可能有效，但他们必须优先。首先需要完成哪个项目。哪个项目需要第二完成。最重要的是，如果您没时间了，那对哪些东西的伤害最小。将每个项目的优先级从1到732（或其他）确定优先级，并按该顺序完成。

FBI的虚拟案例文件是一个历史性的例子，该应用程序由于过度的需求而最终超出预算，进度落后。它旨在替换几十个现有应用程序，并且它们都必须在切换时立即完全工作。该项目最终被取消。成功的做法是构造一个框架，并将单个应用程序逐步替换到新系统中。相反，政治和内斗导致每个应用程序利益相关者都宣称他们的应用程序是最重要的应用程序，每个人都从他们想要添加到现有应用程序的所有功能中“必不可少”来规范自己的规格。最终，每天编写的变更请求量超过了每天实际编写的代码量。

我已经看过2种情况下的“我必须拥有”的作品。在其中一个案例中，大型金融客户（使用万物瀑布）拥有40个不同的系统（我们的公司成为40个系统之一）被更换并一口气投入运营。集成测试和通信是巨大的问题。我的估计是，他们每天在电话会议上耗费10万美元（当您计算通话中每个人的账单费用时）。在这两种情况下，都需要强大的谈判者来敲定要交付的清单，然后将所有人的脚都钉在地上。没有移动球门柱，没有重新谈判。两项工作均按时完成，并按规范完成。一种是超出预算，另一种是预算内。为此，您需要非常优秀的项目经理，他们知道他们的团队可以交付什么（可以说功能Q需要3分的人）。

缺乏出色的PM，谈判人员和指标，我建议您推动客户逐步交付。如果他们仍然想要整个金砖，那么可以通过帮助他们找到其他咨询服务来更好地为他们服务。有时最好的答案是“我们无能为力”。

简短的回答：我会听取客户的意见，并找到与他们合作的中间途径。

我建议听取客户的意见，并根据他们的预算和时间安排，将项目分为多个阶段（发行版，发行版2等）。

然后，您可以继续估计可交付成果，预算以及应用程序应交付的所需功能的优先级的每个阶段。

因此，定义工作和可交付成果的范围是可行的:)

正如其他答案所指出的那样，优先级非常重要。一种简便的方法是通过MoSCoW方法。但是，您可能要先将整个列表分成几部分，否则功能列表本身会给您（或您的客户）理解问题：）

紧接着，您将面临一个整体问题。您可以与客户坐在一起并执行以下步骤来解决此问题：

• 遍历功能并从中提取类别
• 确定类别的优先级（使用MoSCoW），然后定义层次结构（具有默认功能的一个基本类别，主要主题的类别，主要主题的特定变体的类别）。这可能会更改您在上一步中定义的类别（由于有了新的见解）。
• 逐一浏览每个功能，然后将它们分配给一个类别
• 优先排序（使用MoSCoW）top-x类别中的项目。

这将为您所请求的功能提供漂亮而精巧的自上而下的视图，并为您提供了定义不同迭代以从基础开始并以其他功能进行扩展的把手。