像很多同行一样，我理解软件文档的价值。不幸的是，在开始一项任务之前我却很少阅读软件文档。相反，我通常会模仿目光短浅的父母，他们在组装好孩子的自行车时，总会多出一些零件来。
如果我们知道软件文档的价值，那么为什么不经常使用它呢？对于新手，大多数软件文档都存在很多下面提到的这些问题：
• 糟糕的语法和/或拼写错误的词语

• 不完整

• 过期或不准确

• 篇幅太长

• 首字母缩写没有解释或术语不专业

• 难于找到信息或在文档中定位
存在这些问题的主要原因是软件文档通常没有被给予足够的重视。项目预算被迫将主要活动花在了开发工作上，在那里管理层很容易看到他们的收益。值得投入成本的文档工作通常都是主观的，而且通常被刻画为需要避免的成本，因为它们被认为不能产生投资回报（ROI）。很多项目经理将客户所需要的最少文档看作是“镀金”。
软件文档的另外一个麻烦来源是文档的作者。很多应用程序开发经理觉得软件文档是开发工作的一个标准部分，因此，要求他们的开发人员在编码时也编写软件文档。
虽然这在理论上是说得过去的，但是不应该将开发人员看成文档作者。很简单，技术人员只被培训如何开发，而没有被培训如何写文档。为了解决这一问题，很多应用程序开发经理尝试通过聘请一些技术性写手或商业分析人员来提高他们的软件文档的质量。这就导致出现了一个相反的问题：技术写手和商业分析人员通常只有有限的技术技能。
解决方案依赖于文档，文档应该迎合其潜在读者的口味。这方面的通用规则是要求使用一个协同工作方法来编写文档，这种方法允许开发人员和写手发挥他们的长处。例如，如果潜在的读者是系统设计人员，那么开发人员应该提供详细的输入，但是允许技术写手去组织和编辑内容以使文档符合语法。
不管潜在的读者还是被选中的读者，软件文档的质量与其可使用性相关，以下六个属性可以用来测量软件文档的可使用性：

• 适用性：文档提供了相关的信息吗？

• 合时性：文档所提供的是当时的信息吗？

• 正确性：文档所提供的信息正确吗？

• 完整性：文档是不是足够详细？

• 可用性：文档随手可用吗？

• 可使用性：能够快速直观地找到所需的信息吗？
软件文档的首要目标是表达系统的技术元素和用法。软件文档的次要目标是提供一项开发工作的需求、决策、动作、角色和责任的书面记录。只有在你意识到这两个目标时，你的文档才能提供有意义的信息