如何编写面向受众的网站文档？

一个组织不可能只有高级软件工程师或体系管理员，所以，只有基于特定规范的文档就意味着只有高级技术人员才能阅读这些文档。这是一种机能停滞问题。当然，这些文档也是必要和紧张的，这已经比只有阅读代码才能了解应用程序的情况好许多了。然而，这并不是一种完备的文档战略与文化。


解决方式:编写面向受众的文档
 
如何解读一种特定类型的文档取决于个人在组织中的位置。例如，对于体系管理员而言，API参考文档毫无用处，对高级体系管理员也样。他们不可能花时间去阅读API参考文档，更不用说让他们诠释或使用API参考文档去改进运维过程了。体系管理员必须要的是面向体系管理员环境编写的文档。这种文档自己可能会包含许多来自API参考文档的信息，但是这个文档不应该只罗列函数，还应该包含其他一些信息，如API可以支撑多少个请求，它使用什么网络协议，以及它依靠哪些软件，等等。这样才能帮助体系管理员理解如何部署应用程序，从而知道应在服务器环境中部署哪些组件。在这种情况下，我们会先从API参考文档开始，然后给出面向两种读者的两个详细的API实现文档:运维指南和开发指南。
 
编写面向不同受众的完备文档集，让文档成为一个团队文化的鲜活部分。肯定要理解必须要使用文档的受众，如营业用户、体系管理员、数据库管理员、软件开发人员、网络工程师、项目经理，等等。对于营业用户而言，或许API规范必须要考虑所支撑的每种应用的开销成本；而对于网络工程师来说，则可能必须要说明应用程序使用了哪些协议。应该编写哪一种文档，并没有一种固定模式，而完全取决于营业及团队的必须要。
 
益处:强化不同团队之间的纽带
 
面向不同受众编写文档，其效果必然能够优化人们对于营业双方的理解，削减误解和错误，并且削减双方的压力。而且，我们可以在一个文档的基础上编写另一个文档。例如，在了解网站建设应用程序及运维基础架构(服务器、网络设备等)的功能与限定之后，我们就可以在维护、功能规划成本及可扩展性指标上使用这些信息。假如一个文档可以利用另一个文档，那么编写文档的时间就会大大削减。这种方法不肯定适用于所有情况，但是许多时候都是这样的。