在软件开发领域，文档管理是一个至关重要的环节，但往往被忽视。据估计，超过50%的项目问题可以追溯到糟糕的文档管理工具。本文将讨论软件项目文档管理工具的现状，并提出一些改进的概念和建议。
目前，95%的软件项目使用Microsoft Word进行文档管理，有时辅以SharePoint。但这种系统存在许多问题：
- 速度慢
- 难以追踪变更内容、变更者和变更时间
- 难以比较当前版本与旧版本
- 难以将文档的某些部分作为硬性要求与背景信息区分开来
- 粒度太大，无法对单个需求进行版本控制
- 难以处理单个主题、章节或分支
- 难以通过电子邮件发送文档的一部分或几部分
- 难以登录后快速了解自上次登录以来的变更
- 难以了解哪些内容已审阅，哪些尚未审阅
- 在编码时难以标记已完成和未完成的需求
- 无法将代码与需求关联提交
- 创建新的小型文档耗时过长
- 多人协作编辑单一文档困难重重
- 文档中的元素（如需求、用户故事、用例、实现细节等）作为具有生命周期和工作流的实体的概念是不存在的，也无法创建
这只是其中的一部分问题，而且这些问题的列举仅用了大约5分钟。相信在完成这篇博客之前，还会想到更多的问题。现在想象一下，如果像编写文档一样编写代码，把所有的代码都写在五六个巨大的文档中，并将其放在一个大型的SharePoint站点上。不需要详细说明问题，因为这种方式的工作方式显然是完全荒谬和不可行的。这将导致噩梦、故障和对流程问题的无尽分析。这将催生无数的专家，他们的工作是进来告诉工具是次要的，问题不在于工具，而在于流程。需要更好的沟通。需要更频繁的会议。或者也许专家们会告诉，需要更正式的代码签收方法，因为显然不能在代码编写后不经过变更单就更改代码。
听起来很熟悉吗？是的，这就是多年来对文档的看法。但说这是一堆废话，说现在是那些编写文档管理工具的人开始觉醒，为提供真正有效的工具的时候了。
虽然不敢说有所有的答案，但以下是一些立即想到的，软件项目文档管理工具应该能够做到的事情：
- 允许用户以类似于Microsoft Word的方式进行编辑，并创建看起来类似于Microsoft Word的文档。不要让用户学习全新的写作方式。这就是为什么人们不断回到Word的原因，因为文档工具的开发者一直在违反这个最基本的原则。
- 在用户编写时，逐主题、逐段落地跟踪正在编写的内容，并在这些级别上进行版本控制。
- 使用户能够在不到三秒钟的时间内创建新文档。
- 使创建许多小型文档和创建少数大型文档一样容易。
- 将项目文档制作成嵌套树，其中所有小型文档都可以作为大型树的一部分集中找到。
- 使用户能够轻松地创建新页面并开始输入新文档。用户开始输入新想法的时间应该大约是2秒钟。
- 允许用户轻松地在主题和段落的基础上重新排列文档。让可以移动段落上下、缩进等。
- 允许用户查看自上次登录以来所有其他作者所做的所有更改的列表，并在单一的中央列表中显示。如果用户点击列表中的一个项目，他将立即被带到文档工具中更改发生的地方，并且显示更改段落旁边的上一版本段落，更改的文本将被高亮显示。
- 当用户审查更改时，跟踪哪些已审查，哪些未审查。每个用户都应该能够立即知道其他人所做的哪些更改他尚未审查。任何做出更改的人都应该能够立即知道谁已经审查了这些更改，谁还没有。
- 允许用户快速轻松地从普通文本更改文档段落样式为项目符号、编号、标题1和标题2，使用快速按键，如Alt-L、Alt-N等，以及具有相同功能的简单按钮行。不要创建比绝对必要的更多的样式。不要让用户考虑如何应用样式。不要让用户想知道如何进行缩进列表编号。
- 拥有一个包含项目所有文档的主文档树。在该树上进行即时搜索。输入一个字母或短语，树就会立即压缩以反映搜索，就像Outlook最终在经过多年的粗糙、缓慢和几乎无用的电子邮件搜索后的工作方式一样。
- 能够将文档节点附加到许多类型的项目工件上，并让系统智能地意识到正在附加的文档节点的类型，并将节点放置在主树上。例如，BA创建了一个用户故事。很好。现在BA想要将故事分解成更多的细节，比如可能的用例、更详细的要求，以及可能的实现建议。BA只需点击用户故事下方，就会出现一个新的文档窗口，准备在左侧创建主题并在右侧输入细节。可能会出现一个模板。BA输入一些细节并保存。稍后，在主文档树的“用户故事”部分，该文档节点及其细节将出现。但同时，BA输入的实现细节将出现在主文档的“实现”部分。BA输入的用例将出现在“用例”部分。
- 允许任何段落被标记为硬性要求。只需点击一个按钮或快捷键，字体就会改变，旁边就会出现一个图标，现在很清楚这件事必须完成。
- 现在所有硬性要求都应该能够轻松地作为一个列表查看。
- 当开发人员完成一个需求时，允许代码针对该需求进行检查。或者允许该需求像用户故事一样被扩展。只需点击需求并编写一些任务、实现细节等。现在开发人员可以针对各个任务进行检查。
- 能够立即显示哪些需求已经实现，哪些尚未实现。
- 能够显示任何段落的版本历史。
- 能够显示整个文档的任何先前版本。例如，让看看一个月前的文档是什么样子。是的，它在那里。那时有112个需求。现在有134个。让看看它们在哪里：点击，点击，点击。让看看谁写的。是的，那是客户，那是开发人员，那是BA。让看看上个月有哪些变化。好的点击，点击，点击。那太多了。让只看需求的变化。好的。点击，点击。
- 能够将文档的任何部分导出为模板。
- 将文档附加到项目上，并像源代码一样进行备份和恢复。如果用户切换项目，他也切换文档。
- 随着时间的推移，开始构建文档静态分析工具，检查文档是否存在明显缺陷，并提出更好的方法。
- 随着时间的推移，开始构建工作流功能，认识到文档元素（段落）作为具有自己生命周期的实体的重要性。
这些功能中的大多数今天可以用源代码完成。发现不能对文档做同样的事情是完全不可接受的。