需求？

对我来说，每个想法的产生都有一个郁闷的源头；不得不承认，我总是处于这样一种境况：当项目一切顺利时我会没心没肺的吃吃喝喝，而当不得不面对那些无聊的困境时，我会一边抱怨一边想点无聊的点子出来。嗯，听起来是份很没意思的工作，可是你还能对一个拖家带口的中年男人有什么要求呢？

最近就在干一件无聊的事情，我在检查一个即将结束的项目的需求，吃惊的发现有不少功能点压根就没实现，还有很多实现和需求压根就对不上。之后我要把它们从一个静态的word文档扔到需求管理工具里去。在项目尾声做这种早该做好的事情，确实有点不好意思，不过无论如何，有总比没有好吧。

原本应该是一个项目核心的需求文档，被忽略到这种程度，你当然可以对着整个项目大骂一通，然后找个会吹牛的来做个“需求和生命一样重要”的培训。不过，像我常常说的，问题是多种的，解决方法比问题还要多。我习惯的一种找出解决方法的思路就是“釜底抽薪之计”。如果大家都不喜欢需求文档，我们干脆就不要写需求文档吧？

我们都很习惯于打开word，找一个模板，把一个项目的需求一条条写进去。不考虑需求分析者的经验、能力、热情和价值观，也不考虑这份文档能不能让小程序员或者白痴客户们看明白（这常常是比拿到公司股份还无稽的奢望），一个静态的、缺乏正确性和完整性校核、没有内容关系链接的文档，本身就很难描述清楚我们到底想要做什么。一个需求，可能带有多种的属性，单从一个角度来描述它已经很困难；要描述清楚多个功能之间的交互性，那就是更加困难的任务。对于我们的项目来说，更多的问题和精力，都花费在功能的通讯和交互上。在考虑到需求的变化性，使用静态的文档来描述不断变化的、多种属性和功能的功能点，并且在整个项目开发周期维护它，让它始终和当前的项目情况保持一致，根本是个不可能的任务。也许就是因为大家都清楚这一点，我们的需求文档才一直被人有意无意的遗忘在角落里......

如果我们使用的需求文档，能够更好的表现各个内容间的关系，能够易于找出关键路径上的需求，或是来自某个特定用例的需求，更进一步的，能清晰的表示出完成和未完的需求，以及集中于接口上的需求。这才能真正促进项目的运作。

听上去我们应该使用某种需求管理工具。嗯，我也这么想的。需求文档应该像软件产品一样，从一堆精确的、完备的描述中产生出来。如果你有好的需求管理工具，请一定要告诉我。