最新消息:想上头条?没问题,只要你给本站投稿就行啦~

小TW与R&D的爱恨情仇——与研发人员沟通的几个案例

原创 Happy Doc 1374浏览 0评论

首先说明,这里的“TW”指的是以Editor为代表的各种技术传播从业人员,也就是不管在甲方或乙方都能看见的整天追着研发要东西的悲催写手。之所以冠以“小”字,是因为和研发相比, TW一般人数比例很小,且多少有点不太受待见。“R&D”包括研发里面的技术开发人员、一线生产人员、测试人员、项目主管、Release主管等等,他们手里都可能攥着小TW想要的宝贝。当然,这个群体还有其他一些处于文档开发上游或下游的人,比如市场、销售、售后服务、翻译、印刷,甚至一些原材料供应商、研发代理商、合作伙伴等,TW和他们沟通的案例会稍有些不同,不过限于篇幅,不在本文重点讨论之列。其它类型文档如市场类、法律类等,亦不在本文重点讨论之内。

本文献给那些在与研发沟通中爱恨纠结的TW们,至于那些已经修炼出关的大牛小牛们,就只当是在重温那段美好的回忆吧。

人物介绍:

小TW:语言或科技专业,多数为非对口技术专业;擅长交付各种媒介的亲“民”文档和服务;为文档质量负责;需要R&D的Input和Feedback;绝大多数时间是单独跟R&D沟通;

R&D:对口技术专业;擅长写让外行不明觉厉的Spec和Wiki、画高大上的Diagram;为产品质量负责;需要TW的文档来诠释产品、塑造形象;以群体或个人跟TW沟通(其实和他们跟研发同行、测试、QA等的沟通时间相比,和TW的沟通简直可以忽略不计)。

为了各自的责任,为了能给各用户群体提供最优的产品使用体验,我们的小TW和R&D的生活从此美妙地交织在了一起。。。

过招1:“我!没!空!”

我们亲爱的研发同事们多数都很质朴、坦率,说话直来直去,多数时候可能不解释,直接一句话就将他/她的结论告诉你。如果这时的小TW比较腼腆或过于敏感,瞬时间就会勇气顿挫,自尊心碎得一片一片的。

未雨绸缪:提前在研发和自己身上下功夫。事先给研发们讲讲文档那些事儿(杜绝突兀冒犯),增进了解(行业层面上)和友谊(个人关系层面上),让其明白文档对产品研发的重要性,或让研发意识到与TW沟通对自身的意义价值,温柔巧妙地把拒绝消灭于无形。另外,研发不是贴身秘书,研发都很忙的。在开始沟通之前TW也要自己狠下功夫,要事先刻苦钻研,不要事无巨细都跑去找研发。找研发时,建议做一名虚心上进、打破砂锅问到底的学生,如果你天分更好、能够拿捏的话,呆萌一点也无不可(仅限年轻MM)。毕竟,对工作的认真和对专业权威的尊重是必须的。但同时,也要做好被拒绝的心理准备和多个应对之策,务必最终拿到想要的东西,做法见下一段见招拆招。

见招拆招:时间精力允许的情况下,首推“晓之以理,动之以情”。这时考验的是一个TW的心理素质和随机应变了。内心要够强大,把自己的要求暂且Hold住,切莫步步紧逼,然后打出同情牌,必须要表明你是能够切身体会到研发的处境和决定的。同情拉近距离,站得更近了,说起话来也就比较好接受了。顺势站在研发的立场帮助剖析利害关系(文档行业术语会让研发感到陌生无趣,尽量杜绝),帮助寻找双赢Solution(注意:剖析要动情、在理,Solution要简单易懂、易操作)。相信,有了事先的准备、灵活的应变和经验的积累,我们的小TW们会渐渐轻松应对的。当然,特殊情况特殊处理,紧急情况紧急处理,但一定要慎之又慎,并务必顾及所有人的感受,不到万不得已不建议使用。

过招2:“你要的东西我都有现成的啊,见Wiki~”

这句话还通常和Review完淡淡的一句“写了半天,和(wo)我(zen)给(me)你(mei)写(kan)的(jian)不(ni)是(men)一(de)个(jià)意(zhí)思(zai)么(nǎr)?”首尾呼应。如此配套出现的杀伤力绝对不可小觑,保管TW瞬时崩溃、抓狂、无语。类似的还有“你想得太多啦,不可能出现这种情况滴~”

未雨绸缪:首先要清楚,每个人的背景经历等因素造就了各自的思维和想法,不是别人那么容易改变的,但也不是没有办法施加影响,参照过招1的预防办法。也可提供Sample或Template给研发作为参考。但研发不是文档,这种情况还是会偶尔出现的。

见招拆招:TW的基本功之一就是对海量信息的分析消化能力,这个自不必说。笔者想说的是:在涉及到写作时,TW要当仁不让、立场坚定地担当起专业文档人士、职业写手的角色。研发想的写的多是技术性的,并非适合我们或我们的读者。语言要么中文,要么是不那么专业的外语。作为TW,我们要始终明白自己要的是什么,其它都是浮云,无需介怀,更不要顺着研发关于你写作的Comment,或研发Input/Comment中的思路逻辑、信息架构、出发角度、写作习惯、语言特点等随波逐流,最后弄得自己在Input的汪洋大海里越陷越深、越走越纠结。所以,摆正心态,相信自己,坚定立场(当然不是叫你一定要去和研发决一胜负、拼个你死我活),锲而不舍,不论最后研发给的是什么形式的Input,取其精华(想要的核心东西)去其糟粕(其它一切无关的东西)。当然,笔者也曾接触过一些技术大牛,对技术文档也确有一些独到的见解,因此TW们在沟通时要始终善于聆听,于人于己都有好处。

过招3:“你写的这个早就Obsolete了,这个是新的版本,拿好不谢!”

类似的Surprise还有来自一线的生产计划调整、来自技术部门的设计变更等。这些本来可以提前预见的变更,足以让TW当场吐血。

未雨绸缪:和有关Key Person保持密切沟通,随时掌握进度和变更。要主动,不怕麻烦,经常正式或非正式地与Key Person核对。方法有很多,比如制作便于Key Person进行Review的Schedule、Scope、Issue List等,落实Owner(责任到人的时候往往会激发被信赖感和主动性),等等。只要用心,加上经验积累,总会找到更方便更有效的预防措施。

见招拆招:一旦发现自己被遗忘了,迅速调整思维和计划,甩开负面情绪,把准备吐槽的精力投入到适应新版本的行动中去。

过招4:“我们的xx临时变了,所以现在没有东西给你。”

技术传播工作之所以精彩,原因之一就在于:总会有些不可控的和不可预见的Surprise在某个转角等待着与你邂逅。

未雨绸缪:预防措施已超出正常TW的职权范围。

见招拆招:和研发除了“哦?”之外没啥好说的,如果真的发生了,我们能做也必须要做的是,尽快响应(分析所有附带影响和潜在风险、调整文档开发计划、组织协调资源、找相关人核查将来有无变更的可能性等等),在力所能及的范围之内(文档)将损失降到最低。

过招5:“你们怎么这么准时就提交文档了啊,我这还有一个Feature要加进去。”

五花八门的Last Minute Comments让TW的生活多姿多彩。各位TW亲,在即将Final Deliver的时候,内心有没有一种十面埋伏、胆战心惊的忐忑?总觉得哪里会突然冒出一个人、一封邮件,告诉你一个要命的变更或Comment?甚至这种忐忑会在提交后仍挥之不去,你还总想找研发经理或Release部门Double Confirm一下才能放宽心?

未雨绸缪:所有的Key Person要在文档开发之初就确认好,并在开发周期中密切跟踪以免有变,因为这些人中任何一人的缺席、不配合和任何的Comment都会是直接影响文档开发的因素。所有文档的Scope、Level of Information和Audience也要一开始就敲定,当然这要基于对需求和产品的理解,以及对海量Source Information的把握能力。

见招拆招:万一真的发生了,也只能是尽量把损失降到最低了(这里的损失是指全局的,而非仅考虑文档一方的)。首先说明流程和原则,以及因此造成的影响,然后视具体情况而定。笔者有幸遇到过一次,直接阐明原则和利害,然后,果断拒绝了,后来就再也没出现过类似情况。当然笔者也曾经因为Final Delivery当晚姗姗来迟的一堆极其重要的Comment,通宵加班到凌晨4点。毕竟,咱TW们也都是顾全大局的人,不是吗?

调侃了几个让小TW崩溃抓狂的案例之后,要给R&D说句公道话:虽然TW和R&D的沟通有时会出现些小问题,但是事实上,我们的R&D xdjm也很不容易,整天赶各种Deadline,忙得焦头烂额。而且笔者相信,绝大多数的R&D在时间和精力允许的情况下都是非常愿意配合的。还有,R&D是TW的合作伙伴,我们需要互相尊重、彼此依赖、共同成长,把R&D放在敌对面上来沟通的心理是万万要不得的。

所以,在日常沟通中,还请我们的TW周密计划、密切跟踪、Prevention Over Solution,一旦出现问题要多些再多些耐心,多动脑筋,互相包涵,与R&D共同创造和谐、充满正能量的工作氛围,实现我们共同的目标。

最后祝所有可爱、敬业的TW和R&D们工作顺利,共同收获快乐!


原创文章,版权归作者所有,转载请注明本站以及作者名称,并保留原文链接

本文链接:http://www.chinatechwriting.com/laughs-and-tears-working-with-rd/


The following two tabs change content below.
Happy Doc
爱生活,爱TC
Happy Doc

Latest posts by Happy Doc (see all)

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

网友最新评论 (4)

  1. Monica Xie
    现在所在的公司用的是敏捷开发流程,每天有例会的,最后这种临时加Feature的事情,有也有,不过我们TW不在第一时间知道,也会在第二时间知道呢。同意在提问前TW需要狠下功夫,基本我们都要把所有的需求文档读完再去提问呢。
    Monica Xie4年前 (2014-08-25)回复
  2. 感同身受...正处于十面埋伏,心惊胆战的忐忑阶段,final delivery前综合症
    轻轻量4年前 (2014-08-25)回复
  3. 为什么说Peer View很重要呢。。别人眼中的研发:不就是写代码的吗?别人眼中的TW:不就是码字的吗?别人眼中的设计师:不就是美工吗?别人眼中的产品经理:别人我不知道,反正他就是个SB。...
    1227590444年前 (2014-08-29)回复