关于方法论：如何处理信息不充分的客户选择

我敢肯定，这是一个大家都熟悉的场景。

您有一个相当"放任自流"的客户，尽管您尽了最大的努力，但他实际上并不想参与决策。

经验丰富的开发团队会花费数小时来讨论解决特定问题的方法的利弊，并提出一种优雅的解决方案，从而避免了更为明显的方法的弊端。

客户快速浏览后便随随便便便提到他们想要更改它。他们不了解您在仔细考虑后要避免的所有可用性/一致性问题。

尽管有解释，但客户不感兴趣，他们只是想更改它。

您叹口气，按照他们的要求去做，充分了解接下来会发生什么...

3周后，客户说这种方式无法正常工作，您可以更改它吗？您再次提出您的原始解决方案，他们会热情地抓住它。他们似乎总是有某种形式的选择性失忆症，并一开始就掩盖了他们在解决这一问题上的作用。

我敢肯定你们中的许多人都经历了这一过程。当我知道聪明而有能力的人们投入的时间和精力来真正理解问题并试图提出一个好的解决方案时，总是能得到我的帮助。与此形成对比的是，沮丧的是，客户很快就可以在3分钟之内做出客户的选择(或者更糟糕的是，他们的经理常常不知道项目的真正含义)。锦上添花的是，它通常是在一天的很晚才做的。

我知道敏捷方法旨在解决此类问题，但是它要求一定程度的客户购买，因为某些类型的客户(通常是花钱的人)不愿意付出。

有人对您如何处理此问题有任何明智的见解吗？

编辑：糟糕-顺便说一句，我不是在谈论任何当前或最近的客户。纯粹是假设...

---

通过您为设计和开发解决问题的方法而付出的努力，使客户付钱。

工作越多，您得到的越多。客户将不得不为自己的错误付出代价。

客户最终将学会欣赏您在编程领域的经验和见识。

---

我同意Niyaz。但是，当客户提出更改建议时，您应该确定更改将产生的影响以及该影响发生的可能性。然后询问负责交付的人(并不总是那个客户)是否同意更改。

明确影响(增加成本，降低可靠性，延长交货时间等)对于帮助客户做出决定非常重要。以事实的方式描述对项目或其业务的影响并评估这种影响发生的可能性非常重要。"也许"和"我的感觉"非常可忽略。

在那之后，只要合适的人批准了更改，并且他们支付了费用，那么您确实给了他们他们想要的东西:)

---

Niyaz是正确的，不幸的是，要让客户买进是很难的，直到他们被烧毁一次为止。

此外，向客户描述上述情况，并说明如果您下线三到四个星期并由于更改而不得不重写它，然后让他们使用原型，那么将花费多少额外费用。将一个选项放在一起可能需要几天的时间，以便他们可以同时看到两个选项(它们的[错误方式]和您的[正确的方式])。请记住，他们不仅因为您的编程能力而付款，而且还因为您的经验和知识而产生的问题。

无论客户做出什么决定，都要确保将其记录在案，并用选定的实施可能产生的风险更新项目的风险登记册，并与项目经理(如果不是您)与他们讨论缓解计划。

---

通常，这种情况是由两件事引起的。那些应该为您提供需求规格说明的人要么是因为对项目不感兴趣，要么因为对项目不感兴趣，或者因为他们真的不知道自己想要什么而将他们的心投入到项目中。

敏捷编程是最好的方法之一，但是还有其他方法可以做到这一点。我个人通常使用经典的瀑布方法，因此螺旋和敏捷方法是不可能的。但这并不意味着您不能使用原型。

事实上，使用原型可能是最有用的工具。想想冰山效应。秘诀是，那些没有程序员的人对此一无所知。 /d/file/2023041419/tfertopv4aq05

"You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers...." - Joel Spolsky

生成原型需要花费时间和精力，但这是收集需求的最有效方法。我的项目团队所做的是，UI设计师是制作原型的人。如果为用户提供原型(至少是应用程序的外观和感觉的工作界面)，那么您会受到很多批评，这些批评会导致人们的愿望和要求。它看起来像在YouTube上的评论，但这只是一个开始。

第二期：

The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.

生成另一个原型。这里的关键是用户希望看到的结果，而不是他们必须听的建议。

但是，如果其他所有方法都失败了，那么您始终可以列出实施该解决方案的利弊，无论他们喜欢的特定解决方案不是您坚持要求的解决方案。使文档的该部分尽可能可读。例如：

问题：

公园是所有好看的女人都在努力保持体形的地方。约翰尼·布拉沃(Johnny Bravo)喜欢享受"大自然的美"，因此他希望融入……你知道……寻找所有的爱好者，在追逐尾巴的同时做些慢跑。

替代解决方案：

1)穿上黑色麂皮鞋，尽你所能。

2)穿上一双耐克的。跑步必备的鞋子。尝试最新的样式。

实施的解决方案：

黑色麂皮鞋是首选，因为...好吧，因为热妈妈们都在挖黑色麂皮鞋。

---

过去在这种情况下取??得成功的一件事是将问题移交给客户。

"OK, you want to change it - this is
what will happen if you do that. These
are the issues involved. You have a
think about how you'd like it to work
and then get back to us".

这种方法并不会(不会令人惊讶地)产生好的解决方案，但是会倾向于让客户看到这不是一种"胆量感觉"，而是在暗中质疑。

否则，通常会使他们停止要求您进行更改！

---

否则，如果他们不为此付出代价，那就避免将那么多的资源投入到解决问题的过程中，只给他们他们所要求的，然后在三周过去后再考虑一下。

是的，这有点令人沮丧，但这就是这种类型的客户始终会遇到的问题。至少您不会亏钱。

---