对于参与需求收集会议的开发人员来说，理想的心态是什么？

Question

作为我团队中的中级开发人员，我参加了我将参与的项目的需求收集/范围规划会议。我发现很难想出那些能给讨论或我的知识增加价值的问题。经过一些自我分析后，我发现知道有一位高级工程师负责该项目的讨论，这使我在其中一些讨论中表现得很放松。但我确实想达到这样的程度，我被赋予更多的责任和技能，以处理我自己的项目。尽管心态这个词有点抽象，但我想在下面列出的几件事上得到一些建议：

• 我需要什么样的准备才能从这些会议中得到最大的收获。从团队成员的观察中，我注意到，了解项目将要影响的所有系统，什么业务决策将主要影响项目设计等等，都是其中的一部分。
• 我是否需要避免考虑每个需求的低级别实现细节。一方面，我觉得考虑它们是很重要的，因为我会知道可行性，但我也明白，这阻碍了考虑所有的选择。
• 最后，作为一个开发人员，有什么我不应该担心的呢？

Answer 1

按顺序回答你的问题：

1. 在准备方面，我们的思维方式是问正确的问题，这样用户才能确切地知道他们想要什么。这比看上去困难得多。我需要强调问正确的问题。具体一点，如果有任何含糊不清的地方，问另一个问题。通常在这些会议期间，客户的一个回答会产生3个新的问题。一旦你知道他们想要什么，那么你的工作就是弄清楚它如何影响不同的系统，而不是他们的系统。

如果客户想要的要求是不可能的，那就告诉他们(我的教授常称它为“汽车上的翅膀”)。有时候，客户对软件的了解不够充分，无法了解软件的功能。努力解决这个问题。

1. 不，那是在设计阶段。如果它不能工作，则重新检查需求。
2. 不要担心第一次就把它做好，因为你肯定做不到。需求总是因为特性的爬行而变得一团糟，客户想要新的东西但从不告诉你等等。

Answer 2

大多数时候，用户都清楚地知道他们的日常工作以及他们必须解决的问题。他们通常不知道的是

( a)软件必须看起来如何才能支持该过程。

( b)他们如何向你解释他们的过程。

因此，关注于问题，以了解用户真正想要什么(他们的目标，他们的工作过程)，而不是一个按钮应该是蓝色，红色，左边或右边的对话框。通常情况下，澄清任何含糊不清并不是那么重要，而是正确的含糊不清。

关于“低层次细节”：在会议期间避免这种情况-往往有不同的解决办法来实现同一目标，有不同的低层次细节、不同的成本/开发努力、不同的可行性。根据我的经验，最好是考虑一下需求(在会议之后！)，然后在您对需求进行彻底分析时，提出一个可行的解决方案。

尽量避免担心针对具体需求的潜在开发工作(至少在会议期间是如此)。只写下所有的需求并不意味着它们必须实现1:1。在您的会议之后，您或团队将有机会对它们进行分析，对实现进行估计(对于相同需求的不同可能的解决方案可能会有不同的估计)，然后这些需求将被重新排序或讨论。你应该避免的是告诉人们在会议期间的任何估计，即使他们问你或试图给你压力。只要说“我稍后会给你答复”。

Answer 3

在进行需求收集时，我试图强调的是，如果这是为了替换现有系统，那么不要考虑如何在现有系统中进行工作，而应该考虑如何完成您需要完成的任务。

因此，用户常常被事情的方式所困扰，他们只能用这种方式来描述自己的需求。

作为实现者，最重要的事情是理解他们真正想要实现的目标。在我学习如何进行业务分析时，有一本书帮助了我，那就是软件需求模式，这本书讨论了如何更深入地理解一些有时被忽略的隐式需求。

另外，领域驱动设计是一本值得研究的好书(特别是关于普适语言的概念，它基本上是说使用领域专家使用的术语，不要把它们翻译成"developer“，在翻译中丢失了很多东西)。

另一件很重要的事情是尽快了解你的目标领域。当我为一家物流公司开发时，最值得相信的是，我了解了发货人、科西格人、责任方、比Truckload还少、集线器、码头以及其他我需要知道的东西，以便与企业进行明智的交谈。当我在一家石油公司工作时，我花时间学习了有关钻井、油井、油田、产量、饱和度以及所有与这个行业有关的有趣的东西。

这是我能给出的最有价值的建议，学习你正在为之开发软件的行业，你将能够从用户那里收集更好的需求。