让用户自行收集需求还是指导他们？

我确信每个人都经历过这样的事情。您与有项目的客户开会。他们没有/很少有需求，对他们想要/需要的东西最模糊的理解。在这一点上，似乎有两个选择：

1）告诉用户，“好吧，如果您什至无法描述它，我也无法为您提供帮助。为什么您知道自己想要的东西后几个星期不回来呢”。

2）与用户会面几次，并通过良好的ole Socratic方法指导他们进行操作，帮助他们弄清他们想要的东西。“您需要跟踪X吗？”，“ Y怎么样？”，“是否需要功能Z？”

使用第一个选项，您不会被困于他人的工作或获得心理能力，但是，用户可能永远不会向您展示连贯的规范，或者随着期限的临近，他们可能会花很长时间。使用第二种方法时，您会浪费大量时间成为业务分析师，并且不得不将很多业务知识塞进脑海中，您可能永远不会再使用它，但是您更有可能提出一种规范，有道理。

对我来说，这是发展中最具挑战性的方面之一，我感到我并不孤单。根据您的经验，这些选项中的哪一个更有效？

我必须承认，有时我会选择选项3）

3）听取客户的含糊想法，花几个星期的想法，帮助他们弄清楚他们到底想要什么...，以便弄清他们需要什么，建立它并根据需要进行重构。

这种方法特别适用于小型工作，因为它有助于避免客户脑中有这个绝妙主意的情况，这在现实世界中是不切实际的。

它一直在我身上发生；“我们一定能做得到……”这句话非常令人恐惧。特别是提到的东西几乎总是钟声，口哨声和“很好”的一类特征。他们在“显然是一个错误跟踪器，然后...”语句中并没有完全理解这一点，大部分潜在的工作都在前四个词中。

因此，有时候，以客户的眼光，应用大量的常识性程序员并构建适合他们需求的东西是很好的。

就原始问题而言；我发现这很大程度上取决于上下文。如果坚持与客户保持联系（即是通过与我有联系的工作合同进行的，或者没有替代工作），那么＃2是最明智的方法。否则，很可能在一周内您会收到一份精彩而详尽的说明……这对您作为程序员来说完全没有用。

与上述问题（＃3）大致相同，但无论如何，您都必须做＃2。

如果您只是想成为一名程序员，那么您就等到其他人弄清楚了客户的需求之后再进行编码

如果您想成为开发人员，并且这是您的客户，那么您就握住客户的手，轻轻地带领他们走过茂密的可怕森林，直到在旺旺与需求的交汇处一起找到快乐的兔子般的草地。

附录：此过程称为“系统分析和设计”，又名“咨询”，永远不应免费进行

编程首先是要解决用户的问题。因此，对我来说，为了使我们的用户获得可行的，可满足的解决方案而付出“额外”的努力和痛苦几乎总是在避免“额外”的麻烦上获得胜利，并且最终没有提供任何有用的东西。

（当然，那里有真正的用户，他们真的不知道他们想要的是什么，并且没有任何努力可以使他们进入可以做出任何有意义的决定的状态。但是我相信，在大多数情况下，他们确实有这是一个真正的问题，他们愿意花费精力和金钱来解决问题，如果我们能帮助他们更接近可行的解决方案，他们将很高兴。）

因此，最重要的是，我们的重点应该放在解决用户的问题上。有时这可能需要提出一些针对性的问题，并给他们更多的时间来找出答案。有时，它需要密切合作共同绘制域图。有时，它需要花费一些时间来制作简单的草图/原型/模型，然后向他们显示结果并询问“这看起来像您的想法吗？” （然后，当他们说“实际上，我在考虑完全不同的事情……”时，将原型扔掉，然后从头开始……：-）

真正的技能是在正确的时间选择正确的方法。

最后但并非最不重要的一点是，根据我的经验，好的解决方案几乎总是需要开发人员至少提供一些领域知识。没有这个，您与用户之间就不会有真正的共同语言，因此无法保证您交付的内容对他们真正有用。用户通常对技术了解不多，因此不知道什么是可能，什么不可能，以及不同方法/功能的成本是多少。由于我们不能合理地期望他们学习足够的细节，因此我们应该从桥梁的尽头采取额外的步骤。

这可能被视为“额外”的努力，没有回报-但是，我更倾向于将其视为投资，这有两个原因：

• 它有助于我提供良好的解决方案，从长远来看，这将增加我作为开发人员的市场价值，并且
• 不同的领域并不是完全不同的，因此至少一部分领域知识可能会在将来的演出中重用。

作为软件开发人员，您的部分任务是要充分了解软件将要在其中使用的领域。因此，作为项目的新生阶段的一部分，这是非常有价值的（就时间和客户体验而言） 。是的，这意味着要进行全面的域和需求分析。现在是整合目标用户，采访他们或在使用软件的地点走动的最佳时机。

但是，获得此技能几乎是一种艺术形式，尤其是当该领域未与工程学科联系在一起时。您显而易见的问题可能对客户来说是艰巨的，可能就不需要您的现场存在，您对目标受众的社会结构缺乏了解可能会使仍然脆弱的联系崩溃。

如果不了解此阶段的复杂性，无论是对于软件开发人员还是对于客户，都会导致失望。我们希望更快地完成此阶段，或者完全取消它。结果往往是灾难性的：在匆忙起步之后，在开发过程中，成功的赌注越来越高，而回到绘图板上变得越来越困难。当系统最终完成并花费了数百万美元时，客户和工程公司都不愿意承认其故障，从而导致强制引入故障系统。

另一种选择是让业务分析师为您完成这项工作。这对于某些产品可能是明智的，并且分析师通常能够成为中介，但只会创造更多的沟通渠道（因此出错的可能性更高）。

无论如何：重写一​​段代码永远不会超过重写一段需求。

ps也许您认为我在倡导瀑布方法。我不相信“大设计”，但我确实相信领域分析工作应与实施工作成比例。一个可以进行多个循环（原型，候选发布等）。

绝对是选项2，除非您的用户是开发人员（即使那样也可能需要选项2）。

许多大多数软件开发生命周期都集中在需求收集上。大多数用户不仅不知道自己想要什么，而且也不知道可能做什么，因此与用户一起了解用户需求是一项关键的软件开发任务。

我认为您需要同时使用这两种选择。让他们离开并决定他们想要什么。然后，如果有一个具体的想法可以用作出发点，请指导他们帮助将需求细化为有用的内容。

当他们几乎无法清楚表达他们想要的东西时，您不想跳入第二种选择，因为这会使整个过程变得更慢，更令人沮丧（除非他们已经很清楚地知道了他们来找您想要什么），但是以我的经验，这非常罕见）。让他们把想法融合在一起。让他们在纸上写下一些东西，如果可能的话，用现有系统描述他们想要的东西（例如：“我们想要一个像blahblah.com这样的网站，但是存在这些差异……我们想要一个可以像产品X一样执行任务A的工具，但UI也必须执行任务B ...”）。然后是时候开始将他们想要的内容细化为可用于构建系统的非常具体的需求了。

通常，客户会确切地知道他们认为他们需要什么。不幸的是，这就是他们会告诉您的，而不是描述导致他们认为您将提供的解决方案的问题。

为了设计出满足他们需求的产品，您必须确定这些需求，而要做到这一点，就必须有人压抑客户并提取这些需求。如果没有其他人可以做到，那么您必须。（如果其他人认为他们可以做到，那么您可能需要与他们以后再提取实际需求...）

使用选项2，可以在多次会议上培训客户与您共享问题，而不是解决问题。（即使客户具有技术能力，例如，他们没有能力进行这项工作，而是需要您去做，他们可能仍然专注于对最终客户而言并不理想的实现。）无论您使用哪种开发过程，您都仍然需要反复来回几次，直到他们以可以为您定义规格的方式回答问题。

请记住，您希望尽早在开发周期中发现缺陷。如果您可以在需求期间（而不是在编码或测试期间）捕获它们，则可以节省很多时间。

选项1是避免进行某些工作的好方法。当我认为这项工作是不必要的，或者我还有更重要的事情要做时，我就使用它。

首先，用户不知道计算机可以做什么。我们大多数人花了多年的时间来学习计算机和计算知识，而对于那些花了多年时间学习其他东西的人来说，对我们来说显而易见的东西可能并不容易理解。

其次，从任何可行的意义上讲，用户不一定知道他们需要什么，通常也不知道他们想要什么。

打个比方，当我购买当前的房屋时，一位室内设计师为主要（美国第一，英国地面）楼层的房间选择了墙壁的颜色。我自己不会选择那些颜色。我想要一间看起来不错的房子，并得到了它。如果设计师听了我的话，并给了我我可以说的任何东西，那也不会那么好。

以自己喜欢的方式为用户提供所需功能的唯一方法是自己与他们合作。