美文网首页技术传播那些事儿
经验分享 | 来自 11 位 Technical Writer

经验分享 | 来自 11 位 Technical Writer

作者: Lilian_Lee | 来源:发表于2018-03-22 07:04 被阅读35次

    Foreword

    初入或者有意进入 Technical Writer 这一行的小伙伴,难免会对个人的职业发展有些困惑。那该怎么办呢?其实能做的至少有以下三点:

    • 通过各种渠道了解行业动态和发展趋势,比如业内权威的一些组织机构、优质的博客网站等;
    • 不断学习,拓展广义上相关的专业技能,比如技术、设计、内容营销等;
    • 看看前人走过的路,听听资深从业者的见解,结合自身情况做出判断、采取行动。

    这里跟大家分享 11 位 Technical Writer 前辈对这一行的职业发展建议,听听前辈们的看法,说不定会对自己有所启发哦。

    Tom Johnson

    个人博客:http://idratherbewriting.com/

    “如果你想获得成功,那么开始写一个技术传播相关的博客吧,并且定期更新。这样做会督促你去阅读、思考,并将技术传播的原则应用于日常事务。这样做会让你与这个行业保持连接,让你的工作更具互动性和趣味性,因为你可以分析可预见的机会,思考日常工作中遇到的事项。”

    Comment:

    一开始看到 Tom Johnson 的这条建议时,我的内心活动是:呀!好巧,我正好已经开始做这件事。

    2017 年 9 月,在加入 PingCAP 做 Technical Writer 一个月之后,我决定开始写一个技术传播相关的博客,初衷是:敦促自己多一点儿更深的思考,对工作中遇到的问题、习得的技巧进行回顾、反思、总结。

    于是便去以下三个平台刷了一点儿存在感:

    实际做起来,有了更多收获。这样做不仅促进了我去思考、分析一些常见的问题,也让我认识了更多的同行小伙伴,与这个行业有了更进一步的连接,让工作更有趣味。

    Scott Abel

    The Content Wrangler 创始人 & CEO:http://www.thecontentwrangler.com/

    The Content Wrangler

    这个网站上有很多当前业内比较热门的话题,做得比较好,可以经常刷一刷。

    “不要让自己局限于一种或其它某种类型的‘传播’。职位名称无关紧要。实际上,如果你发现自己最适合从事的工作不是‘技术写作’这个职位,也不必感到惊讶。事实是,整个商业正在经历重大的范式转变,才刚刚开始重视我们所创造的内容的价值,并将其视为一种需要高效和有效管理的商业资产。这意味着企业正在关注我们的工作方式(所用的流程)并对其进行优化以获得最高效率。学校里没有教这一重要事实,也没有教你如何在当今的就业市场上为工作做好准备。

    最需要的技能是:合作式的结构化创作(需要团队合作,以及撰写模块式的、独立于上下文的内容块的能力),内容策略(能够将业务目标与内容创建、管理和交付任务相匹配),以及理解内容标准,例如 DITA(Darwin Information Typing Architecture,达尔文信息分类体系结构)。此外,了解并能够为当今流行的移动设备和电子书阅读应用设计交互式的内容,掌握社交类文档和社区管理的艺术(与用户保持互动,让用户协助内容的改进,以便快速发现错误,提高质量,以及添加缺少的内容)是下一代技术写作从业者应掌握的关键技能。

    当然,写作、标点符号、语法和修辞也很重要,但这是每个大学毕业生都应该已经掌握的基础知识。如果你想成功,想在这个极具竞争力的全球市场中脱颖而出,你必须摆脱传统的“写作”角色,掌握所有传播类型中的重要概念。了解受众和传播目的非常关键。选择正确的传播方式也很关键,因为有些信息通过视频、音频、信息图或交互模拟可以更好地传达。当今世界仅仅是一个 Writer 是不够的。”

    Comment:

    DITA 是一种基于 XML 的体系结构,可用于编写、生成和发布技术信息。它具有代表性的基本内容类型是:task,concept 和 reference。之前使用过一年多的 DITA 编辑工具,像 Arbortext Editor 就比较轻型。这里暂不详述。

    对于 Technical Writer 来说,除了“写”之外,在技术传播这个大框架下,其实还有很多可以做的事情。

    Alistair Christie

    个人博客:http://www.itauthor.com/

    “所以你已经为自己找了一份技术写作的工作。首先,不必为这个职位名称感到担忧。你不会整天都在写作,而且很多时候你的工作并不会特别技术性。

    如果你在软件开发的环境中工作,不要期望有人赞美文档多么好,永远不要。虽然这可能会发生,但不要寄予希望。如果没有人抱怨文档太差或文档不全,那就已经可以看作是一种赞美了。你不必为此而感到气馁。

    有很多方法可以赢得尊重并成为一名受重视的员工。在软件开发部门工作,你可以把自己当作最终用户的代表,开发人员有时根本做不到这样,因为他们有自己独特的思维方式,这会使你成为一个非常有用的资源。所以,发挥你的价值吧。

    你还可以获得整体且详细的产品架构图,而在公司内几乎没有其他人可以获得。这是因为你的工作涉及很多产品,并且从用户的角度来看,你将一直关注这些产品。当开发人员、产品经理、销售人员和市场团队需要知道哪个产品可以为哪些用户解决哪个问题,以及产品之间如何关联时,你就成了可以提供帮助的人。

    对你的工作最高的一种赞美就是在别人找你解答问题、寻求你的帮助时得到的。你要鼓励这种行为,并且抓住机会向别人展示你知道的东西。他们会对此感到惊讶。但是,一旦你解释了为什么知道那些东西,且言之有理,他们便会让更多人知道你是掌握那些东西的人。

    作为一个 Technical Writer,很容易默默无闻。但是,请帮自己一个忙,不要默默无闻。”

    Gordon McLean

    网站:http://www.onemanwrites.co.uk/

    “我的首要建议是 - 问为什么 (why)。如果你只会问一个问题,那就问为什么。无论手头的任务是什么,这都是最重要的问题,是的,比问是谁 (who) 更重要。(当然了解受众很重要,这里假设你已经清楚了)。明白你为什么要做某件事,而没有做别的事,可以帮你把精力聚焦在重要工作上。

    我们都有很多事情要做,而且很少能全部做完,所以有必要向自己、向上司、向团队负责人、向同事问个为什么,成为众所周知的问为什么的那个人(同时也要记得问 how,what,where 和 when)。你也可以把这个问题延伸到写作中:为什么这样行得通?为什么用户不应该那样使用这款产品?为什么用户应该这样使用这款产品?”

    Comment:

    问问题是一门艺术,尤其对于 Technical Writer 来说。

    Mike Hughes

    个人博客:http://user-assistance.blogspot.com/

    “我来自软件开发的环境,我的建议是‘成为一个推动者’,也就是帮助你的团队实现目标。这里的团队是指产品经理、开发人员、QA 以及写作人员组成的更广义的团队。

    If they need 'down and dirty' give them minimalist and good. If they need 'comprehensive, accurate, and this afternoon,' give them the most comprehensive and accurate document you can write this afternoon (better yet, find stuff you've already written). Too often, technical communicators get excluded because they turn into blockers, telling the team what they can't have.

    任何团队中最好的赞美就是成为公认的让团队变得更好的人。寻找机会使用你的传播技巧来获得这种赞美吧。”

    Ellis Pratt

    个人博客:http://www.cherryleaf.com/blog

    “看看如何获得一些可以放在你的简历中的相关写作经验。许多开源软件项目都在寻找人们编写手册。你可以让自己加入其中一个写作团队。你可以为当地的慈善机构撰写步骤指南。写得好和按时交付是两项最重要的技能,而一些写作项目的经验可以帮你向未来的雇主展示这两项技能。”

    来源http://www.helpscribe.com/2010/10/technical-writing-career-advice-from-11.html

    你可能想读

    Technical Writer 日常工作中好用的小工具
    技术翻译需要有 Technical Writer 的 sense
    深度解析关于技术翻译的六个认知误区
    如何让你的内容输出更加专业更有设计感?
    书单 | 有哪些技术传播从业者必知必看的书籍?
    有哪些适合技术传播从业者关注的优质博客?(一)
    有哪些适合技术传播从业者关注的优质博客?(二)
    英语技术文档的标题到底该大写还是小写?
    如何使用正则表达式批量添加和删除字符?
    Markdown:写技术文档、个人博客和读书笔记都很好用的轻量级标记语言
    如何为 Markdown 文件自动生成目录?
    技术写作实例解析 | 简洁即是美
    两分钟趣味解读 Technical Writer
    若脱离理解,直译得再正确又有何意?
    优质译文不应止于正确,还要 Well-Organized
    写在入职技术型创业公司 PingCAP 一个月之后
    揭秘 Technical Writer 的工作环境 | 加入 PingCAP 五个月的员工体验记

    -END-

    相关文章

      网友评论

        本文标题:经验分享 | 来自 11 位 Technical Writer

        本文链接:https://www.haomeiwen.com/subject/qvsoqftx.html