jira替代中的父子层级，我们改了三版

我们为什么非改父子层级不可

去年秋天，一个从 Jira 迁过来的客户给我发了一段消息，大意是：“其他都还好，但父子层级这块，我宁愿你们直接照搬 Jira，哪怕照着它抄，也别乱改。”他说的“乱改”，其实是我们第一版的设计。那版设计里，我们没有照搬 epic-story-task 的硬三层，而是做了一套更自由的关联模型。结果上线后，反而收到一批投诉：有人说找不到“归属感”，有人说多级嵌套报表跑不出来，还有人说在 Jira 里花 5 分钟能搞定的事，在我们这边要拆分 6 个关联关系。我当时的第一反应是，用户不是要自由，用户是要确定感。但很快，我就发现自己只对了一半。

因为第二个月，另一批客户给了完全相反的反馈。他们说：“你们千万别学 Jira，我们就是因为它把层级绑得太死，才想换的。”同一个“父子层级”，一边嫌太自由，一边嫌太死板。这不是一个功能需求的问题，而是一个产品立场的问题。从那天起，我们就决定：父子层级这个模块，不改到对为止，绝不收手。这就是我们三版迭代的起点。

一、核心结论：大部分人搞错了“父子层级”要解决的问题

先说结论，这是我花了三版迭代才真正确认的判断：多数团队以为自己在找一个“更强大的父子层级功能”，但他们真正缺的，是一套能随项目阶段动态调整的任务组织机制。用更直白的话讲，不是你家的层级树不够深，而是你根本不该在所有场景下都依赖层级树。

Jira 的父子层级模型在过去十年里几乎成了行业默认标准。Epic 在最顶层，Story 在中间，Sub-task 在底部。这条链路上任何一点的变化，都会向下传导。如果你只在单个 Scrum 团队里做标准迭代，这个模型没什么问题。但问题出在，大多数百人以上的组织，研发场景根本不是“一个团队、一个 backlog、一个迭代节奏”这样干净。一旦跨团队协作、跨版本复用、甚至跨项目追溯，Jira 的层级模型就会从“约束力”变成“锁死力”。

我们内部做过一个统计（基于 2024 年 PingCode 迁移项目的样本数据，样本量 73 个团队，团队规模均在 30 人以上）：在从 Jira 迁出的团队中，有 61% 的团队在导出数据时发现，超过 20% 的子任务与父任务分属不同的版本发布计划，但他们从未在 Jira 里显式管理过这种关系。换句话说，层级还在，但业务逻辑已经跑偏了。这个比例比我们预期的要高得多，也直接推翻了“标准三层结构能覆盖大多数场景”这个假设。

所以我们的核心结论很明确：父子层级的问题，不能通过“做更好的父子层级”来解决。你要么把它做成一刀切的硬结构（像 Jira），扛住简单场景但牺牲复杂场景；你要么把它做成纯关联网络（像某些新一代工具），扛住复杂场景但在简单场景下让人困惑。无论走哪边，只要你还叫它“父子层级”，你就已经把自己锁进了一个非此即彼的错误选择里。我们改到第三版才想明白这一点，代价不小，但值得。

二、一个被反复误判的需求：从一通电话说起

2024 年 3 月，我接到一个老客户的电话。他们是一家 150 人左右的 SaaS 公司，产品、研发、测试、运维四个团队共用一套工具。在 Jira 时代，他们建了 12 个项目，每个项目有自己的 Epic 层级。问题是，同一个客户需求经常在多个项目的 Epic 下都有子任务。比如一个“优化导出性能”的需求，后端在 A 项目的 Epic 下有一个故事，前端在 B 项目的 Epic 下有一个故事，数据迁移脚本又在 C 项目下还有一个故事。这三个故事本质上是一件事，但在 Jira 里，它们分属三个不同的父级，互不可见。

他们当时的解决方案是，手动建了一个 confluence 页面，把所有跨项目的子任务链接贴在一起，每周开同步会的时候对着页面一个一个过。这个工作持续了将近两年，直到 confluence 页面长到要分页维护，他们终于受不了了。迁移到 PingCode 的时候，他们提出的第一个需求就是：“你们能不能让一个子任务同时挂在两个父级下面？”

如果你是产品经理，听到这个需求，你会怎么做？一年前的我会说：“这违反了数据库的树结构，做不到。”但一年后的我会反问回去：“为什么你觉得它必须是树？”这个问题是关键。Jira 把它做成了树，不代表你也要做成树。用户要的是“多个视角都能看到同一件事”，而不是“你帮我把这棵树画得更好看”。这是两种完全不同的需求理解方式。前一种理解会让你去优化 UI、增加筛选器、做更好的层级可视化；后一种理解才会让你真的去动底层的数据模型。

三、市面上常见的三种“替代方案”为什么不够用

在详细讲我们自己的三版迭代之前，先看一下市面上主流工具的解法。各家处理父子层级的方式，大致可以归为三类：

1. 照搬 Jira 的硬三层结构

这是最常见的做法。Epic – Story – Sub-task，三级，层级严格，生命周期绑定。优势是用户不用重新学习，从 Jira 迁过来几乎零切换成本。但问题也原封不动搬过来了：层级越深，变更成本越高。当一个 Epic 下有 40 个 Story，每个 Story 下又有 5 个子任务，总共 200 个节点时，任何一次版本计划的调整都要牵动整个树。而且 Jira 本身对跨项目的层级关联支持很弱，Epic 只能在一个项目内，不能跨项目引用。这就回到了我前面讲的客户电话场景：多团队协作一上来，层级就塌了。

2. 去掉层级，只做标签或看板列

另一类工具走向相反方向：不做任何层级，所有任务平铺，靠标签、看板列或者自定义字段来组织。Trello 是典型代表，Asana 和 Monday.com 在早期也偏这个路子。优点是足够灵活，想怎么组合都行。但缺点同样致命：当任务数量超过 100 个时，平铺结构会让管理者的认知负载急剧上升。你脑子里要同时记住 15 个标签的含义、8 个看板列的状态映射、以及哪些卡片是同一件事的不同拆分。这在小团队或者非研发场景下可能还行，但在研发管理里，缺少层级意味着缺少天然的归并单元，做进度汇总、资源估算、版本规划都不方便。

3. 做“可配置层级”，但压给用户去设计

第三种方案是给用户自己定义层级的能力。你可以设 2 层、3 层、甚至 5 层，每层叫什么名字也可以自定义。Worktile、ClickUp 都走了这条路。思路没错，但落地时有一个被低估的问题：给用户选择权不等于帮用户做了决策。我见过不止一个团队在迁移时花了一周时间争论“到底应该设三层还是四层”“Feature 算不算一级”。这个争论本身不产生业务价值，它只是在消耗决策带宽。而且一旦设定了层级深度，后续要改的成本很高，已经存了几千条任务的项目，谁敢轻易把三层改成四层？

这三类方案各有逻辑，但都绕开了一个核心问题：父子关系的刚性与弹性比例，不应该由工具厂商预设好，也不应该扔给用户自己去从零定义，而应该根据任务的协作状态自动调整。这个认知是我们踩了三次坑才摸索出来的。

四、第一版：我们想做一个“更聪明的Jira”，结果做了一个“更绕的Jira”

第一版的设计思路很直接：我们要兼容 Jira 的层级概念，但做得更灵活。怎么灵活呢？我们引入了“工作项类型”和“工作项关系”分离的模型。

在 Jira 里，你的工作项类型是 Story，那它天然就是 Epic 的子级。类型决定了层级位置。这个映射是写死在系统里的。我们觉得这太僵了，于是把类型和关系解耦：你可以创建一个“需求”类型的工作项，然后手动指定它的父级是什么，可以是另一个需求，也可以是一个特性，还可以是一个任务。理论上，这让你可以在任何两个工作项之间建立父子关系，不受类型限制。

听起来很强大，对吧？上线首月，我们收到了 43 条关于父子层级的工单反馈。其中 28 条是负面反馈。我把这 28 条翻来覆去看了三遍，总结出三类问题：

• 操作路径太长：用户创建一个子任务，需要额外多点击三次才能绑定父级。在 Jira 里，你在 Epic 详情页直接创建 Story，关系自动生成。我们要先创建、再关联。多出来的两步，在每天高频操作下会被无限放大。
• 层级视觉被弱化：因为我们允许任意类型互相关联，树结构在 UI 上变得更难展示。用户看不到一眼就能理解的层级关系，必须点进关系图才能看清全貌。而大多数用户根本不点关系图。
• 默认行为与用户预期不符：在 Jira 里，父任务完成时子任务会自动提示。我们的第一版没做这个触发逻辑，理由是“关联系系不等于生命周期绑定”。但用户不买账，他们觉得既然你叫它父子，就应该有“父完成则子收敛”的行为。

第一版的核心错误在于：我们把“灵活性”做成了“无约束”。用户要的不是绝对的自由度，而是有边界的弹性。你给他无限自由，他反而不知道该往哪走。这是产品设计里很反直觉的一点：限制本身也是一种服务。

五、第二版：我们矫枉过正，把层级锁死了

第一版的反馈让我们意识到“太自由了不行”，于是第二版我们往回收。这次的做法是：

• 恢复了“需求-任务-子任务”的三层默认结构（对应 Jira 的 Epic-Story-Sub-task）。
• 子任务的生命周期与父任务强绑定，父任务完成时，所有子任务必须已完成或主动解除绑定。
• 跨项目不允许建立父子关系，所有层级必须在同一项目空间内。
• 层级深度固定为三层，不允许突破。

这个版本上线后，之前投诉“太自由”的用户安静了。但新的问题来了，3 个月后，我们开始收到另一种投诉。这次来自项目经理和 PMO 角色居多。典型反馈是：“我们的一个 Epic 可能要跨越两个版本才能做完，中间有一部分子任务先上线，另一部分留在下个版本。按你们现在的逻辑，要么我把 Epic 拆成两个，要么我接受子任务被锁在父级下面出不来。两个方案都很蠢。”

还有一个更具体的场景：一个 80 人的研发中心，同时跑 6 个并行的项目。其中有一个“公共组件升级”任务，它同时服务于 A 项目和 B 项目。在 Jira 时代，他们被迫在两个项目下分别建同名的 Story，然后靠注释互相引用。迁移到我们第二版时，用户强烈要求“只建一个任务，让它同时出现在两个项目的视图里”。但我们当时的设计是任务只能属于一个项目，因为父子层级强制在项目空间内。

这两个问题指向同一个根因：在现实研发中，“归属关系”和“协作关系”是两条独立的维度。一个子任务在组织上可能归属于某个父级（归属关系），但在执行上它需要与多个上下文发生关联（协作关系）。当你的系统只支持归属关系，而用户需要同时表达两种关系时，层级就变成了枷锁。

第二版本质上是在用一个 1990 年代的树结构思维，去套一个 2020 年代的多团队并行协作现实。树结构假设一个节点只有一个父节点，但现实中的任务经常有多个利益相关方，每个利益相关方都希望从自己的视角看到这个任务。你不能要求用户去迁就数据结构的限制，而是应该让数据结构去适应协作形态。

六、第三版：我们放弃“父子”，选择“归属+视角”双模型

第三版是我们想得最久、内部争论也最激烈的一版。核心分歧在于：要不要彻底放弃“父子”这个概念？反对的一方认为，父子层级是 Jira 用户最熟悉的心智模型，扔掉它等于自断迁移路径。支持的一方认为，只要“父子”这个词还在，用户就会天然期待树结构的所有行为，我们就永远跳不出前面两版的左右摇摆。

最终我们做了一个折中但关键的设计决策：保留“父级归属”作为主关系，但把它从“强约束”降级为“默认建议”；同时引入“关联上下文”作为独立的第二视图维度。具体来说：

1. 父级归属：从“强制绑定”变为“默认继承”

每一个工作项仍然可以指定一个父级，这个父级决定了它的默认归属项目、默认版本、默认负责人继承规则。但与第二版不同的是：子任务可以选择“脱离父级版本计划”，在不解除归属关系的前提下，被分配到不同的迭代中。父级不再锁死子任务的发布节奏。当父任务被标记完成时，系统会检查子任务状态，但允许用户显式选择“子任务延后完成并移入下个版本”，这个操作会被记录在变更日志里，而不是被拦截。

2. 关联上下文：一个任务可以出现在多个视图里

这是第三版里最核心的创新。我们给每个工作项增加了一个“关联上下文”属性，允许一个任务同时与多个父级上下文发生关联，不限于同项目，不限于同类型。一个“性能优化”任务可以同时关联到“用户端 3.0 需求”和“技术债清理专项”，在这两个上下文里它都作为子任务显示。但底层只有一条数据，不同视图看到的是同一个任务的多个投影。

这个设计的关键约束是：只有一个是“主归属”，其余的关联关系不影响任务的基本属性（负责人、工时统计、版本归属），只影响可见性和筛选视图。这样既解决了“多团队看到同一任务”的需求，又避免了多重归属导致的统计混乱。

3. 视图层做减法：三层够用，但不强制三层

第三版默认提供三个组织层级（对应需求-任务-子任务），但这三层不是数据库约束，而是 UI 层的默认展开层级。实际数据可以更深或更浅。如果一个任务不需要子任务，它就是叶子节点，不影响其他功能。如果某个需求下面嵌套了四层（需求→任务→子任务→子子任务），系统不会阻止，但会在超过三层时提示用户“超过三层可能影响报表聚合的清晰度”，而不是硬阻断。

这个设计的哲学是：工具应该给建议，而不是做审批。我们相信交付团队有能力判断自己需要几层，当他们真的需要第四层时，通常是因为有充足的理由，而不是滥用层级。

七、从 Jira 迁到第三版：五个你不能照搬的经验

这一段我专门写给正在考虑从 Jira 迁出的团队。过去一年，我直接参与了 40 多个迁移项目，其中 100 人以上的团队占了一半以上。关于“父子层级迁移”，我总结出五条没有写在帮助文档里的经验：

1. 先清层级债，再迁移数据

Jira 里很多团队的层级关系是多年积累下来的“脏数据”。一个 Epic 下面可能挂着三年前就废弃的 Story，有些子任务和父任务的逻辑关系早就不成立了，但没人清理。迁移是对数据模型做体检的最好时机。我们会在迁移前给客户跑一份“层级健康度报告”：列出所有子任务与父任务跨版本超过 6 个月且仍在“进行中”状态的条目。这些条目大概率是僵尸数据，清掉之后再迁移，新系统才能跑得清爽。

2. Epic 不是项目管理的基本单元，别按 Epic 规划迁移

很多客户一开始的想法是“按 Epic 为单位一批一批迁”。但这个策略在实操中很容易翻车。因为一个 Epic 下的 Story 可能引用另一个 Epic 的组件，形成网状依赖。按 Epic 迁移会打断这些跨 Epic 的引用关系。更好的做法是按版本发布计划来规划迁移批次：把一个确定要在近期发布的版本所涉及的所有工作项一次性迁过来，不管它们分属哪个 Epic。

3. 迁移过程中，暂时不要引入“关联上下文”

第三版的“关联上下文”功能虽然强大，但迁移期间建议先关掉。原因很简单：用户在适应新系统的前两周，心智模型还停留在 Jira 的树结构里。这时候如果同时推出一个全新的多视图概念，只会增加认知混乱。我们通常建议迁移后稳定使用一个月以上，再逐步开放关联上下文功能。这个节奏控制对用户接受度影响很大。

4. 三层够用，但别在迁移时压缩层级

有些团队在 Jira 里设了四层甚至五层（靠自定义问题类型实现），迁移时客户经理可能会建议“压缩到三层吧，管理起来更简单”。我建议不要这样做。迁移期间的第一原则是数据结构保持不变，业务逻辑先跑通。层级压缩应该放在迁移完成后的优化阶段，由团队自己决定是否精简，而不是在迁移这个本身就充满变数的阶段再叠加一个结构变更。

5. 迁移后的第一个迭代，专门留出“层级纠错”缓冲

无论迁移工具多完善，总有一些关联关系是 Jira 里隐式存在的、导出文件里没有的。比如两个 Story 之间靠 comments 互相关联，这在 Jira 导出里不体现。所以在迁移后的第一个迭代里，我们建议 Sprint 排期减少 20% 的容量，把省出来的时间专门用来让团队成员检查和修正任务关联关系。这 20% 的缓冲是你花在“数据校准”上的必要投资，能避免后续无数次的返工。

八、不同类型团队的使用建议：没有万能配置，只有匹配配置

第三版上线后，我们观察到不同团队在父子层级的使用上分化出几种典型模式。这里给出四类常见场景的建议：

1. 纯 Scrum 小队（8-15 人，单一产品线）

建议：用默认三层就够了，不开关联上下文。这个规模下，标准的“需求-任务-子任务”三层完全可以覆盖日常运作。额外引入关联上下文只会让看板变复杂，ROI 不高。你的精力应该花在维护 backlog 的健康度上，而不是设计层级结构。

2. 多 Scrum 团队协同（30-80 人，多组件多服务）

建议：保持三层结构，在跨团队共享组件上启用关联上下文。这是关联上下文最具价值的场景之一。一个底层服务升级任务，同时挂到各消费端团队的视图下，各团队在自己的看板里能看到这件任务的进展，但主归属只在一处，底层服务团队。这种“一处维护、多处可见”的模式，正好击中了 Jira 做不动的痛点。

3. 研发+运维+测试混合组织（80-150 人，有固定发版节奏）

建议：三层结构+全团队启用关联上下文+自定义“发布视角”。对于这种规模的团队，建议在默认三层之外，额外创建按“发布版本”组织的固定视图。这个视图本质上是一个虚拟的关联上下文，把所有与本次发布相关的任务，不管它们在哪个项目、哪个需求层级下，聚合到一个看板里。发布经理在这里看到的是发布的全景图，而不需要在多个项目间跳转。

4. 大型产品矩阵组织（150 人以上，多个产品线并行）

建议：在组织层面统一层级命名规范，但在项目层面允许差异化配置。150 人以上的组织，不能追求所有的项目用同一套层级模板。有些偏硬件或偏基础设施的项目可能需要四层，有些偏前端应用的可能两层就够。但命名需要强约束，全公司范围内的“需求”层含义必须一致，否则跨项目报表无法聚合。PingCode 在服务这类客户时，通常会在实施阶段帮助客户定义一套“组织级工作项类型字典”，项目团队在这套字典基础上可以使用不同的层级深度，但类型的语义是全公司一致的。

九、三个自我检查：你的团队用对父子层级了吗

不管你用不用 PingCode，如果你现在正在用 Jira 或任何一款项目管理工具，下面三个自检问题可以帮助你判断当前的父子层级设置是否健康：

1. 你的子任务经常需要“先于父任务完成”吗？

如果答案是“是”，而你当前的工具要求子任务必须在父任务完成前关闭，那说明你的层级模型和业务节奏已经错配了。健康的做法是允许子任务脱离父任务的生命周期独立流转，但保留归属关系用于追溯。错配长期存在的后果是，项目经理会在工具外建 Excel 来追踪实际进度，工具里的层级信息沦为摆设。

2. 你需要在两个地方维护同一件事的进度吗？

如果你发现自己在周报里手动汇总“那个跨了三个项目的需求进展怎么样了”，说明你的工具不支持跨上下文的关联视图。这是一个高频信号，一旦出现，不要用人力去补工具的缺口，人的记忆力远比你以为的更脆弱。第 30 周的时候你还能记住跨了哪三个项目，第 50 周的时候一定记不全。

3. 新增一个层级需要几层审批？

这个问题听起来像段子，但它很严肃。如果你团队里有人想加一个“技术调研”作为某一层的子类型，但需要 PMO 审批、工具管理员改配置、全团队发通知，那你的工具把组织决策成本转嫁到了功能操作上。一个良性的配置机制应该让团队在一到两个迭代内自主完成层级调整的试运行，而不需要启动一个变更流程。

以上三个问题，如果你有两个以上的答案是“是”，那你很可能需要重新审视当前工具的层级模型是否匹配你的团队阶段。

十、我们踩过的三个最大的坑

写到这里，我想把三版迭代中教训最深的三件事单独拎出来。它们不是功能设计层面的细节，而是产品决策层面的反思，每一个都曾让我们付出了真实客户流失或声誉损伤的代价。

1. 把“兼容Jira”当作目标本身，而不是手段

第一版到第二版之间，我们内部反复出现一个论点：“用户从 Jira 过来，我们先别动他们的习惯。”这句话听起来很用户导向，但实际上它是懒惰的借口。兼容 Jira 的目的是降低迁移阻力，而不是把 Jira 的设计缺陷也一起继承过来。如果用户离开 Jira 的原因之一就是层级太死，那你做一个更快的 Jira 有什么意义？兼容是入口，改进才是价值。现在我们在评审每一个“兼容 Jira”的需求时，都会追问一句：“这个功能的存在，是在帮用户延续旧习惯，还是在帮用户建立更好的新习惯？”如果答案是前者，我们至少会把优先级降一档。

2. 用少数人的声音代表多数人的需求

第一版上线后，那 28 条负面反馈让我们快速推翻了自己的设计，转而走向第二版的强约束。但事后复盘发现，那 28 条反馈中，有 19 条来自同一个行业、同一类规模（50 人以下、单项目团队）的用户。这些人确实被第一版伤害了，但他们不能代表全部用户。我们当时的错误是：把最大声的反馈当成了最多的反馈。沉默的大多数可能觉得第一版还能接受，但他们的声音没有出现在工单系统里。现在我们做版本迭代时，会强制要求 PM 同时查看三个数据源：工单反馈、产品内 NPS 弹窗数据、以及沉默用户的留存行为数据。三个数据源交叉验证，才允许进入决策流程。

3. 低估了“概念迁移”的教育成本

第三版引入的“关联上下文”概念，在内部测试时被我们寄予厚望。但上线首月的数据泼了一盆冷水：只有 12% 的活跃团队主动启用了这个功能。我们后来做了用户访谈，发现很多用户根本没注意到这个功能，注意到的人也不知道它具体能解决什么问题。新概念如果没有配套的“触发场景”，就等于不存在。后来我们改了两件事：一是在用户执行“跨项目复制任务”时主动弹出提示“是否需要建立关联上下文（而非复制一份新数据）”；二是在迁移服务中增加了专门的一个环节，由客户成功经理带着客户跑一遍“关联上下文”的真实场景演示。三个月后，启用率爬到了 38%。

十一、回到最初的问题：Jira 的父子层级真的需要被“替代”吗

写到最后，我想抛出一个可能让这篇长文显得“白写了”的观点：Jira 的父子层级并没有做错，它只是被放在了错误的位置上。

对于 Atlassian 服务的海外中大型企业市场（通常有强大的 PMO 和标准化流程），硬三层结构带来的约束力恰恰是价值所在，它强迫团队规范使用，避免各自为政。但在中国市场，研发组织的形态更多样：有自研和外包混合的，有多个小团队松散耦合的，有项目制和产品制并行的。在这种情况下，Jira 的层级模型就显得过于“重”，不是因为功能不好，而是因为它假设的协作环境比实际环境更整齐。

所以，父子层级的“替代”，替代的不是功能，而是对它背后那套假设的重新定义。我们花了三版迭代，最终交付的不是一个“更好的层级树”，而是一个承认混乱、接纳混乱、在混乱中提供秩序的工作项关系模型。这个模型的核心只有两句话：

• 每个任务需要有一个主归属，用来回答“这件事归谁管”。
• 每个任务可以有多个关联上下文，用来回答“还有谁需要看到这件事”。

这两个问题合在一起，才是现实世界中“父子层级”应该提供的完整答案。

十二、下一步行动：怎么验证你的团队需要哪种方案

如果你已经读到了这里，我建议你做三件事，而不是立刻去改配置：

1. 花一周时间记录“层级痛点”：每次你或你的团队成员因为任务层级关系而多做了一个操作、多开了一次会、多解释了一句上下文，把它记下来。一周后看看这些记录，判断痛点的集中类型，是“子任务被锁死无法独立流转”？还是“跨项目任务重复创建”？还是“层级太深找不到东西”？三类痛点对应三种不同的解法。
2. 找三个不同类型的团队成员聊一次：一个一线开发、一个项目经理、一个 PMO 或团队管理者。同样的问题问三个人：“你能在 10 秒内找到你自己负责的所有子任务吗？”听他们的回答，注意他们找的路径。你会发现三个角色对“找到任务”这件事的理解完全不同。这个差异就是你工具选择的第一依据。
3. 用最小成本做一次配置实验：如果你用的是支持自定义层级的工具，选一个活跃度中等的项目，调整它的层级深度或关联规则，跑两个迭代。然后对比实验前后两组数据，任务完成周期是否缩短？跨项目沟通是否减少？不要凭感觉决策，要看数据。

父子层级是一个看起来很小、改起来很痛、但改对了收益巨大的模块。它不值得你花三个月去争论“应该三层还是四层”，但它值得你花三天时间去观察你的团队到底是怎么协作的。工具配置永远是协作模式的投影，而不是反过来。搞清楚你的团队是怎么协作的，答案自己就会浮现。