与不知道自己想要什么的客户合作

我最近开始从事一项可以在现有系统上工作的工作。它需要调整和更新以及新代码。我现在已经完成了几个维护/功能添加项目，其中一些最终与实际要求的结果有很大不同。因此，我不得不对该项目进行多次编程，以使其到达请求者想要的位置。

现在，如果需要这样做，我不介意重新编程功能。但是，我想减少项目的周转时间。瓶颈似乎在于请求者对需要完成的事情的理解。您对我可以做什么以更快地了解请求者的需求有任何想法吗？

几点建议：

• 听问题，而不是解决方案。许多客户喜欢告诉您如何解决他们的问题。不要听他们的话。您是程序员，寻找问题的解决方案是您的工作。而是倾听客户遇到的问题，并找出解决问题的最佳方法。正如其他人所说，客户并不真正知道他们想要什么，有时您必须先向他们展示。

• 提出问题。问完问题后，再问一些。客户很少会提供细节，因为他们没有真正考虑它。获取所需信息的唯一方法是将其撬出。

• 以书面形式取得成果根据客户的情况，稍后当客户开始抱怨您交付的内容“不是他们要的”时，这可能非常重要。如果没有其他事情，写出详细的规范可以帮助您确保拥有所需的所有信息，并有助于消除您与客户之间的歧义。

• 沟通是关键。不要只是与客户交谈，获取信息，敲掉一些代码，直到完成后才与他们交谈。始终与客户保持联系。在整个过程中提出问题。向他们展示您的进度并获得反馈。从长远来看，这将使每个人的生活更加轻松。

您从交流中学到的任何自助书几乎都会给您带来一些变化：

• 寻求了解，然后了解

这来自7种习惯书，但它们都是“ 主动聆听 ”方法的一些变体。目标不仅是要了解，而且要与您了解的人交流。

有一次，我想我的，他们有什么好主意需要（从他们什么远离想如果他们开始描述实现细节特别-这是你的工作不是他们），我给他们使用的系统不同人的故事的例子，看看与他们嬉戏。

然后，我实现了这一点，完全期望一旦他们看到了该功能，他们就会真正意识到这并不是他们想要的。保持一切灵活。唯一不变的是变化。我通常会在初次更新之后进行第二次快速更新后，解决大多数粗糙的问题，但是我总是发现我正在渐渐接近一些我无法达到的理想。最终，您需要放任所有无关紧要的事情，然后转向更高价值的目标。

我感到你的痛苦。

坏消息是：根据您要处理的客户的确切类型，这可能像往常一样。

一个普遍的一般问题是客户不知道他们想要什么。他们通常知道根据业务目标要实现的目标，但他们通常不知道软件解决方案的外观。因此，在许多情况下，您会发现自己处于这个迭代周期中，一个项目会以最初估计的时间来回弹跳五次，因为客户不断改变主意并希望对解决方案进行调整和重新调整。是的，最终结果变成与最初目标完全不同的东西并不罕见。

我有一个发生在几年前的史诗般的例子-一个最初花了10周的代码完成的项目变成了15个月的重复迭代。在那种情况下，主要是因为客户公司的不同经理和部门想要不同的东西，所以他们不断将工作发回去，进行调整和重新调整（我们的软件是基于订阅的，这是一个主要的客户，所以这完全没有财务问题-只是很大的技术烦恼）。

所以基本上我的建议是这样的：

如果这就是您的特定行业和这些客户的方式（这是一个很大的因素），那么请习惯一下。可以将其视为敏捷的，面向维护的工作（这或多或少是我目前的工作方式）。:)

如果这不是必须要做的事情，并且您因长期的周转而受到指责，那么请与老板交谈。向他们解释存在通信问题，并且客户提供给您的规范不够清晰，无法实现所需的解决方案。如果您没有获得所有必需的信息来向客户提供他们想要的东西，那么您就不会因为没有给客户想要的东西而受到指责。

首先，您应该接受这样一个事实，即客户直到看到客户才真正知道他们在寻找什么。他们可能会立即告诉您他们需要功能X。向他们显示功能X，他们就会意识到他们真正需要的是功能Y或功能X的另一个变体。

拥抱并遵循敏捷宣言（一种专注于沟通和客户协作）的一种更好地了解客户真正需求的好方法。将开发周期划分为迭代，并在迭代的每个结束时向客户展示功能的原型。这样，您将立即获得反馈并根据客户端的反馈进行更改，而不必在功能上投入过多资源。这样，您和客户都会对产品的结果感到满意。

我敢肯定，过渡对于您的团队或您的公司来说将是困难的，但这是应对快速变化的需求的最佳方法之一。

在这里可以找到很多很多类似的故事。我从来没有，甚至作为另一家开发公司的分包商，都找不到一个确切知道他们想要什么的客户。

我很高兴与一个对自己不想要或想要避免的事情有一个非常好的主意的人一起工作。我通常可以从那里工作到他们满意的地方。

我的经验主要是在应用程序/平台开发方面。值得庆幸的是，我很少像网页设计师那样处理美学问题。

经过许多烦人的重写之后，我现在进行所谓的完全披露。

因此，在讨论了客户的需求和期望之后，我将始终写下我认为他们想要的东西以及如何继续满足该需求。然后，我将把我写的内容发送给他们，并等他们得到肯定的答复后再开始工作。

如果它是一个大型项目（超过5天的工作时间），我也将制作原型。这使他们有机会改变主意，而无需在我端进行大量代码更改。

它并不总是有效，但是至少我在客户所处的位置上知道这是他们改变主意，而不是我执行不正确。