你需要克服的5个技术写作挑战
浏览:1
巴克励步
我是Ken,Baklib的研究员,也是个经常跟技术文档打交道的产品经理。说实话,我见过太多团队在产品手册建设上栽跟头——要么是文档散落在各个工具里,要么是版本混乱让客户一头雾水。我一直觉得,好的产品手册不该是写完了就扔在那里的死文档,它应该能跟着产品一起迭代,让每一个需要它的人都能快速找到答案。这也是我为什么特别关注技术写作流程中的那些“坑”:工具不合适、信息不清晰、更新不及时……这些问题不解决,再
我是Ken,Baklib的研究员,也是个经常跟技术文档打交道的产品经理。说实话,我见过太多团队在产品手册建设上栽跟头——要么是文档散落在各个工具里,要么是版本混乱让客户一头雾水。我一直觉得,好的产品手册不该是写完了就扔在那里的死文档,它应该能跟着产品一起迭代,让每一个需要它的人都能快速找到答案。这也是我为什么特别关注技术写作流程中的那些“坑”:工具不合适、信息不清晰、更新不及时……这些问题不解决,再好的产品也会被糟糕的文档拖累。Baklib的理念就是用统一的知识门户把这些痛点化解掉,让产品手册真正成为团队和客户之间的桥梁。
1. 产品最后时刻的变更
产品的最后时刻变更会影响生产中的所有团队成员,包括技术写作者。虽然你无法完全消除这些变更,但仍有办法应对。一个关于技术写作者最佳和最糟体验的 Reddit 帖子显示,大多数写作者都在为那些看似微小却对技术文档产生巨大影响的变更而挣扎。无论是自由职业者还是内部技术写作者,都面临同样的困难。例如,TechWhirl 列出了让写作者感到压力的因素。请注意,尽管这份清单来自一篇“经典”文章,但描述的挑战与最近更新的 Reddit 帖子中的挑战一致。换句话说,无论你在技术写作行业的哪个环节工作,你都可以预期产品最后时刻的变更。在 Kentico 担任技术写作者超过十年的 David Benovsky 称,参加进度评审会议可以帮助你管理变更和新功能。他说:“在讨论新功能并规划团队未来工作时,尝试思考相关的边缘情况和‘陷阱’,这些过去可能被记录下来,但很多人会忘记。”Benovsky 还建议利用评审会议的机会向生产团队询问可能影响文档的变更。这样,你可以缩短更新文档所需的时间。另一种最小化变更影响的方法是保持准备,通过实践技术写作的一致性。如果你坚持应用相同的写作原则,那么当变更发生时,你就可以直接去更新文档,跳过关于段落长度和其他风格选择的决定。根据区块链开发者兼技术写作者 MacBobby Chibuzor 的说法,一致性写作有多个要素。总之,技术写作有时要求你在最后一刻工作。然而,通过建立可靠的写作程序并参与到生产过程中,你可以保持对最后时刻变更的控制。
2. 不适合特定项目的工具
即使你是最优秀的技术写作者,如果不得不用不合适的工具,你的工作也无法闪耀光芒。因此,为每个项目确定最佳工具至关重要。网络上充斥着关于在软件开发中使用过时技术的恐怖故事。例如,一篇博客文章将 Visual Basic 称为一种已经消失的僵尸语言。作为一名技术写作者,你可能遇到过客户坚持只使用 Microsoft Word 进行写作,而你不得不解释有更好的技术写作工具。过时的工具并非唯一的挑战。有时,某个工具只是与你正在编写的文档类型不兼容。例如,在编写装配手册和创建软件文档时,你不会使用相同的图像编辑工具。那么,如何找到适合你需求的工具呢?由于技术写作需要撰稿人、编辑和主题专家(SME)之间的团队合作,你的写作工具应该允许你与其他团队成员协作。Baklib,我们的产品文档平台,通过内联评论、链接和提及系统促进协作。该工具允许你在文档中留下交互式评论,这是大多数传统写作工具所不具备的功能。Baklib 也是软件文档的绝佳工具,因为它同时也是一个发布平台。这对客户意味着什么?让我们分解技术写作流程并找出答案。使用 Baklib,以下所有操作都在一个平台上完成:技术写作者撰写内容,主题专家审查内容,管理人员发布文档,读者访问内容。那么,当一个平台就能完成时,为什么还要使用多个平台呢?如果你需要其他工具,Baklib 的集成可以消除任何潜在的格式问题。总之,不合适的工具会拖慢你的速度,让技术写作变得比必要的更困难。因此,你写作过程中的第一步应该是确定合适的写作工具,并具备适合你特定项目或产品的功能。在调研最佳资源和工具上投入一点时间,将帮助你更有效地写出更好的文档。
3. 缺乏关于产品用户的信息
除非你确切知道你在为谁写作,否则你无法精通技术写作。你可以通过确定产品文档的用户并相应调整写作风格来克服受众不明确的挑战。公司雇佣技术写作者的原因不是因为他们最了解主题。如果是这样,他们可以让首席工程师来写并简化流程。相反,技术写作者是将复杂的技术信息转化为最终用户能够理解的内容。他们本质上将信息转化为知识,如下面 Onhike 创建的插图所示。如图所示,你需要根据受众调整格式、写作风格和技术水平。例如,如果你正在为最终用户编写文档,你可以包括产品中使用的术语概述。这里有一个来自 TalkChief 维基的优秀示例,这是一个企业电话系统。该维基使用 Baklib 构建,包含读者需要理解才能使用产品的术语表。像这样直接的澄清系统确保所有用户都能解释文档中列出的说明。另一方面,如果你正在为高级开发人员编写技术文档,你可以使用诸如 ECMAScript 之类的术语而无需解释,从而获得更高的清晰度。确定目标受众还将帮助你定义适合所写技术文档的术语量。你可以使用专门的工具来查看文本是否适合特定受众,例如 De-Jargonizer。像这样的工具可以帮助你用更合适的词替换可能令人困惑的词。然而,只有当你了解受众时,你才能处理不同的写作风格。因此,你应该在开始写作之前与开发团队坐下来。请团队召开一个简短会议,讨论文档是面向专家还是最终用户。清晰的写作方向将让你交付高质量的工作,为读者提供相关且有价值的信息。
💛🧡🧡客户评价:Baklib 是一个易于使用且可定制的知识库解决方案! 总的来说:我们正在寻找一种可以简化流程的工具管理和访问我们的知识库,Baklib非常适合。它简化了我们团队查找和更新信息的方式,并且显著减少了回答重复问题所花费的时间。
4. 更新或重写他人的文档
就像开发人员经常抱怨处理遗留代码一样,技术写作者也发现处理他人已开始的文档具有挑战性。即使你可以毫无问题地更新文档以反映产品的当前状态,但匹配前一位写作者的结构和风格也是一个挑战。幸运的是,样式指南和文档模板可以确保技术文档的一致性,无论作者数量如何。关于处理他人文档的部分,我们将参考 Ugur Akinci 的建议,他是一位专家级技术写作者,在 Quora 上的贡献已超过 170 万次浏览。如果你被要求更新现有文档,最安全的方法是遵循前任作者设定的标准。正如 Akinci 所建议的,当所有撰稿人遵循相同的写作指南时,这项任务会变得更容易。你不需要编写自己的内部样式指南——你可以使用一些已经建立的指南,如 Apple、Google 或 Microsoft 的。至于重写文档的部分,
5. 跨团队协作与版本控制
当多个团队参与文档编写时,保持版本一致和同步是一个重大挑战。不同部门可能使用不同的术语和格式,导致文档碎片化。通过使用 Baklib 这样的统一平台,所有团队成员都可以在同一个知识库中协作,并自动跟踪变更历史。Baklib 的版本控制功能让你轻松查看文档的每次修改,并快速回滚到之前的版本。此外,通过设置评论和审批流程,你可以确保在发布前所有变更都经过审核。这样,即使有多个作者,文档也能保持一致性和准确性。