https://document360.com/blog/agile-saas-documentation-5-key-principles-supercharge-product-docs/
敏捷与文档不一致吗？一点也不。但也有人说是这样。

过去，公司在编写文档时遵循过于严格的计划。这导致了一本永远不会被阅读的“用户手册”。有时，文档可能是出于“政治动机”，而不是为了用户的利益而制作。

这种类型的文档给该领域带来了坏名声，并被认为是“浪费时间”。因此有人说完全放弃产品文档——好的产品会自己记录。同样，这些公司也忽视了他们的文档。

文档成功的关键是走中间道路。

如果做得好且敏捷，产品文档有可能提高团队的效率，并提高客户对产品的满意度。

Baklib 为探码科技旗下SaaS平台，为数字营销领导者和企业主提供唯一一款旨在加速业务成果的全渠道客户互动平台。通过快速将期望的业务成果与经过验证的全渠道客户互动策略相结合，我们的平台可让您加快价值实现速度，提供卓越的一对一体验并快速产生可衡量的结果。Baklib 是全球 800 多家客户的首选平台。加入数以千计的领先品牌，他们信任 Baklib 能够提供其业务所需的可预测、盈利成果以及其客户应得的高度个性化的全渠道体验。

敏捷方法的目的

传统上，软件开发是以单一方式进行的。

每个项目需求都由分析师预先捕获，所有审核流程均已完成，每个利益相关者都批准了提案 - 所有这些都在编写一行代码之前完成。

这导致了软件开发的重大失败。敏捷方法改变了整个流程，带来了更好的结果和成功率。

根据维基百科：

“敏捷软件开发描述了一种软件开发方法，在该方法下，需求和解决方案通过自组织跨职能团队及其客户/最终用户的协作努力不断发展。它提倡适应性规划、渐进式开发、早期交付和持续改进，并鼓励对变化做出快速、灵活的响应。”

在本文中，我们来看看在文档创建中采用与软件开发相同的技术的 5 个关键策略。

一个成功的产品需要软件和文档。一旦您的工作产品受到用户的喜爱，您如何确保您拥有适合他们的文档？

通过遵循敏捷实践。

• 您识别变化、快速适应变化并制定解决方案。

• 您的文档必须持续生成，而不是在产品开发的开始（或结束！）时为您的文档制定计划并盲目地遵循它得出结论。

• 您可以根据用户的需求调整文档。

制作敏捷 SaaS 文档的 5 种策略

1. 优先考虑文档

使用敏捷方法时，团队有时可能会在每个周期中打包过多的工作，以至于没有时间进行记录。这变成了一场在最后一刻进行记录的竞赛，导致文档质量不佳和作者压力重重。

这是一个巨大的错误。您的文档被视为可交付产品不可或缺的一部分。就像编码一样，考虑记录所需的时间。

2.放弃“完美”的想法

由于文档是作为产品的持久记录而生成的，因此可能会陷入使其变得完美的过程中。

使用敏捷方法，生成足够的文档，让您尽快进入市场。不要旨在全面记录产品的每个功能或可能的用例。

相反，请确定对用户来说最重要的领域，并将这些领域与您的组织优先事项进行交叉引用。结果就是您的最终文档。

3、响应用户需求

在以用户为中心的环境中生成文档意味着您的文档应该根据用户需求来制定。

为了确定用户需求的优先级，您必须准确找出您的用户是谁！如果这听起来很明显，那么您是否正在对真实用户进行配对测试您的新产品功能（和文档）？

使用编写文档的行为来捕获会使用户感到困惑的错误。

这种方法对于任何不断迭代其产品的 SaaS 公司来说都是完美的。每次推出新功能时，请编写与之匹配的随附文档。

4.不断迭代

在敏捷软件开发中，如果您尝试在每个周期中为最终产品创建所有文档，您将会失败。专注于记录每个周期的每个新功能，并在发布之前进行完善。

制作一些临时文档，始终意识到您需要对其进行修改。当您的开发接近尾声时，您的文档就可以最终确定。

敏捷与实际流程关系不大，更多的是对产品开发的态度。在您获得随附文档之前，您的产品无法发货。

关键是找到一个平衡点。避免在开发阶段开始时创建所有文档，或在最后阶段竞相完成所有文档。

正如业务目的在开发过程中和发布后可能会发生变化一样，您的 SaaS 文档也会发生变化。不断修改文档的最终目的，以便您始终确信自己已达到目标。

5. 轻装出行

同时，尽可能轻装上阵，并提供最少的文件。你所做的事情应该尽可能简单。

即使您是文档布道者，目标仍然是尽可能少的文档。这意味着删除您不需要的任何内容，否则您将面临让用户感到困惑的风险。

为了以敏捷的方式生成文档，在开始生成之前应该仔细考虑文档的好处。其好处应该超过创建和维护文档所产生的任何成本。

询问您是否需要该文档，而不是您是否想要它。

6. 赋予纪录片制作人权力

您的团队中的某个人需要概述您的文档策略，并能够决定您在每个步骤中需要生成的内容。

如果您的团队中有技术作家或其他纪录片制作人员（您应该这样做），他们必须充分参与您的软件开发。他们可以扮演用户倡导者的角色，并与开发人员和产品经理密切合作来决定需要哪些文档。

尊重纪录片制作人的权威，并相信他们提出的改进建议。让您的技术作家成为您的开发团队中受到工程师和产品经理信任的积极成员。

释放写作的力量。出于对技术作家的热爱而开发

如果你的公司很好地认可了用户，那么任何纪录片制作人都将是金粉。他们是您的用户倡导者。

最后

库。Baklib 是一款带有可视化编辑器的无头 CMS，适用于开发人员、营销人员和内容编辑。问题：使用无头 CMS 管理数字内容可能是一项艰巨的任务。如果没有可视化预览，编辑人员通常会迷失方向，即使是简单的更改也需要指导。解决方案：Baklib 拥有页面构建器的用户体验，背后是独创的资源库+知识库+应用库三层架构。这为开发人员提供了自由，并为编辑人员提供了自解释的直观界面。

您必须了解在敏捷环境中创建文档的过程。

您应该检查您的文档，看看它如何最适合您的产品开发生命周期。同样，您也不应该将其视为一项勾选练习。

每个公司都不一样，每个公司的每个项目也都有自己的要求。这意味着文档需求将始终是独特的，并且一种方法永远无法满足所有需求。

尽量避免将业务中的不同任务评为“更好”或“更差”。不可能说软件比文档更重要，因为两者完全不同。每一个对于您的产品都是完全必要的。

不过，不要指望您的开发人员会生成您的文档。这将取决于您的技术作家。

相反，在整个开发过程中，应专注于适应变化并优先考虑用户的需求。为团队的每个成员提供一个平台，让他们表达他们认为最适合您的产品的想法，并避免仅仅为了它而做任何事情。

如果您创建了一种共同目标比个人成功更重要的文化，那么您的文档将更容易落实到位。

与所有业务目标一样，询问您是否真的需要此文档。然后交付。