技术文档写作的职业探讨

转自 http://blog.csdn.net/u014309159/article/details/44904425

原文链接：http://blog.tianya.cn/blogger/post_read.asp?BlogID=423614&PostID=24868550 

  外面的人通常不知道技术文档写作这个职业是做什么的. 这个职业究竟参与了哪些工作? 这个行业是什么样子的?对于一个技术文档作者来说,他的职业前景如何? 会面临什么样的挑战? 
　　
　　　　这里有8个问题,我对此一一作答,作为我关于技术文档写作这个职业的一个探讨. 欢迎感兴趣的人士对我的回答做补充. 与技术文档写作工作相关的问题 作为一个技术文档作者,你最喜欢这个职位哪一点? 
　　
　　　　我最喜欢的是技术与写作的结合. 我热爱写作,曾梦想成为一名小说作家,现实中的我在毕业后成为一名IT行业的程序员. 
　　
　　　　在过去的10年间, 我帮助我的导师编撰过地理学的教材, 制作过富有表现力的课程胶片, 也指导过低年级的学生完成他们的毕业论文. 在科技公司工作期间,我撰写过新员工手册,项目组新成员报到手册，客户白皮书, 开发人员手册,开发环境安装指南, 应用程序手册,还写过一些流程方面以及工具操作的指南.我还帮助那些技术员非常牛但是文字表达能力却不怎么好的技术人员修改他们写的详细设计，部署流程与方案等方面的文档。现在回想起来,能够很好的完成这些任务, 很大一部分原因,是因为我愿意写作,即使写的不是小说. 而过去作为一个程序员的经历,也让我积累了操作系统，数据库，开发平台以及编程语言方面的知识，因而能够很快的对一个软件应用有全面的认识和了解。 
　　
　　　　一个偶然的机会，我接到一个临时的工作，在微软公司的一个部门做专职的技术文档开发。这一段经历让我开始喜欢上这个职位。我需要和各个方面的人员打交道，包括项目经理，开发人员，测试人员，领域专家，以获得我需要的信息。然后我需要用我自己的理解把这些信息转化成文档，让微软内部的其他技术团队使用。这是一个相当有成就感的过程，我自我管理，控制工作进度，为文档的质量负责，寻找各种办法解决写作中碰到的疑难问题。在这样一个职位上，需要很强的积极主动性，沟通能力，解决问题的能力，质量意识，还有作为一个文档负责人的责任意识。由于我是新手，我会有意识的收集我的工作伙伴以及上级对我工作的反馈。他们说我做的很好。我很开心他们这样说，因为我开始热爱这个职业，而我的能力是如此的适合从事它。 
　　
　　　　这个职位对你的生活方式带来什么影响？ 
　　
　　　　我是新手，所以关于收入方面，可能没有很多的发言权，但是即使受经济危机的影响技术文档写作工作的收入会有所波动，但一个专职的技术文档开发作者并不比一个初级程序员的收入低。而高级技术文档作者由于人数稀缺，其收入应该会更高。欧美方面的情况则又不一样，那里的技术文档作者收入比中国更高，一个专职的技术文档作者的收入，可以养活老婆和三个孩子。英文技术文档作者有一个专门的联盟Society for Technical Communication (STC) ，那里会提供大量的工作机会，培训机会，举办全球技术作家峰会，以及公开行业薪资标准信息，成为它的会员会有很多益处，不过需要缴纳年金。 
　　
　　　　成为一名技术文档作者增强了我解决问题的能力，使我对技术问题有了更大的耐心，同时也加深了我对技术的了解和兴趣。例如，我的一个朋友，他可以说是一个电脑白痴，通常电脑速度太慢，或者不能上网，或者死机，他只会抱怨，而对于重装操作系统，那更是不可能完成的任务。我的父亲，很喜欢电脑和上网这个新奇的玩意，但是当他想用word制作一个年度自来水用户情况报告，那些word的复杂的工具栏和按钮，对于他来说确实很难一下子记住。而我以前对待我的朋友和父亲的方式，是教一遍，如果他们听不懂，那我就直接帮他们做了，我懒得再讲。我不能理解他们为什么讲的那么清楚他们还听不明白。现在则不是，成为一个技术文档作者之后，我开始明白那些对于我来说已经是常用词汇的术语，对于他们来说，可能是复杂的技术名词。我开始试着用浅显的语言和形象的比喻告诉他们磁盘整理是什么，怎么去配置IP地址，怎样用word的复制和粘贴按钮。这样做是很有效的。对于我自己来说，我已经习惯于从大量的文字中找到有效的信息，因此看帮助文档来学会使用一个软件或者工具，已经是小事一桩。 
　　
　　　　技术文档写作的压力相对软件开发可能会小一些，这是我这段时间的一个体会。虽然有时候由于项目要求在很短时间内必须完成一个新功能的文档，必须在一些夜晚加班，但是大部分时候则是朝九晚六，非常规律。这让我可以在下班之余还有周末享受自己的时光，发展其他的业务爱好。 
　　
　　　　对于准备从事这个职业的人有什么建议？ 
　　
　　　　如果你准备从事技术文档写作，就应该把它当作一个职业，而不仅仅是一个养家糊口的短期工作。 
　　
　　　　大多数时候，一个技术作者是在写作（或者正准备写，或者正在修改你已经写的东西）。指导手册可能不是那么的有创意或者有趣，你需要把复杂的信息写成结构清晰，易于理解的文字。你没有创造什么东西。实际上，你是在写作。 
　　
　　　　但是仅仅具有文字功底是不行的，你还必须具有理解技术的资质。 当你怎么也不能够弄明白一些东西的时候，你的血压是否会升高？ 你是否能够找到一个解决这个问题的办法？ 如果你善于解决问题，那么技术文档写作很适合你。解决问题会占一个技术文档作者工作实践很大的一部分，因为他需要去试验，去探索，去测试那些软件的功能，或者可能会有的功能。 
　　
　　　　为了锻炼你的技术技能，至少学会三种类型的程序：一个图形工具（例如SnagIt），一个在线帮助的写作工具（例如Madcap Flare），还有一个视频截取工具（例如Camtasia Studio）。 
　　
　　　　创建出几个例子文档，这样你可以向你的现有的或者未来的老板展示你的技能。 
　　
　　　　开一个博客去写技术方面的交流帖，这样你可以向你的现有的或未来的老板展示你在技术方面的热情和知识。 
　　
　　　　主动的去自我学习，而不是依赖于他人的监督。 
　　
　　　　参加当地的STC chapter。 
　　
　　　　可以描述一个技术文档作者有代表性的一天吗？ 坐公司班车去上班-- 在路上用手机浏览一些技术文章（ZDNet, Business Week，Huffington Post上有很多不错的有关技术的话题和讨论）。 
　　
　　　　参加早晨的Scrum会议，每一个成员汇报昨天做了什么。试着在这些汇报中找出应用程序哪些地方有改变，哪些新的特性或者功能被加进去或者计划被加进去。 
　　
　　　　回到自己的座位上开始操作应用程序。在开发环境下，这个应用程序只有部分功能是可用的。因此要试着去根据设计文档以及一贯的风格猜测它有可能是怎样工作的，以形成文档的初稿。 
　　
　　　　到开发人员那里去询问关于应用程序功能的一些问题，了解操作的工作流还有其他的一些流程。 
　　
　　　　到业务分析是那里去问关于用户特征的信息。用户有可能会使用这个软件做哪些操作？试图找出用户是谁，分辨出不同的角色，以及他们对于一些概念的熟悉和理解程度。 
　　
　　　　返回到座位上，开始验证以前写的在线帮助文档，把那些步骤一丝不漏的过一遍，以确认这些信息都是准确的。 
　　
　　　　为那些特别复杂的，仅仅文字很难描述清楚地任务创建出show-me演示视频。有时候，把握胶片的时间是一个很痛苦的事情，不能说的过于详细，又要交待的比较清楚。但是最后的成果一般都很让人兴奋。 
　　
　　　　创建Visio工程来演示应用程序的工作流和其他一些流程。然后把这个图交给项目经理去审核。 
　　
　　　　在Adobe Indesign里为每种用户角色创建一个one-page 快速参考指南。然后仔细的审核这些步骤地准确性。 
　　
　　　　通过其他途径找到那些应用程序已经更新了，但是没有人告诉我的那些功能。在文档中做出相应的更新。 
　　
　　　　参加项目有关的会议，倾听开发人员，项目经理以及业务分析师的谈话。询问他们准备何时在应用程序中创建帮助按钮。注意到项目有可能会延后好几个星期。 
　　
　　　　解决在线帮助文档中的一些bug。调整Firefox中的风格。CSS也有一些改变。 
　　
　　　　到项目所在的站点(sharepoint, TFS, Starteam)里面去浏览一下，看哪些技术文档更新了，哪些跟我的工作需要是相关的。浏览一下需求文档，看看需求文档和目前的开发的软件的差异。询问项目经理哪一个是正确的。 
　　
　　　　对于应用程序中信添加的特性和功能，在帮助文档中添加新的主题。 
　　
　　　　建议开发人员更改界面上一些按钮和文本框的提示和文字，使他们更易懂。 
　　
　　　　打印出文档让业务分析师去审核，并且预定一个会议以鼓励他发表更多的意见。 
　　
　　　　给产品发布公告以及公司简报等媒介撰文，用人们易懂的方式描述产品的新特性。 
　　
　　　　下班回家。 
　　
　　　　对于入门级别的技术文档作者来说，有哪些机遇？ 
　　
　　　　一般来说，初级的技术文档作者随着经验的积累成为资深技术文档作者。然后他们可能成为一个经理，或者成为自由职业者，或去做咨询顾问的工作。有一些成为业务分析师或者项目经理，或者从事其他技术相关的领域。这里有一些关于技术文档写作是否是一个过渡性工作的争论。有一些人认为技术文档可以为成为业务分析师或者软件可用性分析师或者资讯架构师等角色的跳板。 
　　
　　　　目前来说，有经验的资深技术文档作者依然是稀缺的，这也使他们的收入很高。还有一个选择，就是成为自由职业者或者合同工，计件或者计时付费，这样的好处是可以在家里办公。对于有天赋并且有热情的技术文档作者来说，这一行还是非常光明的：这是一个需求正在上升的行业，同时未来的发展也没有限制。在许多国家，技术文档作者明码标价但仍然供不应求。那些自由职业者，还可以旅居国外办公。 
　　
　　　　对于我来说，之前的3年，我一直从事的是应用程序开发方面的工作，同时我也喜欢项目管理和协调的工作。我的职业规划应该是相当清楚地：花3-5年的时间成为一个资深的技术文档作者，当对公司的产品线有了非常深入和全面的认识之后，我可以担任多个产品的技术文档开发的管理工作。技术文档的项目经理比资深技术文档作者需要更广泛的知识以及沟通的技能，因此也对我提出更高的挑战。 与技术文档写作行业相关的问题 
　　
　　　　这个行业目前面临哪些挑战？ 
　　
　　　　最大的威胁是公司面临不景气。当一个公司或者部门盈利下滑时，通常会裁员来降低成本。技术文档作者这个职位通常很容易被裁掉，因为老板们认为业务分析师或者领域专家（SME）以写那些用户手册，或者老板会让一个技术文档作者分担更多的工作。有一些领导认为领域专家是有这个潜力去做技术文档作者所做的工作的，然而结果通常会令他们失望。想想看一个用户说明手册里面拍板混乱，步骤没有任何明显的数字去指引，或者一页纸满满都是文字，并且充斥者令人丈二摸不着头脑的行话和术语（SME下意识的会认为读者知道这些行话是什么意思）。 
　　
　　　　这个行业的主要竞争对手有哪些？ 
　　
　　　　一些人认为wiki会减少技术文档写作的工作机会，他们认为项目组的成员可以为他们所做的那一块写描述文字，让用户根据使用进行修改，插入到wiki页面去。然而这样做有明显的限制，风格不统一，缺乏有效性验证，责任人不清晰等。我同意Craig on Helpscribe所说的，wiki永远不会消灭技术文档写作。我曾经试图在一个wiki上生产出我的帮助文档，是对于一个新工具的描述，包含75个主题。最后我发现仅仅2个人做了一些大的改动。再也没有什么人去改它了。并且由于wiki是文本格式的，而且来源不是单一的，因此很难去排版和重新组织信息。wiki已经存在差不多10年了，但是并没有替代很多东西，除了大英百科全书。 
　　
　　　　Web 2.0技术也对技术文档写作也有一些冲击，可以看DMN上发表的一篇文章Web 2.0 and Documentation Don’t Always Play Well Together. 
　　
　　　　对于英语技术文档作者来说，另外的一个竞争对手就是来自外包。很多欧美的职位都被外包到印度这些国家。Charles Jeter写过一篇文章an interesting post on the state of innovation in India来探讨这个话题。这是全球性的趋势，为了降低成本，很多公司会这么做。 
　　
　　　　但是有一句俗语：不要把所有鸡蛋放到所有篮子里。如果想要规避风险，就要使自己具有更多的技能，承担更多的责任，而不仅仅只是一个传统的技术文档作者。除了写那写产品描述文档，用户手册，安装文档等等常规性的文档之外，应该更关注外部的技术对我们的工作价值带来的冲击，及时地充电。例如：学会使用sharepoint去建设部门及项目组的站点，学习敏捷开发并根据这个全新的开发模式来安排自己的任务，根据部门的需要录制培训视频或者其他短片，做API 文档开发，撰写项目和企业白皮书等等。总而言之，技术文档作者的工作开放新很强，没有很明显界限的。你需要根据企业的需求来调整自己的工作内容，而不是墨守陈规。 
　　
　　　　未来的几年里有哪些改变会影响到这个行业？ 
　　
　　　　由于我刚刚进入这个行业没多久，因此对整个行业的洞察和见解显然会比较肤浅和片面。这里有一些比较资深的技术文档作者例如Neil Perlin 以及 Doug Davis，你可以去google上搜索他们发表的见解。我所看到的是DITA带来的改变。DITA是一种XML语言，它可以让我们复用基于主题的内容。在未来的几年里，DITA将会变成一个标准的技术被嵌入到许多流行的帮助文档生产工具中。这将使源内容更加统一，也提高了技术文档作者的效率。随着效率的提升，我们可以在培训，支持，以及质量保证上面做更多的工作。实际上我已经担任了部分的角色。