收集业务需求信息

在我看来，收集业务需求信息是每个开发者都应该掌握的艺术，但似乎大多数人都缺乏这种技能。实际上，这方面存在两个极端。

一些开发者喜欢收集需求信息，然后建模，并画出漂亮的流程图。他们对于一个完美项目的理解是你所做的一切就是收集业务信息并建模。而另一端是大多数开发者，他们将收集业务需求信息的过程看成是对整个开发过程(包括设计，编码，以及测试)所需时间值得怀疑的占用。不管你属于哪一个阵营，这篇文章--也是我们一系列文章(五篇)中的一篇--将会向你展示一些收集你所需要的信息的有价值的方法。

所有开发者都应该学习的技巧

实际情况是所有的开发者，尤其是高级开发者和团队领导，需要了解到收集业务信息的重要性以及拥有收集这种信息的基本技能的必要性。对于收集这种信息的重要性是很容易说明的。提前收集需求信息能够节省时间和成本并提高整个产品的质量。记住，你的客户会要求最终的解决方案要满足他们的需求。问题是你是否在开发设计和创建应用程序以前就搞清楚了他们想要的东西，或者你将不得不在软件完工后改进这个解决方案来补上没有达到的需求要求。

一旦你了解了业务需求的重要性，你现在的注意力就应该转移到如何用有效的方法来获得这种信息。你可能已经有了自己比较喜欢的方法来与最终用户或者其它企业部门中的人打交道的好方法了。那么，现在已经足够了，对吧？不对。

即使你感觉到了你现在使用的方法工作得很好，那么在你的工具箱中再增加另一个工具是会有帮助的。求助你的专业专家来获得其它的技术，你将有可能挖掘到他们以前没有告诉你的信息。

找到答案

你需要经常使用多个收集信息的技巧来获得你所服务的系统完整的图画。下面是一些你在着手收集业务需求信息的时候可以使用的技巧：

一对一的面谈：最普通的收集信息的技巧就是与客户坐下来并询问他(或者她)需要的是什么。这种讨论可以提前安排进行，具体的时间要根据你寻找的需求信息的类型而定。这种调查可以设计为讨论目前的开发进程，未发现的将来可能需要的需求，或者确定客户目前正在试图解决的问题。

分组调查：这些调查与一对一的面谈有相似的目的，但是如果你想从所有的参与者都得到信息，那么你需要更多的时间和手续来准备。你如果集中于一组人，那么你将可以用较短的时间来获得更多的信息。

主持会谈：在这种方法中，你召集更多的一群人并将他们聚集在一起直到所有的信息都已经收集齐全。这种会谈可能需要所有的主要的和次要的项目参与者都参加以确保业务需求的所有部分都已经考虑到了。这种方法需要做大量的准备工作并使用训练过的技巧来将会议保持在议题之下并有效的进行下去。

询问：这种方法显得不正式得多，而且其作用有限。但是，询问对于与远程的项目参与者或者那些对于整个需求只占很小的一部分的参与者来说是很好的方法。调查询问还是一种快速收集数据，比方使用某个特定功能的可能的人数，或者你还可能通过这种询问来对于需求的相对重要性有一个大概的了解。

与周围的人打交道：这种方法对于收集当前进程的信息来说是特别有用的。你会发现，例如，一些人的工作方式已经如此的具有习惯性以至于他们很难解释他们在做些什么或者他们为什么要这样做。你需要察看他们所做的工作才能理解整个项目的意图。

特例--原型化的方法

原型方法是一种收集信息的相对现代的方法，并且对于Web开发来说相当有效。在这种方法中，你先收集初步的信息而后建立一个解决方案的初始版本--即原型。你向客户展示这个原型，然后客户向你提出进一步的需求。这种反复性的进程要么进行双方同意的次数或者直到这个产品满足了业务需求的绝大部分。

成功和失败之间的区别

能够收集到易于理解的需求信息能够决定一个项目的成功与失败。许多开发者要么有不停的收集这种信息或者根本就不收集这种信息的倾向。你应该确保你的项目计划包括创建一个易于理解的需求列表所需的时间。开发者们通常会以一对一调查的方式收集需求信息，但是就象我们上面说的那样，你还可以使用其它的技巧。掌握这些技巧将使你能够以更有效的来收集你的需求信息。