从2013年入职,我也算在Medical Writing界混了8年了。这8年里面慢慢地积累了不少的心得和体会。虽然继续学习的空间仍然巨大,但是我也想有个地方慢慢地总结和回顾我知道的东西,抛砖引玉,引发思考,并且记录下这些讨论和思考。我希望过一段时间我回来翻看这些东西,能够感到有所收获。
闲话少叙,开篇先谈谈Medical Writer(MW)的职业发展方向。后续的计划准备从最“简单”的文档开始慢慢写上去,先是单个受试者层面的Safety Narrative,然后是单个研究层面的CSR,再后面是多个研究的,到最后再来谈方案和研究设计。
通常大家印象中的MW就是“敲键盘的”。我读PhD的时候曾经去一家公司实习,听到公司其他部门的一个人说我们的工作就是“复制粘贴”,我非常的不服气。再后来工作了几年了,有一次参加China Medical Writer's Community(CMWC)的论坛,有位老外讲者说,MW的工作价值很难一下子说清楚,而且人们常常觉得这个职位没有也行(尤其在Research和Non-Clinical的部分,很多时候就是自己设计实验,自己做,自己写报告;Clinical这一边也有很多公司或CRO就是让Clinical Research Physician/Clinical Scientist来写这些文档),但是一旦你和一个好的MW合作过了,你就忽然感觉离不开他们了,希望每个项目里面都有这么个人在。
类似的还有一次,我当时的公司决定MW要参与研究方案的写作了,MW团队的老板也说,我们不是来做QC的,我们也不是来替你设计实验的,总之我们不是魔法棒小仙女。说了一堆我们不是什么之后,我也心里嘀咕那我们到底是什么呀?但是很神奇的,我们开始参与到方案的写作之后,基本上每个项目都得到了好评,并没有因为团队增加了一个人加大了沟通成本大家会有任何不爽,反而大家忽然开始觉得离不开MW了。
所以我想了想,决定绕开MW干什么这个话题,直接谈成为一个好的MW,需要什么技能。也许这个角度谈完了,能够有一些突破。
基础
作为一个刚入门的小白,有一些基本功我想是不言自明的,例如写英文要拼写和语法没有问题、写中文同样要掌握科技类文章的写作方式、熟练使用MS Office。那么在这个的基础之上,第一个阶段就是掌握单个文件的工作。这大概能分成几个方面:
首先,你要理解你写的东西。你要明白你需要放进去什么内容,而不要放进去什么内容,这取决于1) 这篇文档的目的是什么,然后再加上2) 你对数据、Science等等的理解。第一点应该是MW最应该提供价值的部分:在Common Technical Document (CTD)各个模块中需要准备的文件,各自的目的是什么,以及这次Submission的整体的“中心思想”是什么。这一点可能以后写一篇专门的文章去讨论。对于第二点,对数据和临床科学方面的解读,其实统计师和CRP能够提供帮助。虽然在这些方面MW想要能做得比统计师和CRP还出色我觉得不太现实,但是一个好的MW还是要在这方面做非常多的努力去越来越精进的。对MW比较高的要求,是在团队合作的基础之上,把Submission的”未满足的医疗需求“也写了,或者去写一篇很地道的综述,这些都要求能够有比较深的理解。
第二,对文件流程的管理。比如一个CSR,我们通常情况下是拿到数据前,把前面与研究执行相关的信息(Data-Independent)先写好,等到拿到统计数据了,开始写Data-Dependent部分第一稿,经过两次审阅(项目团队一次、大佬们一次)最后定稿,approve。但是我们有时候会看到,EDC里面的数据只要锁库就可以开始分析了,但有些数据(比如药代[PK]数据需要对血样进行分析)提供得很晚,那在Timeline比较紧急的情况下就要开始搞各种灵活处理,先写一稿不带PK数据的,然后PK数据来了再来一稿……Timeline怎么排、在细节上到底是不是可行,等等,也有很多学问。做的项目多了,见了各种神奇的Timeline,凹了各种造型,慢慢就积累了经验。
第三,项目团队的管理。我以前有个同事,她刚刚加入公司的时候,作为一个新人,被安排了一些不是那么重要的项目作为练手。结果她满怀热情地开始做起来之后,发现因为是Low Priority项目,所以团队里面其他部门的同事都不怎么爱搭理这个项目……但是这个项目对她来讲却很重要。这个时候如何去团结你的团队,调动大家的积极性,就非常地考验人了。还有一些其他更常见的情况,比如几个Reviewer对文件某一处意见不一致,怎么处理,怎么让大家达成一致?这些都没有标准答案,而且是因人、因情况而异的。MW要本着科学的精神,运用你对文档的深刻理解,去引导团队走向正确的方向,当然也要艺术地“摆平”团队的不同意见。
我记得之前又有一回参加CMWC论坛,某公司一位国外的大佬说,他们让新进来的白丁员工从Narrative开始写起,先写2年Narrative,然后才能允许写CSR。我那时觉得特别不可思议,要让我写2年Narrative我会枯燥得掀桌。不过这个精神我其实领会了,就是要扎扎实实地打好基本功,然后再慢慢的向上发展,否则很容易一知半解的,没有办法在复杂情况下给出Solution。
进阶
那么单个文件的“基本功”打下之后,你就可以开始变成一个项目的小头目了,开始带领多个文件的大项目了,变成了一个Coordinator/Lead。
比方我之前曾经参与一个项目,要在很短的时间内写3000个Narrative……(想起来就头秃)公司搞了3个Coordinator分别在亚洲、欧洲和北美,24小时轮流,负责管理n个CRO(没有一家CRO能承接3000个Narrative)、协调Review的流程、保证Narrative之间的一致性等等。
还有其他很多时候则是带领一个NDA或者IND Submission,做Lead MW。其实这个时候,上面提到的基本功仍旧适用——这个产品在这个适应症下的突出点是什么?在一次Submission当中各个文件的功能是什么?文件之间的关系是什么?需要准备哪些文件?再次强调,这些东西不是MW一个人来做的,必须是一个团队的集体智慧,但是MW的作用是非常大的。
可能Coordinator不写具体的文件了,或者只写少量文件,但是仍旧需要对流程、整个项目团队进行管理和协调。这个时候的Timeline就是一个巨大的Timeline了。(顺带说一句,我以前曾经收到过别的MW发出来的timeline,是用Word画了一个表格写的。MS Project不是每个人的电脑都装了,但是Timeline还是用Excel来做吧……用上Workday函数,这样才方便调整啊。)而且现在在外企,很多项目开始要求中国和国外几乎同时交,但是中国在与别的国家保持一致的信息和结论的同时,又需要额外的亚组分析,这个时候的Timeline就非常的酸爽了,出了一些变化再要改起来,更加酸爽。
除了这些之外,还要学会Review的技能。在前一个阶段基本是MW向团队大喊“Strategic Review”,然后私下里面抱怨说我的Reviewer给我改标点符号还改错了!然后你自己做Reviewer的时候会抑制不住的冲动想去给改标点符号……(我觉得Strategic Review也是个可以单独成文章的话题。)
除了做Coordinator或者叫做Lead Writer之外,一般你要开始Coach新同事了。有些特别优秀特别资深的MW和我说,Coach别人真的好累,新人半天都写不好,还不如自己加加班一会儿就写完了。我也曾经有类似的感觉,但是慢慢地我理解到这种“痛苦”的根源在于,这项工作需要的不再只是MW的基本技能了(也就是不仅是“搬砖”技能了),而是开始需要通用技能了。这里面包含了人与人之间更频繁和深入的互动、为他人设置合理的预期和目标、协助他人成长。
最后一方面在于做一些好的Initiative。公司的流程和做事方式需要不断地优化,这样才能提高效率、让大家的工作越来越顺畅。有的时候流程优化是从上层传达下来的,这一般是比较大的、公司全局的事情。比如把公司所有的流程,从项目计划、追踪、数据管理……全部都整合到一个大的系统里面,打通通道……这个别说一个人了,一个部门出来也做不了。另外有一些流程的优化,是需要从底层往上做上去的,这就是我说的Initiative。因为很多优化的需求和idea,不是上面的人能够知道的。
那么作为一个比较资深的MW,你在工作中一定会遇到这些需求,然后你要思考怎么去解决这些问题,拿出你的Idea来。如果我们的解决方案是加班加点搬砖,那我们可能无法进步,甚至开始内卷,觉得做完一个项目又是下一个项目,每个项目都Accelerate,进而感觉自己被掏空。当然,这些Initiative并不是说你要凭一己之力就去实现,而是你发现、你提出,老板支持,给帮助给资源,你来牵头,最终做出成绩。
这里面所需要的通用技能就更多了,需要去解决实际工作中很有复杂度的挑战。我有时候见到有的MW,觉得哪个Idea很好,为了实现而去实现,不问这个解决方案最终需要解决的痛点是什么,也不管这个解决方案今后推广给大家使用的话是简化了流程还是让问题更复杂。我觉得这有些像产品经理的一些Skillset,可能我们需要慢慢的锻炼自己。
不仅Coach他人让不少特别优秀的MW不乐意,逼着他们去做做Initiative他们也会觉得很麻烦,刚才说了,因为这些事情需要更多的通用技能,需要MW跳出目前的技术舒适区。因此在职业发展上来看,这是一种进阶。成功地完成这一步的进阶,你对组织的贡献才能更大,反过来你自己的成就感满足感也才会更大。
几年前有个优秀的MW找到我聊天,因为我俩不是一个公司,所以比较能够敞开去谈。他当时的感觉就是接触了很多的文档,一个项目又一个项目地做,周而复始,感觉没什么新意了。当时谈的时候我水平也有限,没有意识到他其实就是卡在这里了,现在反思,我自己也有更多的感悟。之所以会产生“周而复始没完没了做项目”的感觉,甚至开玩笑说自己就是个工具人,主要是因为没有找到下一个阶段的方向。我觉得进阶的方向就是做更多的技术之外的工作(比如上文提到的Coach和做Initiative),寻找突破,获得更大的成就感。
写了好多字,把前面的两个阶段大概说了说,希望能够给大家指出一些方向和可能性、带来一些启发。
发展
下面谈谈最后一个阶段。MW这个职业的最终发展方向,在中国可能还暂时没有大量先例让我们学习,但是看看国外的情况,可以大致给我们一些参考。
简单归纳有两个Track,一个是成为技术专家。我在之前公司曾经遇到一位,是某一类文档的专家。我们大家在这一类文档上有了问题,都会去问她,她说出来的话所有人(包括别的部门的)也听。我当时觉得这也太爽了吧。后来我去法国出差,还专门约了她见面。嗷嗷,这里让我花痴一把,她是典型的优雅法国女性,自带皇冠那种……那时候我和她聊,她的工作大概就是,这类的文档有不少是外包出去的,少量仍旧内部来做。她会负责对CRO公司以及我们公司内部的培训,总体流程的管理,听取内部团队对质量等等问题的反馈,也许会进一步改进流程。所以你看,资深的技术专家也需要不少的管理才能,是更加高级的Coordinator/Lead,可能区别就在于更加技术流一些,不直接带人,不用去思考下属的职业发展。
另外一个Track就是走向了管理岗,带领团队,帮助每一位下属发展自己,同时也要开始做一些决定、担一些责任。每个人的管理风格都不一样,到了这个阶段以我的水平也说不出什么心得了,大家就自己摸索吧!或者多多找其他大佬取经。
总体上去看外企和欧美MW的发展,无论做技术专家还是做管理,我感觉都能做得很好。MW并不是一个拼体力的工作,非常依赖于经验——读读法规看看模板大家都会,但是遇到各种幺蛾子怎么处理就需要大量的经验了。所以说成为一个经验丰富的技术专家对企业仍旧非常有价值,不可取代性很高,不太会轻易淘汰。以前我也读到过文章说做一个技术大牛,结果看着一些技术上不如自己的人升职加薪,自己就会很不爽。我觉得我们应该看到问题的背后,升职上去的人应该有更多的管理技能和通用技能,有能力协调关系、关怀员工、支持员工、让组织更加有效的运转,那仅仅作为技术大牛,有可能这些方面的价值无法提供给企业。如果你技术方面的价值真的超级大,其实也有公司会出现某个很牛的下属比上司工资还高的情况对吧。所以最后还是多多看看自己贡献的价值,而且不要仅从“写文档”这一个角度去衡量价值。咱们谈到的第二个阶段其实就已经有很多“写文档”之外的技能点要去发展了。
其实除了在公司里发展,还有很多其他的方向,比如做Freelancer,或者像我这样写写文章自爽。这些东西我了解得都不多,所以不敢评论。哪位同学有相关经验,欢迎分享。
最后的话
DIA在2011年发布了Pharmaceutical Medical Writing Competency Model,特别好地总结了MW的发展道路,我觉得我的想法和他们这个Model还挺一致的。
其实我很早就看到这个Model了,但是真的在工作中实践,过一段时间再反思、总结、再看看,最后内化成了自己的想法,我也花了很长时间。所以我鼓励大家兼听,然后形成自己的想法和职业发展思路,多多顺从自己的内心,做自己喜欢的事情。
本文仅供知识分享之目的,若存在侵权行为或疏漏,请与本平台联系,我们将及时处理!