本文适合软件即服务 (SaaS) 行业的文档工程师阅读，原创来自美国云数据平台 Snowflake 文档工程师 Sarah Moir 博客。
如果您正在为不断发布的软件即服务 (SaaS) 产品编写文档，那么很容易被需要记录的大量新功能所淹没。但是您真的需要记录所有这些吗？答案是“不”。
相反，文档工程师该去归档隐藏的、归档奇怪的，去归档原因。
考虑用户关心的每一个新产品的功能。
不要去归档产品可以做什么——归档用户想要做什么。建议在您的文档中采用极简主义，尤其是当您试图跟上 SaaS 产品的快节奏发布周期时。
Sarah Moir 使用一系列问题来保持文档最小化并集中在文档工作。
归档功能查看功能时，请考虑以下事项：
- 什么可能使某人对此感到困惑？
- 他们需要帮助解决什么问题？
- 与可能需要塑造心智模型的现有产品体验有何不同？
- 这些更改在客户工作流程中的什么位置？
- 可以通过哪些方式改进该功能以使其更清晰或更易于使用（无需文档）？
使用您作为用户倡导者的角色来推动产品改进通常很有帮助，而不是围绕用户体验问题进行记录。
审核文档反馈在查看来自客户或现场的文档反馈时，请考虑以下事项：
- 是不是不止一个人糊涂了？
- 这个反馈是否与一个特定的边缘案例有关？
- 这是一个实际的错误吗？追踪需要多少时间？
- 是什么导致某人感到困惑？他们的个人心智模式不同吗？
- 它实际上是否对产品的工作方式感到困惑，并且不一定是文档任务？
尝试了解反馈的根源。与其放弃并添加关于任何事情的快速注释，不如考虑对文档或产品进行哪些改进以解决核心问题。
归档奇怪的行为该审查来自 PM 或工程的请求以记录奇怪的事情时，请考虑以下事项：
- 这个有时间限制吗？
- 这种行为是否只在某个时间点才会成立？
- 这个功能有限制吗？
- 这种行为是否只有在某个功能被重构/改进/增强之前才会发生？
- 这项工作的范围和计划是否很快？
- 这实际上是一个应该在发行说明中而不是其他地方的错误吗？
- 有多少人受到了奇怪的事情的影响？
- 在实际客户环境中发生的奇怪事情有多普遍或有可能发生？
看起来我在告诉你要找到很多避免编写文档的理由。重要的是要关注客户将要查找的文档，而不是确保归档整个产品功能。
假设您的产品要求人们在开始使用之前确认他们的电子邮件地址。
客户会阅读有关如何确认其电子邮件地址的文档吗？不。
您是否需要编写有关如何确认电子邮件地址的文档？也没有。
如果您对您的用户及其心智模型有深入的了解，您可以对产品中其他更复杂的工作流程做出同样的决定。
停止尝试机械跟上产品的步伐，让我们去开始帮助使用产品的人。
,
