程序员应该为客户“思考”吗？

我到了讨厌需求收集的地步。客户对于自己的利益过于模糊。在敏捷的环境中，我们可以向客户展示一件完成的工作，这还不错，因为我们可以对功能进行少量的定期更正/更新。

在“瀑布式”的环境中（首先是需求，然后是近乎完整的产品），事情可能变得很难看。这种环境使我不断提出要求。EG客户希望“将输入自动转换为数字1”（指订单中的数量）。但是他们没有考虑的是“输入”可能是一个简单的type-o。文本框中的“ x”可能是“笨蛋”，而不是我想要的那些“牙膏”产品之一。但是，有很多要求，我可以忍受并纠正几个小时，最终弄清他们想要的东西。这是不健康的。

在一家公司工作时，我可以尝试调整文化以适应对我们有帮助的敏捷模型（不小的工作，高于我的薪水等级）。或者，在地毯下扫除丑陋的细节，并希望得到最好的。也许我的客户试图与代码过于接近？

如何处理“为客户考虑”的问题而又不给他们太多的问题而烦恼呢？

在大多数情况下，客户不知道还能做什么。他们从来不需要以对我们明确的方式描述他们的需求。在他们看来，这很明显。甚至他们正在考虑将用户输入转换为数字1的事实确实超出了他们习惯的思维方式。

确实如此。如果他们真的很新，可以准确地描述他们想要的东西，那么他们就不需要我们为他们写东西了。因此，我们的责任是在整个过程中帮助他们。该过程确实需要做出决策，因此他们也需要我们的建议，以使决策过程更加容易。

因此，让客户含糊其辞，高层次地交谈。他们了解自己的业务，这就是他们的专长（希望如此，否则他们将无法支付您的账单...）。将他们谈论的内容考虑一会儿。最终，您会得到一些好主意，以使他们了解他们的需求和需求，同时确保您的需求可测试且一致。

我强烈建议分块工作。当您与客户见面时，会有一系列彼此相关的要求，然后解释您打算如何做他们想要的事情。还请说明您为什么做出选择。然后，客户可以查看您提供的内容并进行微调。如果您收到诸如“我从没想过，但这确实有帮助”之类的答复，则说明您对客户的想法有所了解。注意：这不是特征，它是在选择最适合客户所遇到的业务问题的正确功能。

如果您有任何看起来可能与客户明确告诉您的内容相抵触的内容，那么该是时候解释原因了。您需要提出一些客户从未想到的问题，您的替代方案如何仍能给他们他们想要/需要的东西，同时还要避免那些潜在的问题。您可能会有所回落，但由于他们意识到您正尝试向他们提供可以真正使用的产品，因此也建立了客户信任。如果他们做出一些回击，这将迫使他们解释为什么他们想要某种方式的东西。这可以帮助您更多地了解客户，并根据需要调整需求。

使客户厌烦的最快方法是一个接一个地问所有小问题。您想计划和安排一系列会议以审查您的方法。只要您拥有技术要求（团队用于构建产品的方式）并且客户拥有业务需求，并且可以将它们联系在一起，便可以弥合差距。

如果您因太多问题而“生气”，请寻求更好的客户。

客户不知道他们想要什么。当他们看到解决方案时，他们不一定会意识到他们的解决方案。这是一个问题，这就是您要解决的工作：将其需求转换为可以作为软件包交付的东西。

为此，您必须了解自己在做什么。您不应该问“他们在文本框中输入数字会发生什么”，您应该问“为什么这个数字很重要？它的作用是什么？” 让他们教你如何做自己的工作。而且不要听他们说什么，因为他们不知道自己想要什么，而是要看他们在做什么以及眼睛在哪里。

请阅读以获取更多信息：http : //www.joelonsoftware.com/articles/fog0000000356.html

假设您是某家公司的员工，这听起来像您需要一位优秀的业务分析师来帮助在客户与您自己之间调解这些细节。我猜想您没有足够的影响力来实现这一目标，因此，我的下一个最佳建议是，了解有关客户所处领域的更多信息。通过了解其业务和与之合作的流程，您可以尽管他们描述的方式可能很松散，也可能有错误的地方，但他们会对他们真正想要做的事情有一个更好的了解。这样一来，您就可以分析他们的要求，然后在以后的另一次会议中回来，对他们的需求进行解释，并提供有关他们真正想要的建议。如果您始终与相同的客户合作，

如果那看起来非常困难，痛苦，极其不愉快或不现实，我的最终建议是开始在他们有业务分析师的地方寻找新工作，因为如果不付出一些努力，这将不会让您变得容易。

如果您正在收集需求，那么您将要问这些问题。

是的，客户可能会很生气，但是在这种情况下，您需要解释为什么要问“所有这些问题”。您需要先了解他们的业务，然后才能编写将使该业务自动化的代码。最关键的是，如果您不这样做，他们将花费大量金钱来开发实际上无法执行他们想要的功能的系统。

这样做的副作用是您应该最终帮助客户改进他们的需求。

无论您是在进行大型设计还是敏捷设计，这都适用。

可悲的是，为客户考虑自己是否愿意或不会自己做是您的工作。

我有两种可能的结果：

• 客户很高兴您实际上在思考他告诉您的内容，他觉得自己在正确的手中，或者

• 客户很生气，因为您强迫他重新考虑他的要求。但是，无论如何，此类客户迟早都会惹恼您。如果他发现您起初没有想到他为时已晚，他一定会非常恼火。我会说：尽可能避免此类客户：-)

一个快速应用开发（RAD）以及解决这个问题。

根据您对他们所需的最佳猜测，为程序制作一个非常粗糙的非功能UI，从而开始“为客户考虑”。然后向他们展示并反复进行工作，直到满足他们的实际需求为止。

不是他们不知道自己想要什么。因为直到他们看到他们才知道他们想要什么，有时您可以通过排除来确定他们想要什么。也就是说，向他们展示他们不想要的东西，并注意他们的批评方式。

BFUD（Big Up Front设计）的主要问题在于，它通过迫使客户签订明确描述他们将要获得的收益的合同来使开发人员免受责备。不幸的是，这是在项目中没有人真正知道实际需要什么的时候完成的。最后，这只会使客户接受您的构建，因为他们签了字，但有些勉强。

如果客户对交付的产品不满意，那只是痛苦的胜利。

客户的工作就是向您传达他们的需求。您的工作是充分了解他们的需求，以便能够对他们的需求进行编程。对于将所有输入更改为一个的问题，一个显而易见的问题是：“为什么要将所有输入更改为1？” 然后，客户可以解释其背后的原因，以便您了解需求，然后能够不一定提供他们的要求，而是提供他们的需要。如果您有信心知道他们的需求，那么我认为您不必“纠正”他们的思路。他们将使用产品和东西“哦！太完美了”。但是，除非您有信心知道自己的需求，否则就需要先解释您的想法并与客户一起解决。不幸的是 如果没有大量的交流，而这实际上涉及到两个部分的聆听，则无法执行过程的这一部分。请小心不要对情况感到烦恼，并说出您可能想要或可能不想说的话。

老实说：除非这是“大功能”，否则请具有最专业知识的人对应该发生的事情做出最好的猜测，并加以实施。它会在验收测试中充实-这就是为什么。