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

• 我们有一个相当"放任自流"的客户，尽管我们尽了最大的努力，但他实际上并不想参与决策。
• 经验丰富的开发团队会花费数小时来讨论解决特定问题的方法的利弊，并提出一种优雅的解决方案，从而避免了更为明显的方法的弊端。
• 客户快速浏览后便随随便便便提到他们想要更改它。他们不了解我们在尝试时非常仔细地考虑要避免的所有可用性/一致性问题。
• 尽管有解释，客户并不感兴趣，他们只是想改变它。
• 我们叹口气，按他们的要求去做，充分了解接下来会发生什么...
• 3周后，客户说这种方式无法正常工作，我们可以更改它吗？我们再次提出原始解决方案，他们会热情地抓住它。他们似乎总是有某种形式的选择性失忆症，并一开始就掩盖了他们在解决这一问题上的作用。

我敢肯定你们中的许多人都经历了这一过程。当我知道聪明而有能力的人们投入的时间和精力来真正理解问题并想出一个好的解决方案时，总能带给我的东西。与之形成对比的是，无奈之举与客户在三分钟之内做出选择的认识形成鲜明对比(或者更糟糕的是，他们的经理常常不知道项目的真正含义)。锦上添花的是，它通常是在一天的很晚才做的。

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

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

编辑：糟糕，我不是在谈论任何当前或者最近的客户。纯粹是假想的...

解决方案

回答

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

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

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

回答

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

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

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

回答

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

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

回答

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

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

在那之后，只要合适的人批准了更改，并且他们支付了费用，就可以了。

回答

过去，在这种情况下我们取得了一些成功，要做的一件事就是将问题移交给客户。

"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".

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

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

回答

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

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

实际上，使用原型可能是最有用的工具。考虑一下冰山效应。秘密在于，不是程序员的人不会理解这一点。 http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg

"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)穿上一双耐克的。跑步必不可少的鞋子。尝试最新的样式。

实施的解决方案：

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