需求收集

Question

您是如何进行需求收集阶段的？有没有人有一套很好的指南或小贴士可以遵循？问利益相关者一些好的问题是什么？

我目前正在做一个新的项目，有很多未知数。我正在向利益相关者提出一系列问题。然而，我情不自禁地觉得我错过了什么，或者忘记问一个批判性的问题。

Answer 1

您几乎可以肯定会遗漏一些东西。可能有很多事情。别担心，没事的。即使你记住了所有的事情并涵盖了所有的基础，如果没有任何参考点，涉众也不能给你非常好的、清晰的需求。做这类事情的最好方法是现在就从他们那里得到你能得到的东西，然后给他们一些东西来做出反应。它可以是一个纸质原型，一个模型，0.1版本的软件等等。然后他们就可以开始告诉你他们真正想要的是什么。

Answer 2

请看下面的必备漫画。

一般来说，我会尝试去感受一下我的客户/客户试图用他们想要构建的应用程序来模拟的业务模型。我们是在构建一个美化的表单处理器吗？我们是否要在单个应用程序中从多个来源检索数据以节省时间？我们是在执行某种集成吗？

一旦建立了一般的业务模型，我就移动到应用程序的“必须”和“不能”，以指示我可以检索哪些数据，谁可以执行哪些功能等。

通常，如果您能让客户解释他们的模型或工作流程，您就可以从中找到其他关键问题。

我总是以这样或那样的形式问一个问题：“在做X时，你必须做的最棘手/最烦人的事情是什么。通常，这个问题的答案揭示了你必须实现的最疯狂的业务/数据规则。

希望这能有所帮助！

​

​

Answer 3

Steve Yegge说起来很有趣，但了解别人的需求是可以赚钱的，所以我对他的文章持保留态度。

由于通信的工作方式，需求收集是非常困难的。这是一个四步的过程，每一步都是有损的。

• 我脑海中有一个想法，我把它转换成文字和图片，你解释图片和文字，
• ，你在自己的脑海中画出我最初的想法是什么样子的图像<

>F210

而人类在这方面的失败令人担忧，因为他们可爱的不完美。

敏捷在促进迭代开发方面做得很好。将早期版本提供给客户端对于确定哪些功能是最重要的(在0.1 -0.5ish中提供了哪些功能)很重要，这有助于让你们在应用程序的工作方式方面保持在正确的轨道上，并快速识别出您将错过的隐藏功能。

两个主要的问题场景是天平的两端：

对你在做什么有一个奇怪的线索-- get Some域experts

• Having too some - feature pit。-问题，剔除(优先级;)特性并使用迭代开发

Yegge很好地指出，领域专家对于产生良好的需求至关重要，因为他们了解业务并在其中工作过。他们可以帮助识别客户的核心愿望，并帮助解释他们的员工将如何使用系统，以及对员工来说什么是重要的。其他选择和补充包括尝试自己做这项工作，以进入心态，或者让客户工作人员偶尔在现场，尽管后者不太可能发生。

功能坑是另一边，大部分都是失败的政府IT项目。太多，太快，没有足够的现实主义思考或应用(但你希望他们只有四年左右的时间让自己觉得自己很重要吗？)。这里的目标是弄清楚客户真正想要的是什么。只要您致力于使核心组件正确无误，高效和无bug的客户端通常会对后期交付中丢失的功能保持容忍，只要它们最终到达。这就是迭代开发真正有用的地方。

记住要区分客户对程序将是什么样子和他们希望程序实现什么的想法。一些客户可能会通过以应用程序功能的形式传达他们的需求来制造混乱，这些功能可能考虑不周，或者由于比他们认为需要的简单得多的功能而变得多余。虽然我并不提倡说客户是个笨蛋，或者不听他们的话，但我觉得永远值得问一问，为什么他们想要一个特定的功能来达到其潜在的目的。

请记住，在任何一种情况下，都必须找出满足客户核心需求的最快路径，并将您置于双方都从关系中获利的场景中。