小TW与R&D的爱恨情仇

技术传播日常工作的开展，离不开与研发人员的沟通与合作，其中总会发生一些令人啼笑皆非的有趣故事。谨以此文献给那些在与研发沟通中曾经或正在爱恨纠结的技术文档工程师们。...



首先说明，这里的“TW”指的是以技术文档工程师（Technical Writer）为代表的各种技术传播从业人员，也就是不管在甲方或乙方都能看见的整天追着研发要东西的悲催写手。之所以冠以“小”字，是因为和R&D相比， TW一般人数比例很小，且多少有点不太受待见。“R&D”即研发（Research& Development），在本文中泛指研发里面的技术开发人员、一线生产人员、测试人员、项目主管、发布主管等等。

人物介绍：

小TW：语言或科技专业，多数为非对口技术专业；擅长交付各种媒介的亲“民（即读者）”文档和服务；为文档质量负责；需要R&D的素材和反馈意见；绝大多数时间是单独跟R&D沟通；

R&D：对口技术专业；擅长写让外行不明觉厉的spec和wiki、画高大上的diagram；为产品质量负责；需要TW的文档来诠释产品、塑造形象；以群体或个人跟TW沟通（其实和他们跟研发同行的沟通时间相比，和TW的沟通简直可以忽略不计）。

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

过招1：“我！没！空！”

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

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

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

过招2：“你要的东西我都有现成的啊，见wiki~”

这句话还通常和文档审核之后淡淡的一句“写了半天，和（wŏ）我（zěn）给（me）你（méi）写（kàn）的（jiàn）不（nĭ）是（mén）一（de）个（jià）意（zhí）思（zài）么（năr）？”首尾呼应。如此配套出现的杀伤力绝对不可小觑，保管TW瞬时崩溃、抓狂、无语。类似的还有“你想得太多啦，不可能出现这种情况滴~”

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

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

过招3：“你写的这个早就过时了，这个是新的版本，拿好不谢！”

类似的小惊“喜（悲）”还有来自一线的生产计划调整、来自技术部门的设计变更等。这些本来可以提前预见的变更，足以让TW当场吐血。

未雨绸缪：和关键人物保持密切沟通，随时掌握进度和变更。要主动，不怕麻烦，经常正式或非正式地与关键人物核对，方法比如制作便于他们核查的进度表、范围、问题清单等，落实负责人（责任到人的时候往往会激发被信赖感和主动性），等等。只要用心，加上经验积累，总会找到更方便更有效的预防措施的。

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

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

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

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

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

过招5：“你们文档今天一定要交付么？我这儿还有一个功能要加进去。”

五花八门的last minute 意见让TW的生活多姿多彩。各位TW亲，在即将最终交付之际，内心有没有一种十面埋伏、胆战心惊的忐忑？总觉得哪里会突然冒出一个人、一封邮件，告诉你一个要命的变更或新功能？甚至这种忐忑会在提交后仍挥之不去，你总想找研发经理或发布主管再次确认一下才能放心？

未雨绸缪：所有的关键人物要在文档开发之初就确认好，并在开发周期中密切跟踪以免有变，因为这些人中任何一人的缺席、不配合或任何的修改意见都会直接影响文档工作。所有文档的开发计划、范围、读者、架构等等也要一开始就敲定。

见招拆招：万一真的发生了，也只能是尽量把损失降到最低了（这里的损失是指全局的，而非仅考虑文档一方的）。首先说明流程和原则，以及因此造成的影响，然后视具体情况而定。笔者曾经遇到过，直接阐明原则和利害，然后果断拒绝了，后来就再也没出现过类似情况。当然笔者也曾经因为最终交付当晚姗姗来迟的几条极其重要的修改意见，通宵加班到凌晨4点（时差有时真是个好东西）。毕竟，咱TW们也都是顾全大局的人，不是吗？

结束语：

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

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

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

    关注 HappyTC