很多团队都纠结于产品业务需要和各种一直插入的中断请求而无法自拔，这篇文章介绍了 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 完结。
事实是，有些事不能等。合规要求、新员工入职、大客户的渺小配置变动等等，都是和相干流动关联的工作，须要在肯定工夫内实现。
在短时间内不满足这些要求可能会导致名誉受损或经营危险。
为什么预留容量会失败？
团队采取的另一种办法是投入肯定的工夫，比方冲刺的 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-… \
[2] Using tempo to avoid the chaos of agile methodologies: https://jgefroh.medium.com/using-tempo-to-avoid-the-chaos-of-… \
[3] How to design an effective intake process: https://medium.com/swlh/how-to-design-an-effective-intake-pro…你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。\
微信公众号：DeepNoMind
本文由 mdnice 多平台公布