|
经常听到有人说,TW(Technical Writer,技术文档工程师)就是写写文档,原样照抄研发工程师的文档内容,排排版就好了。这是Technical writing吗?当然不是!真正的技术写作除了写作本身之外,还包括协调开发人员收集资料,安排文档开发计划,文档架构设计,写作风格的控制,绘制辅助文字的图形图表,编写不同用户在不同场景下使用的各类产品文档,并保证与产品同步发布文档等。其实技术写作是对综合素质要求很高的一个职业,可不是随随便便谁都可以做的。
生活中我就曾经历过以下对话:
问:“你是做什么的?”
答:“文档工程师。”
问:“就是文职工作,类似于文员吧?”
答:“哦,不是,写技术文档的,就是类似于写产品说明书,什么安装手册,操作手册什么的……”
问:“哦,明白了,就是写说明书的。”
经历过以上对话后,再有人问我从事什么职业,我就回答:“技术文档工程师,类似于写说明书的。”
作为一名TW,没让家人真正了解这个职业,自认为有点失职。☺
有一天与妹妹聊天,谈到工作压力。妹妹说:“你还好啦,不像研发工程师压力那么大,你们就写写文档,多轻松啊!”
我笑着说:“是吗?其实不同的职业有其不同的压力所在,我们虽然不像研发人员那样整天写代码、编程序、Debug,但我们也不轻松啊。”
我写过很多不同类型的产品手册。深知要想写好一个产品手册,必须做很多事情,有些甚至是别人根本看不到的,而且在产品手册中也不一定完全体现出来。
TW开发一个产品手册,需要经历不同的阶段。
计划阶段
根据研发产品项目的需求,制订产品手册开发计划及相关知识的学习计划。
在写产品手册之前,必须了解并理解产品的各个性能及相关的技术原理。有相关的技术背景会好点,没有相关的技术背景就得自己学习,查找资料,请教工程师。在这个学习的过程中,如果时间紧,项目上根本不会安排时间让TW学技术,TW必须自己找时间学。所以,技术写作人员要有超强的学习能力。
开发阶段
在写产品手册的时候,必须站在用户的角度考虑问题,发现有与用户行为习惯不符,就必须马上与相关人员沟通并修正手册内容。
在写产品手册的过程中,因项目需求不一样,有时在不同阶段会承担不同的角色:
✓ 有时承担项目协调人的角色。研发人员做的解决方案,测试来不及测,而项目经理又要按时发布文档,于是TW就把相关的研发人员、测试人员及项目经理召集起来一起开会讨论并给出文档的最终解决方案;
✓ 有时承担测试人员的角色。自己测试产品的性能,自己动手操作产品并了解产品,甚至发现产品的问题;
✓ 有时承担技术支持的角色。有些研发人员对自己所负责的细节很清楚,但在自己负责范围之外的,就不是很清楚,当他看产品文档看不明白的时候,需要给他作相应的解释。
从某种角度上说,一名优秀的技术文档工程师应该是对产品最了解的人。
评审阶段
当产品手册写完后,要提交给相关人员评审,组织相应的评审会议,回答每一个人的疑问,澄清每一个疑点。直到文档内容达到清晰,准确和完整才算完成。
发布阶段
产品手册评审校对完毕后,要按照需要的格式发布到指定的平台。供内部和外部用户查阅。
维护阶段
产品手册发布后,若涉及到产品升级或方案的变更,就要对相应的产品手册内容进行更新,如果产品发现明显缺陷或者有内容可能造成用户的误操作,产品手册一定要及时修改并尽快把新版本的手册尽快发布到用户手中。
业内有这样一种对技术写作的精确描述:“文档工程师是一名系统工程师,虽然你不需要深入研究产品的每个技术细节,但你必须清楚了解产品的相关功能和特点及用户使用层面的相关技巧等。你不需要会写源代码,但有些基本的编程常识,你必须清楚。总而言之,你要成为第一个熟练使用产品的用户,否则你是无法写出让用户理解的文档的。”
有人说技术文档工程师英文用Technical Communicator比Technical Writer更贴切。也不无道理,在开发一个产品手册的过程中,文档工程师大部分时间其实是用在与产品相关人员沟通交流并充分学习了解产品本身,只有少部分时间(大约20-30%左右)是在撰写文档内容,这就是说仅仅会写是远远不够的。
以上是一名TW根据自己的工作经历对TW这个职业的一点总结,也许并不全面,但希望本文可以帮助你的家人或朋友了解并支持我们的职业。欢迎指正批评。
|
|