职场恩仇录

  传播, 评论

(文/Tom Johnson)我喜欢编写Xtranoraml剧本时的快感,因为剧本里我可以把项目经理在欺骗、跟踪、管理和控制文档工程师时表现出的丧心病狂、无所不用其极用数据列得一清二楚。在我看来项目经理就是这样的魔鬼,这也解释了为什么同事Derek告诉我他正为一种新的项目管理模式创建用户教育模板时我并不感冒的原因。我只是粗略的看了一遍就同意了,因为实在不想在上面浪费时间。

我知道自己喜欢抱怨文档工程师被孤立的问题。不通知我们会见客户,项目提前也不被告知,原型设计考查会不能参加,没有进入合适环境的权限等等。

所有一切都是合法的,但最近情况却转向了完全相反的方向。项目经理们很早就请我撰写帮助内容;他们邀请我参加许许多多的会议;在项目中对我张开了欢迎的臂膀,不管我是要考查原型还是希望发出有影响力的声音。

问题是,我的体力和精力不允许我参加全部的会议。我曾希望通过与社区授权的志愿者们合作来扩大工作范围,但最终并没有成功。我在盘子里放入了一个又一个的项目,因为拒绝它们真的很难。“哦,你即将开展的项目需要帮助吗?什么时候发布?三个月以后?让我来给你提供帮助吧。”

我曾和一麻袋的项目经理们重复过这段对话,接了一批又一批的工作,最后期限远的当然不需要操心。我有一列列的代码工作要做,过去我也跟这些项目经理们合作过,为什么现在不能继续呢?

如果工作还不够,可以利用寻找信息空缺所发挥的作用,这些空缺都是我在机构中察觉到的。我通过阅读用户手册、写文章来填补这些空缺,以参与更多的项目。找到新项目其实是分分秒秒的事情,例如和某人闲聊一下他正在进行的新应用项目,就会出现新的机会。“你们的应用项目中帮助内容的解决方案是什么?”“噢,我们还没考虑这一点呢。”“我能帮你……”

这不仅是因为我有答应所有事的坏习惯,而且还不喜欢严格遵守时间和计划。给我一个发布日期,告诉我你需要什么,我就满足了。这是我的风格,但最近这种风格开始自我崩塌,因为每次见到项目经理,他们都想知道帮助文档的进展状况,而且我的工作范围还在扩大。我发现自己搅进了调试错误、设计原型、分类问题,决定关键特征,帮助用户等等事务中,换句话说,我变成了一名主创人员。

帮助文档没有按期搞定是因为我的时间越来越少了。现在我的日程至少已经安排到了明年年中。在最近标准讨论的小组会议中,我发现自己失去了讨论有效手段和整合入早期软件开发进程中的能量。整合?我不需要过早整合,项目经理们在整合我,而我们只需要更多资源。我们能聘请另一个文档工程师吗?我能聘请实习生吗?

现在,我开始重新审视Derek撰写的用户教育计划模板的价值。虽然我喜欢通过非正式的协议和握手来敲定项目,但我意识到这种方法很快就会把我埋葬在工作的汪洋大海中。除非我能够确定各个工作需要的具体时间,否则就会接下过多地项目,结果就是无法达到想要的质量。除非我能更好地界定工作范围、期望、并在项目开始前交付,否则就不能达到我承诺的工作质量。

Derek长达23页的用户教育计划模板容纳了文档计划中所有重要的组成部分:目标、受众、风险、依赖度、定位、SME联系、界碑、内容模型、共识、假设、预算、范围、内容概述、策略、轨迹等等。这个文档能够强迫你在答应不合理的时间安排前重新思考一遍。它也能够帮助项目经理和文档工程师在期望与现实间找到共识。

我惭愧地承认,这么多年过去了还没有完成一个正式版的用户教育计划。但我开始认识到这是个巨大的错误。如果我打算让自己保持清醒并干好帮助文档这项工作,就需要在预计项目的工作量和要求时更加小心。在一小部分项目中做出漂亮的帮助文档比完成一堆半生不熟、马马虎虎的项目要好的多。所以,与其说计划文件是让你崩溃的一块砖头,不如说它更像是一把利剑。正如同无理的项目要求和时限是茫茫大海的话,那么计划文件就是在你落水时上天恩赐的浮木。

原文看这里

科技名博微博

看完文章来这里调查一下吧

博主介绍:
Tom Johnson是LDS Church一名高级的文档工程师,在此之前,他曾尝试过各种工作,比如在哥伦比亚大学和美国大学开罗分校教授文档写作,在佛罗里达做文案等等。无论什么工作,博主自己都说了,文档工程永远都是他的最爱。这个博客里,他会一直跟踪最新的技术,包括技术指导,技术设计和一些文本。

LEAVE A COMMENT

This site uses Akismet to reduce spam. Learn how your comment data is processed.