如果你有过 Technical Writer 实习或工作经历，那么对技术写作的流程应该已经了解。当然，在很多大公司里，你参与的很可能只是这个流程的某一个环节。例如，你只负责写，或者只负责 review，或者只负责文档架构。相比之下，在创业公司里，可能会参与多个环节。
如果你是尚未毕业而且也没有相关实习经历的在校生，或者已经工作但有意转行做 Technical Writer 的小伙伴，那么可能对技术写作流程仍存疑惑，或者一知半解。
不同公司技术文档流程的划分可能略有差异，但从本质上来看，则大同小异。无论你在这个流程中的哪个环节，从宏观上了解整个流程有助于让你的认识更加清晰，也有助于在有需求时从容地承担其它环节的工作。
这里跟大家分享一个完整的技术文档写作流程，你只需记住六个单词即可。如下图所示：
再说明一下，你从工作中已经了解或即将接触的技术写作流程不一定与上图完全一致，但一个完整的流程一般都会涵盖这些内容，区别多半是主观划分而已，这一点不必拿出“大家来找茬”的精神死磕哦~
准备阶段的工作主要包括以下几点：
在写文档之前，需要明确文档需求。你要了解为什么要写这篇文档，写这篇文档是为了达到什么目的。
也要明确文档受众。受众不同，内容就很可能不同。比如，面向开发人员和非开发人员/普通用户的文档，在内容的组织上就会不同。
还要界定文档范围。思考并确定这篇文档需要覆盖哪些内容或模块，以及不会涉及哪些内容。这样在之后搜集资料的时候就会有所侧重，写的时候也不会模糊不定。
有过技术文档写作经历的小伙伴一定会深有同感，如果不理解某个东西，那么给它写文档简直太痛苦。
那么当遇到一个让你毫无头绪的陌生主题时，该如何尽量避免这种痛苦呢？当然就是尽最大可能去理解了。
可是具体该如何做呢？简言之，即搜集资料。那又该如何搜集资料呢？笔者认为，可以从以下几点着手：
1）对比较有代表性的同类产品或相似产品的相关文档进行调研，看看别人的文档是怎么做的。
在一无所知的时候，借鉴他人的经验做法不失为一种好的选择。通过对几家产品的文档进行对比，你就可以对自己要写的文档建立一个大致的框架。
需要注意的是，借鉴不是照搬，只用于提供思路；产品不同，文档的结构规划也会有差异。
2）采用最有效的方法尽力搜集与所写文档相关的各种资料。
搜集的资料经过 Technical Writer 的摘删组织，很可能就会成为发布文档的一部分。
搜集资料的方法有很多，像网络搜索、调查问卷、访谈、实验，以及邮件讨论、报告、技术文章等等。到底该使用哪种方法要具体分析，需要你根据文档需求、Deadline、已有资料的丰富程度等因素，来选择能快速而准确地搜集到所需资料的方法。
有些主题的写作，通过网络搜索可能几乎无法给你提供任何帮助。即便是这类内容，你也可以从开发人员那里获得一些资料，可以根据自己的需求请他们协助提供资料，抑或是通过内部系统中的开发说明和讨论获取所需信息。
对于软件类的产品文档，即便有了一些技术资料，也往往需要 Technical Writer 自己使用一遍，从而对操作步骤有一个直观的理解，获得文档写作的一手资料。
当资料搜集得差不多的时候就可以组织这篇文档的具体结构了，之前对相似产品的调研或许可以在此时助你一臂之力。
对于常见的产品使用指南，一般按照安装或使用的顺序进行组织；对于其它一些非指南类的文档，也应遵循一定的顺序或逻辑。
此外，还需考虑该文档是否需要配图，是否需要使用表格。如果需要配图，明确是需要他人协助提供，还是需要自己完成。画一个较复杂的图也是一件蛮耗时的事情，花费的时间也需考虑在内。
有了详细的文档架构之后，就可以进行下一步的写作了。
如果做好了前几步的工作，写作将变得非常简单，你只需把相应的内容准确地填到文档架构中。在这个过程中，你需要写一个个段落或者具体的操作步骤。这是一个反映你的语言和写作功底的时刻。
有的 Technical Writing 书籍中说到，在写文档的时候不必在意语法、措辞和标点，认为这些细节应该在 Revision 阶段完善。
我对此有不同的看法。一个合格的 Technical Writer 本身应该有良好的语言功底，像语法、措辞和标点这种最基础的细节本就不该成为一个需要单独解决的问题。规范的语法、得体的措辞、正确的标点应该已经成为一种不需要额外付出精力、也几乎不会占用额外时间的写作习惯。
如果写作的初稿比较粗糙，有许多需要修改的小细节，这必定会增大 review 时的工作量和时间成本，从而延缓文档流程。
或许，对于有精细化分工、每个人只负责一个小环节的大企业，可以采用这种方法。但是，对于快速发展、需要文档敏捷开发的创业公司，这种就不适用了。
写完文档第一稿后，一般都需要进一步修改完善。这里的 Revision 指的是 review 之后的修改，所以这一步也可以叫作： Review & Revision 。
那么需要谁来 review 呢？技术文档通常需要请其他小伙伴进行两种 review，即：
收到 reviewer 的反馈之后，Technical Writer 需要及时作出判断和修改，有不明确的地方需和 reviewer 讨论确定。改完之后，再请 reviewer 看一下。如果又发现了新的问题，那么还需要再次修改。这个 review - revise 的过程可能会反复几次，很正常。
当然，在请他人 review 之前，Technical Writer 也可以先自己 review 一遍，尽量避免低级错误，不浪费他人的时间。
哈哈，问题又来了~通常，刚写完一篇文章的人是很不情愿再去看自己写的东西的，此时就可以使用一些语法拼写检查的小工具来协助你了。
我在之前的一篇文章 Technical Writer 日常工作中好用的小工具 中有推荐，有需要的小伙伴可以戳链接去瞅瞅~
如果你觉得自己足够细心，根本不需要小工具来协助你，我佩服你的能力，但还是建议用一下小工具。因为，你可能也会有状态不好的时候，有疲劳打盹的时候，有不知道自己写了一堆什么鬼东西的时候……不要跟自己和小工具过不去。
等文档定稿之后，就可以在平台上发布了，一般很容易操作。不同的公司的文档发布平台也会不一样，Technical Writer 使用的写作工具也不一样。
文档发布之后，并不代表着结束。根据我的工作经历，即便是已经发布的文档，也依然有可能存在问题，无论是大公司还是小公司的文档。例如：未发现的文字错误、失效的链接、与最新的产品已不匹配的描述和步骤等。Technical Writer 需要及时跟进产品动态，以便及时更新文档。
写技术文档不是一劳永逸的，只要产品在更新，就需要 Technical Writer 一直维护下去。
以上分享的是一个完整的技术文档从零到有的过程。日常工作中，有时不需要从头开始，而只是对原有文档的增删修改，那就可以省去一些相应的环节。
如果你也是一枚 Technical Writer，也期待听到你对技术写作流程的见解，欢迎留言交流哦~
Reference:
你可能想读 ：
Technical Writer 日常工作中好用的小工具 技术翻译需要有 Technical Writer 的 sense 深度解析关于技术翻译的六个认知误区 如何让你的内容输出更加专业更有设计感？ 书单 | 有哪些技术传播从业者必知必看的书籍？ 有哪些适合技术传播从业者关注的优质博客？（一） 有哪些适合技术传播从业者关注的优质博客？（二） 经验分享 | 来自 11 位 Technical Writer 前辈的职业发展建议（上篇） 经验分享 | 来自 11 位 Technical Writer 前辈的职业发展建议（下篇） 英语技术文档的标题到底该大写还是小写？ 如何使用正则表达式批量添加和删除字符？ Markdown：写技术文档、个人博客和读书笔记都很好用的轻量级标记语言 如何为 Markdown 文件自动生成目录？ 技术写作实例解析 | 简洁即是美 两分钟趣味解读 Technical Writer 若脱离理解，直译得再正确又有何意？ 优质译文不应止于正确，还要 Well-Organized 写在入职技术型创业公司 PingCAP 一个月之后 揭秘 Technical Writer 的工作环境 | 加入 PingCAP 五个月的员工体验记
-END-