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