saas配置合同模板 编写SaaS文档的技巧

本文适合软件即服务 (SaaS) 行业的文档工程师阅读，原创来自美国云数据平台 Snowflake 文档工程师 Sarah Moir 博客。

如果您正在为不断发布的软件即服务 (SaaS) 产品编写文档，那么很容易被需要记录的大量新功能所淹没。但是您真的需要记录所有这些吗？答案是“不”。

相反，文档工程师该去归档隐藏的、归档奇怪的，去归档原因。

考虑用户关心的每一个新产品的功能。

不要去归档产品可以做什么——归档用户想要做什么。建议在您的文档中采用极简主义，尤其是当您试图跟上 SaaS 产品的快节奏发布周期时。

Sarah Moir 使用一系列问题来保持文档最小化并集中在文档工作。

查看功能时，请考虑以下事项：

• 什么可能使某人对此感到困惑？
• 他们需要帮助解决什么问题？
• 与可能需要塑造心智模型的现有产品体验有何不同？
• 这些更改在客户工作流程中的什么位置？
• 可以通过哪些方式改进该功能以使其更清晰或更易于使用（无需文档）？

使用您作为用户倡导者的角色来推动产品改进通常很有帮助，而不是围绕用户体验问题进行记录。

在查看来自客户或现场的文档反馈时，请考虑以下事项：

• 是不是不止一个人糊涂了？
• 这个反馈是否与一个特定的边缘案例有关？
• 这是一个实际的错误吗？追踪需要多少时间？
• 是什么导致某人感到困惑？他们的个人心智模式不同吗？
• 它实际上是否对产品的工作方式感到困惑，并且不一定是文档任务？

尝试了解反馈的根源。与其放弃并添加关于任何事情的快速注释，不如考虑对文档或产品进行哪些改进以解决核心问题。

该审查来自 PM 或工程的请求以记录奇怪的事情时，请考虑以下事项：

• 这个有时间限制吗？
• 这种行为是否只在某个时间点才会成立？
• 这个功能有限制吗？
• 这种行为是否只有在某个功能被重构/改进/增强之前才会发生？
• 这项工作的范围和计划是否很快？
• 这实际上是一个应该在发行说明中而不是其他地方的错误吗？
• 有多少人受到了奇怪的事情的影响？
• 在实际客户环境中发生的奇怪事情有多普遍或有可能发生？

看起来我在告诉你要找到很多避免编写文档的理由。重要的是要关注客户将要查找的文档，而不是确保归档整个产品功能。

假设您的产品要求人们在开始使用之前确认他们的电子邮件地址。

客户会阅读有关如何确认其电子邮件地址的文档吗？不。

您是否需要编写有关如何确认电子邮件地址的文档？也没有。

如果您对您的用户及其心智模型有深入的了解，您可以对产品中其他更复杂的工作流程做出同样的决定。

停止尝试机械跟上产品的步伐，让我们去开始帮助使用产品的人。