最近读到了一篇关于如何发现及修正“问题”文档的文章，很受启发。其实作为技术写作人员，工作中或多或少已经涉及到了本文提到的某些观点，所以本文仅仅只是结合我自身的工作经验，给大家做一个相对全面的总结。
在平时的工作中，我们常常接触的是每个发布周期需要发布的那些新功能，但除此之外，我们要如何发现那些老文档中的“问题”呢？
Reactionary Identification
单靠技术文档工程师一个人是难以发现隐藏的问题的，因此我们需要依靠其他角色的协助。
目标用户
通过搜集目标用户的反馈，我们可以了解目前文档中存在的问题，并进行有针对性的改进。如果反馈内容不是很具体很明确，需要跟相关的stakeholder进行深入的沟通以了解用户的痛点到底在哪里。
客户支持
通常来说，客户一旦有跟产品相关的疑问，首先会报ticket，接下来会由客户支持进行处理和跟进。客户支持是连接公司与客户的第一道桥梁，因此技术文档工程师需要与他们保持定期沟通，以了解下面的几个方面的问题：
- 客户在哪些方面经常碰到问题？
- 客户通常用哪些term去描述问题？
- 哪些文档是有用的？哪些已经过时了？
- 技术文档工程师可以做些什么让客户可以更轻松使用我们的产品并且提高客户满意度？
Proactive Identification
技术文档工程师主动邀请相关的stakeholder，定期review目前文档的整体结构和内容。基于技术文档质量标准，看下目前文档离“ideal”还有多远。IBM出版的“Developing Quality Technical Information”一书中，提到了quality technical documentation的三个标准：easy to find, easy to understand, and easy to use. 我觉得不妨可以从这三个标准去评估现有文档的质量。当然， 首先需要和所有stakeholder对文档要实现的目标达成一致。
总之，技术文档工程师需要积极地与客户支持和其他的stakeholder保持密切沟通，一方面可以在最大程度上及时发现“问题”文档，另一方面也可以逐步提高他们对于文档的重视程度，了解如何与技术文档工程师更好的合作。
发现了“问题”文档之后，如何来修正它呢？敬请期待“技术写作心得002”！
Source: Part 1: Identify and Fix Underperforming Documentation
