很多团队都纠结于产品业务需求和各种不断插入的中断请求而无法自拔，这篇文章介绍了 QRF 团队模型，将产品业务开发和紧急响应团队区分开，为重要而紧急的事情提供单独的处理通道，从而帮助团队能够聚焦在重要的事情上。原文：Engineering Org Structures— The QRF Team Model[1]
为资源不足、被各种事情干扰的初创公司建立团队模型
作为团队负责人，我发现很多初创公司的产品和工程团队都在为敏捷而挣扎。
初创公司在发展早期走捷径有一定好处，但也需要付出代价。某种程度上，这会造成很多技术、能力、知识和组织债务，以至于只有工程团队能够处理持续出现的错误、内部问题和各种干扰。
来自各方的要求都希望能够被快速处理，有时之前的任务会被连续中断好几天，极大扰乱了工程师的工作。即使每次中断只需要几分钟，但单是上下文切换就能毁掉整个下午的工作效率。
工程组织怎样才能以合理的方式处理这些问题?
采用 QRF 团队模型
QRF 模型在某些环境下工作得非常好，并且没有其他方案的缺点。
什么是 QRF 团队模型？
将组织单元划分为两个分散的、独立的团队:
- 团队 1，为主要任务工作
- 团队 2，QRF 团队（快速反应小组）
团队 1 的章程很简单: 构建路线图上的内容。 他们就像一个典型的产品开发团队一样，按照路线图、可预测的节奏，基于任何合适的框架或方法（例如 Scrum 或 Kanban），致力于高价值、高优先级的项目。
简而言之，他们为公司的主要目标工作。
团队 2 的任务是处理任何可能导致团队 1 中断的项目。 他们充当 QRF，即快速反应部队，处理任何可能中断冲刺的问题。简而言之，他们防止团队 1 被干扰，并起到支持作用。
QRF 解决了在其他方法中发现的问题
其他通常采用的“敏捷”方法都有根本的缺陷，从而在某些情况下没有效果。
这些办法包括：
- 只处理有价值的工作
- 把它放到下一个冲刺阶段
- 为每个冲刺留出一定的容量/时间
为什么只做有价值的工作会造成问题？
下面哪件事情优先级更高:
- 创建用户帐户
- 一个可以产生 10 亿美元的想法
下一个十亿美元的想法总是会赢得任何关于优先级的争论，因为这是一个未知的、理想化的、容易被操纵的预测。然而，专注于新产品创意的创新意味着当前的客户得不到服务。
这是创新和运营之间的矛盾关系: 两者都需要在市场上茁壮成长，但大多数关于产品优先级的论点都低估了运营。当选择的价值呈指数级增长时，很少有产品经理愿意从事具有递增价值的项目。
这意味着，从“价值”的角度来看，内部工具、漏洞修复、自动化、技术债务等都不能被优先考虑。它们通常有一些已知的、较小的可量化价值，而这些价值与未经验证的理想化预测相比显得苍白无力。
最后，不管我们使用了多少结构化框架，确定优先级是一门艺术，而不是科学。
基于价值的优先级排序使得某些事情永远不会被完成
为什么把它放到下一个冲刺阶段会失败？
一些团队试图通过严格遵守 sprint 承诺来解决这个问题。每当出现额外的要求时，他们会说:“我们已经计划好了这个 sprint，所以会把它放到下一个 sprint 中。”
不幸的是，当下一个 sprint 到来时，在待办事项列表中有额外的 15 项需要完成。
不断重复，直到有一大堆待办事项，其中大部分都没有完成。这支团队开始被客户、公司其他人和高管团队视为缺乏灵活性。
为什么这个方式会失败？
这种方法假设事情可以等到 sprint 结束。
事实是，有些事不能等。合规要求、新员工入职、大客户的微小配置变化等等，都是和相关活动关联的工作，需要在一定时间内完成。
在短时间内不满足这些要求可能会导致声誉受损或运营风险。
“下一个 sprint”太遥远了，永远没有足够的空间存放新任务
为什么预留容量会失败？
团队采取的另一种方法是投入一定的时间，比如冲刺的 10%，或者每周的一天，来解决这些问题。
为什么这个方式会失败？
对于工作量小的干扰，这种方法有用，但对于工作量大的组织来说，就不适合了，因为占用的时间太多了。
此外，把这些工作变成“10%”的事情，会让人认为这部分工作不重要，让人分心，工程师可能没有动力去完成，导致执行这些任务时一定程度上的效率低下。
此外还有一个隐含假设，实际上可以在那个时间段内完成足够多的事情。
但实际上在很多情况下并不能完成，然后又回到了起点。
新任务可能超过计划的容量和时间段
让我们来解决真正的问题
这里真正的问题是团队的工作节奏比环境要求的慢。
如果每天收到 5 个紧急请求，但每两周才接新工作，意味着客户可能要等上 4 周才能解决问题。在创业世界里，4 周可能是一段不可接受的漫长时间。而且假设我们能够根据计划的路线图找到优先级(但通常不是这样)。
最终事情会堆积起来，客户会不高兴:“为什么设置一个配置要花一周的时间?” 用户感受会受到负面影响。
这就是 QRF 解决方案工作良好的原因——迫使工作以更快的速度进行[2]。
QRF 模式还有很多其他的好处
系统性减少上下文切换
第一个也是最重要的好处是，中断任务可以由一个专用的执行流处理。虽然团队可能会频繁切换上下文，但作为一个整体，组织最终只会在较少的重要事情中切换。
这有助于防止上下文偏离组织的主要焦点，而这些焦点应该是非紧急的、重要的工作。
最终这是一个以本地成本为代价的系统级优化。
改进组织的敏捷性和响应能力
第二个好处是提高组织对请求的感知响应能力。
许多组织执行某种形式的敏捷仪式，每两周围绕目标定义并设定工作。这意味着在最差情况下，理论上从客户提出请求到满足请求的时间最长可达 4 周。
QRF 团队为此类请求提供更快的响应时间。我曾见过有团队的前置时间（从请求到交付）只需要 3 天，这有助于提高客户满意度和服务满意度。
致力于系统维护和支持
维护是系统生命周期中成本最高的方面。由于成本很高，因此经常被延迟，而这又增加了维护系统所需的风险和工作。
QRF 有助于确保重要的维护工作（比如 bug、运维工具和其他项目）不会中断。
QRF 如何运作
运作模式
QRF 有两种运作模式：
- 反应式
- 待命式
在“反应式”模式下，QRF 团队积极灭火，解决紧急的、中断性的问题，作为防止中断的第一道防线，通过专注于解决问题来提供支持。
在“待命式”模式下，QRF 团队致力于预防性的“左移”项目或帮助其更快反应的东西。这些可以是内部工具、改进的监控/告警、提高质量、自动化、日志或审计中的可观察性——由 QRF 团队决定如何利用这段时间。
左移
QRF 最大的任务是在中断时的“左移”。他们不仅要努力做出反应，解决实际问题，而且要从一开始就避免工程领域出现的所有问题。
什么是 QRF 的左移?
每个公司和问题看起来都不一样，但一些常见的“左移”解决方案包括:
- 创建管理工具，让内部团队自己执行操作
- 修复导致工程需求的产品领域的 bug 或 UX
- 提高监控、可追溯性和可观察性，使修复工作更快完成
- 创建易于使用和导出的查询，以便其他人无需工程团队的帮助就可以查看需要的数据
- 记录常见的工程维护任务，以便其他人能够解决问题
随着时间的推移，当中断的种类左移时，作为整体的工程组织有更多的空间来关注高价值项目的执行。
同利益相关者合作
QRF 与整个组织的利益相关者紧密合作，特别是内部团队，如支持、客户成功和运营。与这些团队保持联系是很重要的，他们需要了解对工作流程的任何更改或对他们可能提出的请求的解决方案。
衡量 QRF 绩效
有几种方法可以衡量 QRF 团队的表现:
- 问题解决率 —— QRF 团队解决了多少问题?
- 周期时间和前置时间 —— 请求等待“完成”的时间是多长?
- 任务左移 —— QRF 阻止了多少种类型问题的发生?
- 中断预防 —— QRF 帮助主工作团队处理了多少任务?
所有这些都是评估 QRF 是否有效的合理方式。
问题解决率本质上是中断请求的吞吐量。换句话说，如果没有 QRF 团队，这将是主团队必须处理的中断次数。
对已完成的项目进行分类，可以对组织可能遇到的各种中断的构成和来源提供关键的见解:
- 大量的 bug 可能表明质量问题
- 大量的调查询问可能意味着可见性问题
- 大量的普通数据任务可能表明缺少内部工具
周期时间和前置时间可用于为请求者提供新请求完成的预测平均值。例如，如果最后 100 个任务的平均前置时间为 3 天，那么请求者可以预计，他们的请求平均需要 3 天。
任务左移表示 QRF 团队成功防止再次发生的离散工作流的数量或任务类别，这是一项获得主动性的预防工作。每一类可能代表几十或数百种已被预防的未来中断。
中断预防可以用来度量 QRF 团队在问题出现之前的情况，任何一项左移(例如。通过内部工具)的任务都意味着一个工程师将来都不需要解决的问题。
QRF 成功案例
一些公司已经成功实施了这个模型。
其中一个我称之为“PayCo”，它最大的问题是每天都有超过 12 个请求，而公司里只有几个关键工程师知道如何解决。他们忙于其他事情，没办法完成这些请求，因此请求不断积压，最终问题越来越大，对项目造成了严重的干扰，需要立即处理。
我刚加入时，有大量的任务和请求。我知道这不可持续，所以迅速组建了一个快速反应小组。
最初这是一项艰难的工作，我们遇到的每个问题和要求都是新的，需要很多时间找到解决方案。
不过我们明确仔细的记录了遇到的问题和解决方案，创建了详细的指南，甚至编写了将来可以使用的快速“填充”脚本。我们在工作中确定并记录了超过 40 类请求的解决方案。
从这些类别中，我们确定了关键模式:
- 某些部门由于缺乏可见性而提出了很多请求
- 一些请求者频繁询问可以在现有工具中轻松提供的信息
- 有些人只是遇到了执行问题，只要有正确的工具，他们就可以很容易的执行操作
我们实施了一系列的左移工作，并通过授权请求者自己解决问题或告诉他们解决问题的方法，完全消除了 25 种类型的请求。
我们从每天处理和解决 10 几个中断请求，在短短两个季度内减少到每周收到不超过 3 个请求，最终，QRF 团队不需要作为问题的第一响应接口，而是只需要响应其他团队解决不了的问题。
实施建议
为了使 QRF 成功，需要组织做出如下承诺。
QRF 必须有自己的接收和优先排序
这意味着其他团队不能告诉 QRF 该做什么，而是由其自身根据预防干扰及其能力进行选择。
QRF 不能有路线图或 backlog
QRF 的全部意义在于迅速反应，如果有一堆必须完成的任务，就无法反应迅速。团队应该总是能够自由的放下手头的工作去做其他需要做的事情。
QRF 必须有权解决问题
必须能够与利益相关者和其他部门直接合作来解决问题，这些问题可能包括过程更改、接口调整或工具的引入。任何许可限制都只是增加了等待时间和延迟，这使得团队的响应更少，中断更紧急。
QRF 必须是具有高度主动性、适应性和注重细节的多面手
团队中需要有这样的工程师: 他们喜欢做不同的事情，钻研问题，与利益相关者一起工作，在没有支持的情况下记录和跟踪解决方案。否则，他们将很难影响变更、收集信息以及与公司共享更大的解决方案。
公司必须将请求收集到中心位置
只有当 QRF 能够容易的识别符合其操作参数的请求并能够识别长期请求模式时，才能够有效工作。只有当请求以一致且可见的方式提出时，才能做到这一点。
简而言之，QRF 不能对不知道的请求做出回应。
如果还没有正式的请求处理流程，那就建一个![3]
QRF 成员必须提供完整、清晰的文档
QRF 的工作之一是发现如何解决问题，并且只需要解决一次，这通常意味着需要写下解决步骤，并在公司内共享，从而可以为这一问题模式建立预案。
如果 QRF 团队中有人讨厌文档，那么这个团队最终会一次又一次的解决同样的问题。
避免工程师短期轮岗
要想在 QRF 运作模型中发挥作用需要一定的熟悉度，而这是无法在几周内就能建立起来的。团队需要能够追踪线索，与利益相关者沟通，识别左移模式。每隔几周就换掉一名工程师，就没办法建立起相关经验。
设置响应 SLA
快速反应机制的全部意义在于提供及时的响应，因此需要让团队承诺响应服务级别协议。
类似“我们将在 48 小时内回复所有请求”之类的话将有助于防止 QRF 变成不可预测的黑洞。请注意，响应并不一定意味着解决，只意味着人们可以知道是否会被 QRF 接收。
常见问题
那不是 bug 小组吗?
人们很容易认为“哦，这是一个 bug 团队”，但这并不是事实。
是的，通常是作为修复大量 bug 的团队开始，但是 QRF 在优先级划分上不一样。Bug 团队根据 Bug 的重要性进行优先级排序，并且只处理 Bug。
而 QRF 根据中断和效率低下的程度进行优先排序，可能会处理根本不是 bug 的项目。他们的工作是防止中断，而不是修复 bug。这可能意味着会让一些错误发生并保留在系统中，从而为另一个中断创建长期的预防解决方案。
如何激励工程师去做这些小东西?
自驱和感激。
QRF 的关键是允许无限自治，这对许多工程师来说很有吸引力。只要完成了响应 SLA，团队中的工程师基本上自己可以决定在待命期间做什么。
一开始不会有很多待命时间，但最终会在一个紧急事项和下一个紧急事项之间有足够的空余时间，工程师可以借此扩大影响力。
由于请求的性质，QRF 也是一个团队，可以直接与需要帮助的人进行互动。一些工程师发现，部署修复程序或工具，并有机会立即与从中受益最多的人交谈，是一件令人难以置信的充满激励的事情。尽管许多产品开发团队都在谈论客户协作，但仍有太多的团队继续将工程师与用户隔离开来，从而使得这样的机会成为例外，而不是常态。
但必须承认，QRF 并不适合所有人。如果工程师只想埋头编写代码，不要让他们加入 QRF 团队。
QRF 需要采用 Scrum 吗？
不。Scrum 的优先排序节奏可能太长了。QRF 可能会根据问题严重情况每天调整优先级，有时甚至一天几次。这就是它的强大之处，这是它的承诺。Scrum 的做法正好相反，它创建了一个几乎不可改变的契约，规定(理想情况下)重新确定优先级只应该在 sprint 结束时进行。
建议 QRF 采用基于拉的运作模型，如看板。看板工作得很好，有助于限制进行中的工作，减少批量大小，使工作可见，并且阻塞的工作可以通过集体智慧合作解决。
如果 QRF 没有东西可做，会发生什么?
他们从事预防性工作、左移工作或其他具有杠杆效应的工作，实际上由团队成员的自由裁量权决定。唯一要求是及时响应和处理问题，使队列尽可能清晰。
这意味着不要进行大规模的、需要几个月完成的项目，要确保交付的任务是迭代、增量完成的，可以在任何时候放弃或中断。
不太可能发生的情况是，QRF 真的没有任务需要处理了，这意味着他们完成了自己的工作！接下来可以平稳过渡为内部支持团队、开发体验团队，或者合并到其他团队。
这难道不是增加了额外步骤的容量承诺吗?
如果纯粹从工程能力的角度来看，那么，是的。然而，这个比较过于简单了，如果把同样的能力放在普通的产品团队中，并不会得到同样的结果。
这是因为 QRF 的关键组成部分其运作方式，与公司中其他工程团队的运作方式完全不同。从长远来看，团队专注于预防问题比部分注意力模式更有助于减少未来的干扰，无限自主的激励机制有助于激励和留住在该模型中工作的工程师。
QRF 团队需要多少工程师?
具体问题具体分析，这个模型可以只适用于一个小团队的单个工程师，或者可以是几个工程师组成的团队。重要的部分是检查中断请求率，并确保 QRF 有适当的工作人员，以防止出现大量请求。
如果团队需要一个比主工作团队更大的 QRF，这很可能意味着更大的、上游的、可能是跨职能的组织问题，这些问题需要被左移，例如连续出现差劲的需求、技术质量，或者优先级排序流程等。
环境很重要
QRF 模型可能是非常有效的，但请记住: 没有任何灵丹妙药可以在每种情况下都有效，这取决于团队背景和情况。
我发现这种模式在以下环境中取得了巨大的成功:
- 工程团队经常在高度紧急的环境中被中断
- 这种复杂性使得 QRF 能够快速进入各个区域
- 优先级框架不重视运维需求
- 处理这项工作的资源很少
- 请求如果被实际完成，慢慢的就会体现出价值
这种模式可能不会在以下环境中产生作用:
- 干扰的请求真的不重要
- 这些干扰请求经常会变成有意义的战略需求
- 解决方案需要高度专业化的知识或经验
- 组织有足够的能力和资源可以集中处理请求
- 有成熟的优先级排序流程，可以将业务需求和创新综合考虑在内
环境很重要。一篇文章并不能解决问题，最多只能提供一个可以应用的心理模型，在评估了环境和需求后，可能会发现需要修改这个模型。QRF 模型很有可能会解决你的问题，但也有可能没有任何帮助，只有自己知道什么才是最好的。
References:
[1] Engineering Org Structures— The QRF Team Model: https://betterprogramming.pub/engineering-org-structures-the-qrf-team-model-7b92031db33c
[2] Using tempo to avoid the chaos of agile methodologies: https://jgefroh.medium.com/using-tempo-to-avoid-the-chaos-of-agile-methodologies-cb213a84652c
[3] How to design an effective intake process: https://medium.com/swlh/how-to-design-an-effective-intake-process-cba0b98be4d4
