Linear 发布大型工作区团队结构最佳实践

Linear：Now·2026-11-10 20:11· 3 小时前AI 评分40

Linear 中大型工作区团队结构的最佳实践

AI 导读

Linear 发布大型工作区团队结构最佳实践，建议围绕有意义的边界创建团队，并用父子团队层级让子团队继承部分工作流、独立配置其余流程。团队默认公开，私有团队用于 HR、客户数据等敏感工作，受限子团队对父团队成员可见。父团队可统一定义周期、状态、估算和标签，供子团队自动沿用。

正文 · 原文

随着组织发展，团队需要灵活地以适合自身的方式工作，同时不使跨公司协作变得困难。以下是在 Linear 中构建团队结构，并建立兼顾自主性与一致性的共享标准和工作流的方法。

围绕有意义的边界创建团队

团队是 Linear 中组织人员的主要方式，通常代表经常一起工作的人群。团队可以独立存在，也可以组织成层级结构，由父团队在其下嵌套子团队。子团队从父团队继承某些工作流，同时独立配置其他工作流，使组织的不同部分能够建立自己的流程，同时保持在一个共享结构中的连接。

使用层级结构时，将父团队视为你希望在 Linear 中代表的最广泛的人群分组，然后为其内的特定群体创建子团队。

当整个组织都在使用 Linear 时，父团队通常是主要职能组，如产品、工程、市场、运营、财务等。对于主要由产品和工程使用 Linear 的公司，父团队则可能代表产品组，如核心产品、平台和增长。

一个良好的经验法则是，从尽可能少的父团队开始，以反映组织的结构。随着时间推移增加结构，比之后拆解不必要的复杂性更容易。

添加子团队以映射运营结构

子团队可以遵循汇报线、产品领域、业务单元或人们已经熟悉的任何其他分组方式。它们为领导者提供对其下各团队的集中可见性。例如，一位负责基础设施、平台和移动端的工程经理可以使用父团队，在一个共享空间中跟踪三个子团队的工作。

判断是否需要子团队的一个有用方法是，考虑这群人是否可能有独特的工作方式。如果你主要是在对某个工作领域进行分类，那么最好在单个团队内完成。例如，如果移动端团队单独规划工作或以不同方式审查传入请求，它可能需要自己的子团队。相比之下，由同一工程团队处理的缺陷、技术债务和功能工作可以放在一起，用“缺陷”、“技术债务”和“功能”等标签区分问题。

有意识地使用团队类型

我们建议默认将团队设为公开以支持协作，但私有团队是一个重要的例外，通常用于需要严格控制访问权限的敏感工作，如人力资源事务、客户数据或高管规划。私有团队的问题只能由添加到其中的成员查看。

当私有父团队拥有子团队时，你可以更精确地控制可见性。受限子团队对父团队成员可见，成员可选择加入；私有子团队仅对明确添加的人员可见。

这些子团队适合用来建模需要自行管理团队访问权限的内部业务组。例如，如果你的公司内有一个秘密项目组，其成员可以自行加入相关子团队，而无需依赖 IT 来管理单个团队的访问权限。

在团队内统一操作规范

除了组织人员，Linear 中的团队还能帮助一群人建立共同的工作方式。当每个人遵循不同流程时，协调工作很快就会变得混乱，尤其是当 AI 承担更多工作时。共同的规范让跨团队跟踪进展更容易，也为 agent 在推进工作时提供了一致可循的结构。

以一个工程组织为例，Engineering 是父团队，其下设有 Infrastructure、Platform 和 Mobile。如果这些团队按相同的两周节奏规划工作，Engineering 可以一次性定义 cycle 排期，每个子团队都会自动遵循。他们也可以选择共享相同的 statuses 和 estimates，这样 issue 会经过相同的阶段（如“backlog”、“in-progress”和“done”），并使用相同的量表来估算工作规模或复杂度。如果他们以相同方式对 bug、技术债务和客户请求进行分类，这些 labels 可以在团队层级定义一次，并对每个子团队可用。子团队可以共享用于事件复盘等重复性工作的 templates，或共享保存的 views，以呈现每个人都需要关注的问题。

作为一般规则，只向需要它们的团队提供标签和 issue 模板。否则，它们会随着时间累积，让人们在日常工作中不得不在大量无关选项中筛选。

定义工作如何进入团队并在团队中流转

团队设置完成后，以下原则为在 Linear 中建立良好工作习惯提供指导。

将团队与工作连接起来

你希望让向团队提交工作尽可能容易，但要在保持流程简单与确保每个请求都带有足够上下文供团队采取行动之间取得平衡。由于工作经常出现在 Slack 对话中，将 Linear 连接到你的 Slack 工作区是一个自然的起点。这样人们就可以标记 Linear Agent，从一段产生了有用产品反馈的长线程中创建 issue。

当团队外的人需要提出请求时，Asks 提供了一种结构化方式，提前收集相关信息。例如，产品团队可以使用功能请求模板，询问期望的结果是什么，以及用户目前如何绕过该问题。

将请求转化为正确的后续步骤

如果任何人都能直接向你的团队提交任何事项，你的待办事项列表很可能会迅速堆积，而且没有高效的方式推动工作向前。我们的建议是让 Loops 承担其中大部分工作。例如，一个工程团队可以让一个 loop 每天审查请求，识别并标记 bug 报告，并在有明确修复方案时分配一个编码代理。如果没有明确修复方案，该 loop 可以将其发现分享给相关的代码负责人，以便他们掌握上下文并进一步处理。

Linear 内置了一些自动化功能，例如当拉取请求在 GitHub 中经历审查和合并状态变化时更新议题。这样，你的团队就不必每天事后追踪代理的工作。

利用所学改进工作流

我们建议定期跳出来审视，了解团队在哪些方面可以更高效地工作。重要议题是否卡住了？请求是否在堆积？同样的瓶颈是否反复出现？

一个好的起点是向 Linear Agent 提出这些问题。该代理可以设置视图、仪表板和 loop，帮助你了解工作流的哪些部分需要关注。例如，一个平台团队可以要求该代理识别尚未推进的高优先级 bug，并寻找常见的阻塞因素，例如修复等待同一个审查者，或工作因另一个团队的 API 变更而受阻。这些模式可以帮助团队决定是否更广泛地分担审查职责，或更早地协调依赖关系，而不是简单地催促人们关闭更多议题。

来源：Linear：Now · linear.app