需求搜集

需求搜集通常开展软件项目的第一步。很显然，需求对于一个软件项目顺利开展至关重要。因为只有有了明确的需求，整个项目团队才有行动的目标，任何项目计划才有依据。

虽然对于敏捷项目来说，对需求并非要求其永远牢固不变，而倡导所谓“拥抱变化”，但是在项目之初，有一个尽量详尽和稳定的需求，也是十分必要的。否则无穷无尽的需求变更，同样会导致整个项目陷入没完没了的变化中，从而所有计划、安排都成为一张废纸。太多变数或者模糊不清的需求，就算万幸没有导致项目失败，也必然会极大地增加研发成本。因此，我们需要采取一些切实有效的措施，来保证需求搜集的质量，从而为后续研发工作的开展打下坚实的基础。

 

寻找真正的用户或者用户代表

任何产品，包括软件，它的最终成败取决于其是否能满足用户的需求，因此在需求搜集阶段搞清楚用户真正的需求是再自然不过的要求了。那谁是我们软件的用户呢？这个问题看似简单，但事实上，大量实践告诉我们，许多软件项目在其最终发布之前，却很少或者根本没有确定和找到真正的用户。特别是所谓“产品”软件的研发，很容易造成闭门造车。软件研发部的同志们凭自己的想象，猜测用户的需求，然后根据这些想象出来的需求设计软件。这样制造的软件，其成功的概率自然很低。

要解决闭门造车的问题，首先作为软件研发者，我们应该习惯于怀疑自己对于用户需求的猜测和判断的准确性。对于自己从技术角度认为天经地义的解决方案，不要那么的想当然。只有养成这样的习惯，我们才能自觉地去跟用户确认需求，去寻找真正的用户。曾经我经历过一个软件项目，其软件有个信息输入窗口，有很多输入框。根据Windows平台上的习惯，输入框之间的输入焦点的跳转是通过按“Tab”键来实现。但在软件发布给用户试用时，才发现许多用户目前在用一个类似功能的DOS软件，用户习惯DOS软件的惯例，通过按“Enter”键跳到下一个输入框，而且用户输入的都是数字，通过小键盘一只右手就能完成所有输入操作，不需左手去按“Tab”键。所以，最后用户评定，新软件不如旧软件好用。虽然修改软件使其支持“Enter”键跳转输入焦点并不难，但这也是一个典型由于开发团队闭门造车，事先没有充分了解用户需求，从而造成软件得不到用户认可的例子。

在有了找真正用户的自觉性之后，剩下的问题是谁才是我们真正的用户？有时候这个问题很难问答。比如，如果我们的软件是“产品”。所谓“产品”软件就是它本质上不是专为某个公司某个特定的人开发的，可能是面向一个很大的用户群体的软件。很显然，我们不可能组织所有可能的潜在用户来开会。那样成本太高而不现实。现实的方法是，可以通过市场、销售部门去接触比较典型的用户。通过聆听，综合筛选用户的期望。此外还需要分析竞争对手类似产品的优缺点，再加上本公司对市场的预期，对今后技术发展方向的判断，来综合形成产品软件的需求。有了这个复杂的需求确定阶段，还不够。如果有条件，在正式发布软件之前，多次发布一些预览版给用户试用，搜集反馈，这样才能最大限度保证我们软件所具有的功能是用户真正需要的。

对于项目软件，可能需求搜集没有上面产品软件那么复杂。但也要小心，要冷静判断跟你联系的用户或者用户代表他本身是不是真的可以代表最终用户。我以前经历了一个项目软件开发。给我们提需求的用户代表在项目之初，很自信地宣称他可以作为我们唯一的项目需求联系人，任何跟需求有关的事情他都可以解决。换句话说，他让我们相信他关于需求的任何理解都是正确、准确和完备的。在整个项目开发过程中，这个用户代表跟我们有非常好的合作。一切似乎风平浪静。但是在项目接近结束，从他那里突然发来很多需求变更请求。他的理由是，他最近才跟一些其他用户演示或者让其他用户试用了软件，他们提出了这些新的要求。由于这个项目是公司内部部门之间的合作，我们不可能从合同上通过商业手段限制这些最后一分钟需求变更，唯一能做的就是痛苦的跟他就一个一个需求变更进行谈判，软硬兼施，最后才很辛苦的按时完成了项目。虽然这个事件没有造成大麻烦，但也让我得到一个教训。对于这种太过自信的用户代表，我们需要多点理性的怀疑。应该在整个项目过程中，不断提醒他去找更多的用户确认需求，从而从根本上避免不必要的需求变更，特别避免在项目后期发生大的需求变更。

 

与用户进行有效的需求确认的方式

不同经历、不同背景的人往往具有不同的思维方式和语言习惯。软件开发者和用户，特别是没有软件开发背景的用户，他们往往具有很不相同的表达、思维、和语言习惯。这种天然的差异经常造成对软件需求不同的理解。所以，对于我们软件开发者，特别需要用用户习惯的方式跟用户确认需求，从而避免需求误解。

对于有图形界面的软件，需要做些原型程序，至少用Visio画些界面来跟用户确认。一般用户只有在看到实在的界面和具体的操作方式时，才会意识到什么是他想要的。

对于以开发接口为形式的模块开发，要写一些实际使用该接口的例子程序，展示给用户。

任何输出结果文件，除了文字描述的格式定义，需要提供示例性的输出文件给用户确认。

总之，对于可以通过更进一步的描述和原型来展示的需求，一定要尽量具体地跟用户确认。不能太寄希望于抽象的文字描述。

《软件项目求生法则》里建议用户帮助手册的写作和软件开发并行。我觉得这个方法很好，除了可以保证帮助手册和软件实际实现信息同步以外，也是一个很好的确认需求的方式。因为用户帮助手册里的语言和例子说明，相比于其他专业技术文档，更容易让用户了解软件最终的功能和操作方式。只要用户能持续地使用软件和试读帮助手册，就能最大限度避免需求误解。

除了上述形象化的需求表达方式，一个完备的需求说明文档也是必须的。特别是对于功能比较复杂，周期比较长的项目，完备的需求文档是很好的开发跟踪手段。

 

前导性开发，解决核心技术问题

对于没有核心技术问题的软件项目，可以跳过本节。但是如果你的软件开发任务中，存在有比较难的技术问题，在需求搜集阶段，应该安排一定的人力做些试验性的开发。主要目的就是利用需求搜集阶段的时间，尽量摸清目前开发团队对核心技术的掌握程度，为紧跟需求搜集之后的项目日程制定提供比较科学的参考数据。

拿我经历过的一个软件项目为例。这个软件是用于分析一个特定协议的网络数据。网络数据用工业标准PCAP格式存储。该格式文件本身不支持快速定位到某一特定的Packet。但是用户希望这个软件可以在海量数据文件中快速的任意定位分析。在跟用户讨论需求的阶段，我们就设计了一种解决方案。由于跟用户的讨论不可避免会有些等待确认的时间，我们充分利用了这个时间，做了大量前导性开发，验证了我们设计的解决方案的可行性，从而使我们自信地承诺用户，我们的软件可以提供这个功能。另外，这个软件还被要求提供比较复杂的图形用户界面来结构化地、灵活地显示网络数据的所有细节。承担这个模块的开发人员，以前没有复杂图形界面的开发经验。我们也充分利用需求搜集阶段的空余时间，鼓励该开发人员做些试验性的开发。不但使他补充了开发知识，他的试验性的开发成果也被当作一个原型程序给用户确认是不是他所期待的。等我们完成所有需求的搜集确认，完成软件功能说明书之后，整个开发团队感觉我们万事具备，很自信的提出了让管理层和用户满意的开发日程。随后的软件实现阶段也因为我们之前扎实的准备工作而进行的相当顺利。