英国教育部研究运营团队：从人力支持转向自助基础设施以解决规模化瓶颈

编者按：本文最初发表于 The ResearchOps Review，点击此处阅读。

研究运营（Research Operations）是一个特殊的职业。作为 ResearchOps 专业人员，我们创造价值，而这种价值往往会产生超出供给的需求，从而挤压 ResearchOps 团队支持用户研究人员的能力，形成瓶颈。成为自己成功的受害者并不罕见。

我领导英国教育部（DfE）的 ResearchOps 团队，在那里我们促成了数百项研究，并擅长回答需要专业知识的各类问题。几年前，我注意到，我们在回答研究人员的问题方面做得越好，研究人员对我们就越依赖。他们会要求我们审核他们的参与者同意书，请求协助制定招募策略，询问讨论指南的建议等等。为方法论决策提供指导通常不是 ResearchOps 的职责，但他们仍然会向我们提出这些要求。如果你是一名 ResearchOps 专业人员并以这种方式支持你的研究人员，你很可能成为他们最好的朋友。但当用户研究人员的数量增加，而你无法给予他们习惯的（并且现在觉得需要的）关注时，你很快就会变成他们最大的敌人：即他们眼中的瓶颈。

雇佣更多的 ResearchOps 专业人员来为更多研究人员提供无尽的临时协助并不是一种扩展策略；这是一种 人员配置 策略。增加人手以持续回答临时性问题并不是一个可持续的运营模式。对于 ResearchOps 专业人员来说，真正的挑战在于构建基础设施，使其无论你是支持十名还是 120 名用户研究人员都能发挥作用（作为 DfE 的一个两人 ResearchOps 团队，我们目前支持的就是这个规模）。

为了实现这种程度的可扩展性，我必须从支持或服务导向的心态转变为系统设计心态。在本文中，我将分享我们如何停止扩展一对一支持，为重复需求构建自助服务基础设施，使指导不仅具有说明性而且具备可操作性，当文档不足时重新设计流程，以及如何衡量（和报告）研究人员的自主性和流畅度，而不仅仅是活动量。

停止扩展临时支持

在 DfE，我们的大多数研究收集关于人的数据，例如：某人在学校的经历、作为平衡工作和育儿的家长的情况，或处于寄养状态的经历。因为我们的研究经常涉及儿童，所以我们非常重视合规且合乎伦理的数据收集。¹ 我们的研究人员社区过去常常就伦理和合规问题向我们提出无数疑问，范围从“我们可以使用这些数据来招募研究参与者吗？”到“如果他们已经参加过研究，还需要同意书吗？”以及“当我们招募弱势参与者时需要考虑什么？”这些问题起初很复杂，我们逐个案例进行解答。然而，模式很快显现出来，例如最常见的情况、经常被考虑的研究人员问题以及最务实的解决方案。一旦我能看到这些模式，我就意识到问答瓶颈并非由问题的性质或规模造成。相反，这是因为答案只存在于我们团队成员的脑海中。

因此，我花了两周时间编写了一份关于《通用数据保护条例》（GDPR）²的用户研究手册，该立法规定了欧洲和英国的组织（包括企业和政府部门）如何使用个人信息。手册发布后，我们收到的支持请求减少了，因为人们无需等待我们即可推进工作。但还有一个更微妙而深远的好处。当你口头解释流程时，不完美的流程尚可应付，但书面指令则不容许丝毫马虎。简而言之，写下系统使用说明有助于你发现其中的缺陷——并迫使你设计出更好的系统。

不再占用我的时间和精力，GDPR 用户研究手册让用户研究人员在需要时即可获得所需指导。随后，其他几个英国政府部门联系我们，希望借鉴并在我们的流程基础上进行建设。这一成功促使我们公开开展工作，并将手册发展为更具影响力的成果。2022年，我们创建了 DfE 用户研究手册³，这是一本公开可用的手册，包含我们所有的政策、指南、流程以及用于参与者招募的同意书和工作说明书模板。（你也可以使用它。）因此，DfE 用户研究人员不仅有一个集中查阅研究标准和学习如何改进实践的地方；他们还可以将其作为权威依据，向那些不太以用户为中心、缺乏设计意识的同事说明为何要以特定方式行事。这是一种很好的表达“这就是我们在这里做事的方式”的方法，也是整个职业群体支持的证明。

构建自助式基础设施

自手册发布以来已过去四年，我们不断学习如何更有效地支持研究人员。目前，手册正在重写，使其指导更具可操作性而非仅仅具有解释性：更多是“如何申请安全文件夹”，而不是“考虑文档的加密级别”。我们预计用户研究人员已经了解基本的文件存储知识，或者可以在 DfE 的内网上找到更多信息。相反，我们的指导需要具体化。例如，它应告知他们用户研究数据的保留期限、可以与团队内哪些人共享数据，以及当参与者要求删除其数据时应如何处理。

重点不在于指导是好的且你应该创建大量指导，而在于你构建的系统应以你的专业知识和研究人员的集体专业知识为基础设施的基础。旨在更快地给研究人员提供答案，并以增加他们知识和信心的方式进行，而不消耗你的时间或他们的注意力。这对他们来说是胜利，对你来说也是胜利：你将收到少得多的问题，从而节省时间并减少任务切换的需求。如果专业知识仅存在于一个人的头脑中，或 ResearchOps 团队的头脑中，那么研究可扩展性和你能交付的价值就达到了硬性上限。知识就是基础设施。

重新设计流程，而非建议

即使文档写得再出色，也终究有限度。最终，如果你的系统效率低下，你就需要停止完善文档，转而重新设计系统。这意味着工作重心从 ResearchOps 中的“研究”（或“研究人员”）转向了“运营”。对我们而言，这意味重新设计一项关键的数据保护流程：数据保护影响评估（DPIA）。

在法律上，启动一项研究之前，我们需要评估该研究活动是否属于高风险，如果是，则需进行影响评估。高风险研究可能涉及成千上万的人参与，或收集基因或生物识别数据。大多数 DfE 用户研究不属于高风险，但我们仍需一种可靠的方式来得出这一结论——不能仅凭感觉。

2019 年，DPIA 流程难以理解和操作。它由精通法律术语的人编写，但旨在供精通用户研究实践的人使用。例如，精通数据保护的作者会将“大量数据”定义为从数千人处收集的数据。而对用户研究员来说，“大量数据”可能意味着在一轮研究中从二十人处收集数据。两者在各自语境下都是准确的，但只有前者在 DPIA 的语境下是准确的。这种差异往往导致研究人员与其数据保护同事之间看似无休止的来回沟通。数据保护同事觉得自己在尽力落实法律要求，而研究人员却感到受阻。这是一个低效（且令人沮丧）的系统示例，仅靠更好的文档无法解决。

我们与数据保护同事密切合作，利用法律、多年关于研究与数据实际运作方式的证据，以及服务设计技术（如创建服务设计蓝图和开展共同设计工作坊），重新设计了该流程。我们还为数据保护团队提供了用户研究和以用户为中心的设计（UCD）培训，并邀请他们参加研究会议。如今，过去平均需要研究人员花费五小时的工作，现在只需几分钟即可完成。研究的合规性更高，ResearchOps 很少需要介入。

为缺席而设计，而非为在场而设计

我承认，我不擅长避免成为单点故障，但不确定的健康状况迫使我必须为那些我意外连续几周无法工作的日子做好设计。去年我做了手术，离岗三周，当我回来时，一切并未乱套。（我的自尊心受到了一点打击，但我从中得到安慰的是，我所协助建立的一些事物促成了这种独立性。）

无论是有五人还是五百人在阅读《用户研究手册》、遵循 DPIA 流程或使用我们的标准化同意书之一；无论我在不在场，流程都能顺畅运行。赋予人们独立行动的能力，是你所能做出的最有价值（且最具可扩展性）的流程变革之一。

在急于提供帮助的过程中，许多研究运营团队无意中变成了帮助人们应对故障系统的专家，希望有一天能有时间修复或关闭这些系统。但这种方法不会带来进步。更有价值的技能是退后一步，研究问题的根本原因，然后找到时间，或者争取时间和预算来解决问题。假设你无法（或不应该）完全自动化流程，请找出使流程自助化或至少低支持的方法。⁴ 例如，与其进行一对一会议，不如举办小组入职培训、预先录制一段“欢迎”视频、创建入门资料包，并每两周举行一次随到随学会议，以欢迎新成员加入团队并帮助他们安顿下来。

将限制视为设计系统的机会，这些系统不依赖于你或你的团队，而是赋予人们独立性。

用高杠杆取代高接触

对系统的需求翻倍不应导致你或你的团队的工作量翻倍。作为经验法则：按当前研究人员数量的十倍进行系统设计。这并不是因为你一定会达到那个数量，而是因为它迫使你去构建那些不依赖英雄式（不可持续的）努力、机构记忆或特定人员可用性就能完成工作的系统。还要考虑以下标准：

• 如果一个问题被问了五次以上 次，它就值得一个自助答案，无论是通过操作手册、模板、决策树还是自动化机器人。
• 如果你或团队成员是常规工作的唯一审批人，那么你在设计上就是一个瓶颈。相反，用路由系统、标准或审计来取代签字批准。
• 如果一个相对简单的流程需要花费数小时，请在向无效的系统添加更多支持指南之前重新设计它。

这种方法不是魔法，也不会自发解决研究运营的长期问题。相反，它需要进行大量的优先级排序，这有时令人不适。我们无法像以前那样为个人提供那么多帮助；我不得不停止那些为个别团队提供价值但对整个部门价值不足的服务，因为我们的带宽有限。（我不认识你也猜得到，你的带宽可能也有限。）

相反，我们优先投资于在整个部门最大化价值的系统。因为我们的系统旨在服务于大众，它们都包含一些妥协，并不完美无缝。但通过为大多数人提供“足够好”的东西，即使对少数人来说并不惊艳，我们也能向教育部整体交付更多价值。

衡量不那么明显的指标

十八个月前，我们的策略是在教育部的各个工作领域（如学校、家庭或技能）嵌入一名 ResearchOps 人员，我的团队充当“卓越中心”。我从未打算建立用于自助式 ResearchOps 的基础设施；我也没打算成为系统或服务设计师，但这正是我作为 ResearchOps 专业人士的角色演变方向。

实现这一策略花了很长时间——大约六年。在我担任 ResearchOps 的第一个职位时，需求清单无穷无尽，而且每件事似乎都具有同等的紧迫性，所以我优先处理那些我能最快完成的事情。我自己也还在摸索门道，所以做的是我熟悉的工作。然而六年过去了，我现在对 ResearchOps 的作用以及它在政府环境中的具体运作方式有了广泛的了解。因此，我经常问自己这三个问题：

1. 这个系统的具体部分如何融入研究人员的整体旅程？
2. 它将如何使 DfE 受益？
3. 如果系统两者都不满足，那可能不是正确的决定。如果它两者都满足，那么我会问自己：我们将如何衡量它的成功？

如今比以往任何时候都更重要的是，展示研究运营团队的投资回报。为了生存，你的价值必须显而易见，但说起来容易做起来难。ResearchOps 的大部分工作都是无形且基于轶事的。我有无数例子可以说明事情何时成功或失败，但它们并非以结构化数据的形式存在。过去，我曾尝试进行基准调查，但回复率很低，而且回复的人通常是最投入和最尽责的，这会使数据产生偏差。

活动不等于影响

为了衡量我们研究系统的影响，我可以做一些显而易见的事情。例如，我可以做简单的数学计算，算出通过重新思考购买研究激励措施的方式为我们节省了多少钱；我可以计算 DPIA 在新流程之前平均需要多长时间，然后乘以提交作为审计跟踪一部分的表格的人数。上个月，我们为用户研究人员节省了 37 个小时（相当于英国一个完整的工作周），而没有占用我们一分钟的时间。

这些是值得跟踪的良好指标，但我个人关注的指标不那么明显：保持电子邮件收件箱安静，能够轻松回答问题，听到研究人员说“谢谢，这太有帮助了！”的反馈，或者花一个下午的时间忽略通知，专心处理更具战略重要性的事情。

关键点在于，活动不等于影响。我不统计已关闭的工单或已完成的需求，因为它们是虚荣指标，无法传达投资回报。例如，给某人一个软件许可证并不一定意味着他们现在可以访问的软件能让他们的工作更轻松或更高效。我可以在 ResearchOps 支持频道上回答问题，但回答问题并不能解决最初提出问题的原因，也不一定防止它们再次被提出。相反，我的组织和我关心的是节省的时间量、消除的不重要决策数量，以及研究人员自主权的总体提升，从而提升速度——这是当下的热词。研究人员能够在没有无谓摩擦的情况下交付优秀的研究成果，这对我和我的团队来说才是真正的影响。

创造真正的可扩展性

因为我们现在的工作更具战略性——作为系统设计者而非系统管理员——我们得以解决积压问题，这些问题我们知道将为 DfE 带来价值并使研究人员的生活更轻松。我们重写了五篇指导文章，制作了一段鼓励人们报名参加研究的视频，并创建了内部交付研究激励措施的流程和能力。作为 ResearchOps，我们现在正在推进核心基础设施的建设，而不是勉强维持现状。

扩展研究规模并不是要完成更多任务或雇佣更多员工；而是要建立能够在需求增加、优先级变化或你或你的团队无法工作的时候仍然持续运行的系统。如果你的团队之所以能交付价值，只是因为某个人知道答案、可以批准请求或记得流程，那么你的运营就是建立在依赖关系之上的。如果在你不在场的情况下研究仍能继续运作，那么你就建立了真正可扩展的研究基础设施。

脚注： 

1. 虽然数据收集和处理必须符合相关的法律、监管和组织要求，但这些框架并不总是涵盖更广泛的道德考量。伦理为决策提供了额外的视角，并关注尊重、公平、诚实和正直等价值观。虽然伦理引导研究人员思考在特定情况下应该做什么，但合规性确立了必须满足的最低标准。

2. 数据保护立法控制着包括企业和政府部门在内的组织如何使用个人信息。在英国，数据保护受 UK General Data Protection Regulation (UK GDPR) 和 Data Protection Act 2018 管辖。

3. "User Research: Guidance and Support for Any User Researcher Working in Department for Education." User Research Manual. Department for Education, Accessed August 7, 2026. https://user-research.education.gov.uk/.

4. 在 “The Transformative Power of Automation: from Enhancing Research Efficiency to Catalyzing Strategic Change” (The ResearchOps Review, 2025) 中，Rodrigo Dalcin 分享了一个矩阵，以帮助决定何时进行自动化以及何时手动方法更为合适。

‍

‍