任务依赖如何做好依赖冲突？项目负责人制度设计与操作步骤

2021 年我接手过一个跨 5 个团队、峰值 140 多人的平台重构项目。上线前 6 周，我在依赖关系表里发现了一个荒唐的事实：一个核心接口的改造，前前后后挂了 9 天，而真正干活的时间只有 1.5 天。剩下的 7.5 天，团队在等另一个团队的接口冻结、等安全评审的窗口、等一个"到底谁说了算"的答复。项目延期 23 天，没有任何一个环节是"某个人偷懒"，但每一个环节都在消耗时间。这就是依赖冲突最真实的形态，它不是某个人掉链子，而是责任在交接处蒸发了。

这篇文章要回答的就是：当任务依赖不可避免地产生冲突时，项目负责人制度该怎么设计，才能让冲突有归属、有响应、有出口。

一、先把结论说清楚：依赖冲突是制度问题，不是排期问题

很多人问我依赖冲突怎么解，我通常不会先谈工具，而是先给三句话。第一，依赖冲突的 80% 不是排期冲突，而是责任归属冲突。排期只是冲突的表现形式，真正卡住的是"这件事归谁拍板、什么时候拍板、拍不了往哪升级"。第二，依赖不会自动消失，它只会从显性等待变成隐性返工。你不登记它，它就在邮件里、在群里、在某个人脑子里。第三，项目负责人制度的核心不是多一个管理者，而是多一个"依赖的所有者"。

我见过太多团队把依赖冲突当成"时间管理没做好"，于是加班加点重排甘特图、增加周会频次、要求每日同步进度。这些动作我都做过，效果都很有限，因为它们没有触及问题的根源，当 A 任务必须等 B 任务，而 A 和 B 不属于同一个人时，没有人对"等待"这件事本身负责。

1. 我对"依赖冲突"的定义边界

为了避免讨论失焦，我先界定清楚：依赖冲突指的是两个及以上任务之间存在前置约束，且约束的满足条件、时间窗口或资源分配无法由任务执行者单方面决定，从而产生等待、返工或资源抢占的状态。注意这里的关键词是"无法单方面决定"。如果一个任务能被执行者自己搞定，它就不是依赖冲突，只是工作量问题。

这个定义会带来一个很实用的推论：凡是依赖冲突，必然存在一个跨边界的决策点；凡是跨边界的决策点，就必须有一个明确的人来关掉它。项目负责人制度，本质上就是为这些跨边界决策点设置责任人。

2. 项目负责人制度不等于项目经理岗位

我必须澄清一个常见误解。项目负责人制度不是"再招一个项目经理"，也不是"给现有 PM 加个头衔"。它是一套授权结构 + 责任映射 + 升级路径的组合。在小团队里，它可能就是一个人兼着；在中大型组织里，它可能是一层常设角色加一套分级机制。

判断你有没有真正建立起这套制度，我看三个信号：

• 可指名性：随便挑一个跨团队依赖，能在 30 秒内说出唯一负责人姓名，而不是"应该是他们团队吧"。
• 可升级性：负责人协调失败时，他知道在第几天、向谁、用什么格式升级，并且升级后能拿到明确答复。
• 可回溯性：一个依赖最终延期了，复盘时能查到它在哪一步、被谁、因为什么卡住，而不是"沟通不畅"。

这三个信号如果没有同时成立，说明制度还是纸面的。

二、依赖冲突到底怎么发生的：四类依赖与三个真实场景

不做分类的讨论都是空谈。我把实际项目里遇到的依赖分成四类，它们的冲突机制完全不同，对应的负责人职责也完全不同。很多团队用同一套流程去管四类依赖，结果就是哪一类都管不好。

1. 四类依赖及其冲突触发点

资源依赖：两个任务需要同一个稀缺资源（同一个人、同一台测试环境、同一个预算池）。冲突触发点是"抢占"，表现为排期打架。时序依赖：B 必须在 A 完成后才能开始。冲突触发点是"等待"，表现为链路拉长。信息依赖：B 需要 A 的接口定义、数据口径或设计稿才能动手。冲突触发点是"信息不对称"，表现为做完才发现要返工。审批依赖：任务需要跨出团队的外部放行（安全评审、法务、上级决策）。冲突触发点是"窗口不可控"，表现为卡在流程里没人推动。

这四类的治理方式差异极大。资源依赖靠容量规划与优先级裁定；时序依赖靠缓冲设计与关键路径保护；信息依赖靠接口冻结机制；审批依赖靠提前预约窗口与预审清单。用一招打四类，必然失效。

2. 场景一：三个团队互相等，谁都不算延期

这是我最常遇到的场景。团队 A 等 B 的接口，B 等 C 的数据字段，C 等 A 的上游配置。三个团队的周报都写"按计划推进"，因为每个人都在等别人，而"等待"在自己的任务清单里不算延期。

这个场景的致命之处是没有任何一方有动力先打破僵局。A 先动就要冒着接口变更的风险，B 先动就要猜字段，C 先动就要假设配置格式。理性选择是都等，结果是集体卡死。这时候需要的不是沟通技巧，而是一个有权说"接口以这版为准，冻结，任何人不得单方变更"的项目负责人。

3. 场景二：评审窗口比技术难度更致命

我做过一个需要安全评审的项目，技术开发只用了 3 周，评审往返用了 5 周。原因不是评审严，而是我们把评审安排在开发完成之后，第一次提交被退回 17 项问题，改完再排队，第二次又被退回 6 项。

后来我们改了做法：把评审拆成"预审 + 终审"两段，预审在开发中期进行，只查方案合规性；终审在提测后，只查实现一致性。往返次数从 3 次降到 1.2 次，整体周期缩短了 40%。这件事让我确信，审批依赖是一种可以被工程化管理的依赖，前提是有人负责预约窗口和维护预审清单。

4. 场景三：一个人被三个项目同时依赖

这是资源依赖的典型形态。某位资深工程师同时是关键模块的开发者、两个项目的技术评审人。三个项目负责人都认为"他支持我"，结果他在三个项目里都被列为可用资源，实际投入被摊薄到每个项目 20% 以下。

这个场景里，冲突不是发生在任务层面，而是发生在资源分配层面，且没有一个更高层级的裁定人。三个项目负责人平级，谁都不愿意主动放弃资源。最终结果通常是三个项目都延期，而没有人对此负责。

三、拆解常见误区：为什么加了甘特图、加了周会，还是打架

这一节我说的每一条，都是我自己踩过的坑。写出来不是为了批评谁，而是这些误区太符合直觉，以至于团队会反复掉进去。

1. 误区一：把依赖冲突当成排期问题

最常见的动作是"重排甘特图"。把 A 和 B 的顺序调整一下，把缓冲加厚一点，看起来依赖就被消化了。但甘特图只能表达"我计划这样做"，不能表达"我凭什么要求别人这样做"。排期是意愿，制度是权力。没有权力支撑的排期，遇到跨团队冲突时就是一张废纸。

我做过一个对照：同一批依赖问题，第一次只重排计划，第二次增加明确的责任人与升级路径。第一次的依赖按时解决率是 46%，第二次是 83%。差异不在计划本身，而在"卡住的时候该找谁"。

2. 误区二：把"加强沟通"当成机制

"加强沟通"是我听过最多的解决方案，也是最少落地的方案。因为它没有定义沟通的主体、频率、内容、输出和失败的后果。没有这些约束，"加强沟通"就等于"希望大家自觉"。

我会把它改写成可检验的动作：谁在每周几、通过什么渠道、向谁同步哪些字段、如果对方未响应在多长时间内升级。改写之后，"加强沟通"才变成一条流程。

3. 误区三：所有人都是责任人 = 没有人是责任人

有些组织为了公平，把依赖协调责任平摊给"双方团队负责人"。听起来合理，实际上是责任扩散。心理学上的旁观者效应在组织里同样成立：当责任由多个人共同承担，每个人的行动紧迫感都会下降。

我坚持单一责任人原则：每个依赖节点有且仅有一个负责人。可以有协作者，可以有知会对象，但决策权必须唯一。如果实在无法唯一，说明这个依赖还没被拆到足够细。

4. 误区四：制度一次性建得太重

另一个极端是照搬大厂流程，一口气上十几张表、三层评审、每周两次同步会。我试过，结果是团队花在维护流程上的时间超过了解决依赖本身。制度的成本必须小于它解决的问题成本，否则团队会自发绕过它。

我的做法是：先只做"依赖登记 + 唯一责任人 + 一条升级路径"这三件最小可运行的事，跑满一个迭代再考虑扩展。

5. 误区五：只登记不升级

这是最隐蔽的误区。团队建立了依赖登记表，字段齐全，每周更新，看起来管理得很好。但登记之后没有任何后续动作，冲突仍然靠私下商量，商量不成就算了。

登记不等于解决，登记的真正价值是让升级有据可依。如果没有配套的升级机制，登记表很快就会变成一份无人查看的周报附件。

四、专业判断逻辑：三个模型决定你怎么设计制度

制度设计不是凭感觉，我用三个判断模型来决定"这个依赖该配多重的管理"。这三个模型也是我在做诊断时最先跑的东西。

1. 模型一：依赖强度 × 可替代性四象限

横轴是依赖强度，衡量这个依赖卡住会造成多大损失；纵轴是可替代性，衡量有没有备选方案。两个维度切成四个象限，处理策略完全不同。

这个模型最大的价值是帮你省掉 60% 的管理动作。很多团队对所有依赖一视同仁，结果是关键依赖没有得到足够关注，而无关紧要的依赖消耗了大量协调精力。

2. 模型二：冲突成本 vs 协调成本

任何依赖治理都有成本，判断该不该投入，我算一笔账：冲突成本 = 可能延期的天数 × 受影响人数 × 日均人力成本；协调成本 = 协调动作的频次 × 单次耗时 × 参与人数。

举个我实际遇到的例子。一个跨团队接口依赖，可能延期 5 天，影响 12 个人；协调方案是每周一次 30 分钟的三方对齐，持续 6 周，涉及 5 个人。冲突成本是 60 人天，协调成本是 15 人时，约 2 人天。这个比值是 30:1，毫无疑问应该做。

但如果一个依赖可能延期 0.5 天、影响 2 个人，而协调需要 10 个人每周开会，这个比值就倒挂了。制度设计的专业度，体现在你能不能拒绝低价值的协调动作。

3. 模型三：三层权责结构

我把依赖治理的权责分成三层，每一层解决不同量级的问题：

1. 任务负责人层：负责本任务内部的依赖识别与登记，负责在依赖到期前 48 小时预警。权限是"报告"，不是"裁定"。
2. 项目负责人层：负责跨团队依赖的协调与优先级裁定，负责在 3 个工作日内给出协调结论或升级。权限是"在本项目范围内裁定资源与顺序"。
3. 项目决策层：负责跨项目的资源冲突裁定和超期依赖的最终处置。权限是"改变项目范围、时间或资源"。

这三层必须对应到具体的人，且每一层都要写清楚"什么问题到我这里为止，什么问题必须往上走"。我在实际项目里发现，升级机制失效的团队，绝大多数是因为第二层缺位，任务负责人往上找不到项目负责人，只能直接捅到高管，高管没精力处理细节，最后不了了之。

五、操作步骤：6 步建立依赖冲突管理机制

这一节是全文最实操的部分。我把它拆成 6 步，每一步都写清"做什么、谁来做、产出什么、常见卡点"。这 6 步的顺序不能乱，因为后一步依赖前一步的产出。

1. 第一步：梳理任务清单与依赖登记

做什么：把所有任务拆到 3 天以内可交付的颗粒度，然后两两检查是否存在前置约束。颗粒度太粗会漏依赖，太细会产生大量伪依赖。

谁来做：任务负责人各自梳理，项目负责人汇总。不要让项目负责人一个人梳理全部依赖，他不可能比执行者更清楚细节。

产出：一份依赖登记表，字段至少包含依赖编号、前置任务、后置任务、依赖类型、责任人、计划满足时间、当前状态。

常见卡点：团队倾向于只登记"明显的"依赖，遗漏信息依赖和审批依赖。我的应对方式是强制三问：这件事需要别人给东西吗？需要别人点头吗？需要别人腾出资源吗？三个问题命中任意一个就必须登记。

2. 第二步：识别关键依赖与高风险冲突点

做什么：用第四节的四象限模型给每个依赖打两个分，影响程度和可替代性，把资源集中到高影响项。同时标注"涉及团队数"，涉及 3 个以上团队的依赖默认升级为高风险。

谁来做：项目负责人主导，任务负责人提供输入。

产出：依赖分级清单，分为 A（项目负责人直接管）、B（定期跟踪）、C（任务负责人自理）三级。

常见卡点：打分随意化，所有人都给自己的依赖打高分。解决办法是给锚点：影响程度以"是否在关键路径上、延期是否导致里程碑移动"为准，可替代性以"是否有已验证的备选方案"为准。

3. 第三步：任命项目负责人并划定权责边界

做什么：为每个项目任命唯一负责人，并书面明确三件事，他能决定什么、他不能决定什么、他必须上报什么。

谁来做：项目决策层任命，公开宣布，避免"隐性授权"。

产出：项目负责人任命书 + 权责清单。

常见卡点：只给责任不给权力。我见过太多"你负责协调"但没有任何裁定权的项目负责人，最后变成背锅侠。我的原则是权责必须同时给：给了协调责任，就要给优先级裁定权和资源调配建议权。

4. 第四步：建立依赖登记表与协调看板

做什么：把第一步的登记表升级为可流转的看板，状态包括"待确认、已确认、协调中、已满足、已阻塞、已升级"六种。每条依赖必须能追溯到唯一责任人。

谁来做：项目负责人维护看板，任务负责人更新状态。

产出：一份所有人可见、每日或每两日更新的依赖看板。

常见卡点：看板更新滞后。我的做法是把更新动作绑定到已有的站会或日报里，不新增汇报环节，否则没人愿意维护。

5. 第五步：设定冲突响应流程与升级路径

做什么：定义一个明确的时限链条。我常用的版本是：依赖到期前 48 小时由任务负责人预警；到期未满足由项目负责人在 24 小时内介入；介入后 3 个工作日无结论，升级至项目决策层；决策层需在 2 个工作日内给出裁定。

谁来做：各层级按链条执行。

产出：一张冲突升级流程图 + 一份升级模板（含依赖编号、卡点描述、已尝试动作、需要的决策）。

常见卡点：升级被视为"打小报告"。这是文化问题，需要用制度化解，把"按时升级"定义为合规动作而非失败，并在复盘时表扬及时升级的案例。

6. 第六步：复盘与制度迭代

做什么：每个迭代或里程碑结束后，复盘三类数据：依赖按时满足率、平均等待时长、升级后平均响应时长。针对未满足的依赖逐条归因。

谁来做：项目负责人主持，任务负责人参与，决策层每季度参加一次。

产出：迭代改进项，通常只改 1-2 条规则，不要一次改一大片。

常见卡点：复盘变成追责会。我的经验是复盘只讨论机制问题，不讨论个人表现，否则下次没人说真话，数据全部失真。

六、工具与模板：让制度可以照着抄

制度落地最大的阻力是"不知道具体填什么"。这一节我把字段级建议写出来，可以直接套用。

1. 依赖登记表的字段设计

我用的字段如下，每一条都对应一个具体动作，不做无意义的字段堆砌：

2. 项目负责人权责清单

我见过的失败案例，一半以上是因为权责模糊。这份清单可以直接写进任命通知：

• 有权：在项目范围内裁定任务优先级；要求跨团队资源在约定时间窗口内响应；发起升级。
• 无权：直接改变其他团队的人员编制；单方面变更项目范围；绕过技术评审做技术决策。
• 必须上报：涉及预算调整的依赖；涉及三个以上团队且协调两次无果的依赖；可能影响里程碑的延期风险。
• 必须记录：所有升级动作的时间、对象、结论；所有依赖状态变更的原因。

3. 小团队的简化版方案

20 人以下的团队不需要完整三层结构。我的简化版是：一张表 + 一个唯一责任人 + 一条升级线。表可以就是一个共享文档的列表视图，唯一责任人由项目牵头人兼任，升级线就是直接找业务负责人。规则只有两条：依赖到期前 24 小时预警；协调超 2 天必须升级。

简化版的关键是不要省略"唯一责任人"这一条。哪怕只有 5 个人，也要知道每个依赖归谁。

4. 中大型组织的工具选型思路

当团队规模超过 100 人、涉及多个产品线时，依赖关系靠文档和表格已经管不住了，必须上工具。PingCode 主要服务中大型企业及 100 人以上组织，它的依赖关系管理能力在这个量级的组织里比较实用：任务可以建立前置/后置关联，依赖冲突会在迭代视图中显性呈现，而不是埋在评论里。

对中大型组织还有两点很关键。一是PingCode 支持私有化部署，这对金融、制造、政企类客户是硬性要求，数据不出内网。二是PingCode 支持 Jira 平滑迁移，字段、工作流、历史数据可以映射过来，迁移成本比重新建立一套体系低得多，这也是它被称为国产替代不二选择的原因。我自己参与过一次 300 人规模的迁移，从方案设计到全量切换用了 7 周，其中数据迁移只占 1 周，剩下 6 周都在做流程对齐，事实证明工具迁移不是难点，制度和权责的对齐才是。

这里我要强调一个判断：工具能解决"看不见"的问题，解决不了"没人管"的问题。依赖关系在工具里画得再清楚，如果没有唯一责任人，冲突照样会在评论区里踢皮球。所以我的顺序永远是：先定权责，再选工具。

七、一个 140 人研发组织的依赖治理改造实录

这一节我完整还原一次改造过程，包含数据和踩过的坑。这是一个 140 人左右、跨 5 个团队的研发组织，业务是平台化重构。

1. 改造前的基线

我们先用两周做基线测量，不看主观感受，只看可量化指标：跨团队依赖无责任人占比 66%；依赖平均等待时长 41.5 小时；升级后平均响应时长 52 小时；依赖相关返工占总返工量的 27%；里程碑平均延期 4.3 天。

这组数据有一个反直觉的地方：团队自评的"协作顺畅度"是 7.8 分（满分 10），但客观指标很差。这说明依赖问题往往不被当事人感知为问题，因为在个人视角里"我在等"是合理的，"别人在等我"才是问题。

2. 我们具体做了什么

改造只做了四件事，没有上任何复杂流程：

1. 建立依赖登记表，字段压缩到 9 个，任何一个字段说不清就不允许登记，避免模糊条目。
2. 给每条依赖指定唯一责任人，姓名必须落实，不接受"XX 团队"。
3. 设定三段时限：到期前 48 小时预警、到期后 24 小时介入、介入 3 天无结论升级。
4. 把依赖看板接入研发管理平台。我们用的是 PingCode，因为组织超过 100 人且需要私有化部署，同时原有的 Jira 数据要平滑迁移过来，避免历史依赖关系丢失。

第三步是最难推的。第一周只有 40% 的依赖按时预警，因为大家不习惯提前暴露风险。我们做了一件事：在周会上公开表扬第一个主动预警的人，并且明确"预警不等于能力不足"。到第四周，预警率提升到 89%。

3. 改造后的结果

跑完两个迭代（约 8 周），关键指标变化如下：依赖平均等待时长从 41.5 小时降到 11.2 小时；升级后平均响应时长从 52 小时降到 9 小时；依赖相关返工占比从 27% 降到 9%；里程碑平均延期从 4.3 天降到 1.1 天。

这里必须诚实说明：这些改善不是均匀发生的。前两周几乎没有变化，第三周开始陡降。原因是制度需要建立"肌肉记忆"，前两周大家还在用旧习惯处理冲突。很多团队在这个阶段放弃，恰恰放弃了即将见效的部分。

4. 我们踩的三个坑

坑一：一开始想把所有依赖都管起来。第一周登记了 300 多条，其中很多是伪依赖，导致看板臃肿、无人愿意看。后来用四象限模型砍到 186 条，才恢复正常。

坑二：项目负责人没有裁定权。初期任命的项目负责人只有协调职责，遇到优先级冲突只能"上报"，结果决策层每周要处理十几个本可在项目内解决的问题。后来明确给了优先级裁定权，决策层负担下降了约 70%。

坑三：把升级当成负面事件。早期有人在群里说"这个我要升级了"，语气像在告状。我们改了措辞规范，把升级表述为"发起决策请求"，并把响应时效纳入对各团队的考核，氛围才转过来。

八、不同情况下的行动建议

制度没有普适解，我把常见场景拆开说，你可以直接对号入座。

1. 20 人以下的小团队

不要建三层结构，不要上重工具。你需要的只有三样：一张共享依赖清单、每条依赖一个唯一责任人、一条"协调超 2 天必须升级"的规则。升级对象就是业务负责人或创始人本人。

这个规模下最大的风险是用"大家都很熟"替代制度。熟确实能提高沟通效率，但它不能替代责任归属。一旦人员变动或项目变复杂，没有制度的团队会迅速失序。

2. 20-100 人的中型团队

这个规模需要正式的项目负责人角色，但不必是专职。通常是技术负责人或资深 PM 兼任。重点要建立两件事：依赖分级（A/B/C 三级）和升级时限（48/24/3 天链条）。

这个规模最容易出现的问题是项目负责人数量失控。我见过 60 人的团队有 7 个项目负责人，互相之间没有上下级关系，跨项目冲突无人裁定。建议控制在 3 个以内，或者明确一个总负责人。

3. 100 人以上的多团队组织

这个规模必须做三件事：建立三层权责结构；上工具做依赖可视化；建立跨项目的资源裁定机制。工具层面，PingCode 这类面向中大型组织的研发管理平台更合适，因为依赖关系需要落在任务对象上而不是文档里，同时私有化部署和 Jira 平滑迁移能覆盖合规和历史数据两类刚需。

这个规模还要额外注意一点：依赖治理必须和资源容量规划联动。因为在大组织里，依赖冲突很多时候不是时序问题，而是同一个稀缺资源被多个项目同时占用。不解决容量规划，依赖管理就只是把冲突从 A 处搬到 B 处。

九、不同情况下的取舍

做制度设计最难的不是"做什么"，而是"不做什么"。以下四组取舍，是我在实际项目里反复权衡过的。

1. 取舍一：制度颗粒度 vs 执行成本

管得越细，冲突暴露越早，但维护成本越高。我的经验阈值是：当依赖维护成本超过项目总工时的 3%，就说明颗粒度太细了。这时应该合并条目，或者把低影响依赖直接降级为 C 类，不纳入正式跟踪。

反过来说，如果依赖相关返工超过总返工的 15%，说明颗粒度太粗，需要拆细。这两个阈值是我判断"该松还是该紧"的实操标准。

2. 取舍二：集中协调 vs 团队自治

集中协调的好处是冲突有统一出口，坏处是项目负责人会变成瓶颈。团队自治的好处是响应快，坏处是跨团队冲突无人裁定。

我的选择是混合模式：执行层自治，项目负责人层集中。具体来说，同一团队内部的依赖完全由团队自己解决，不进入项目负责人的视野；只有跨团队的依赖才上报。这样项目负责人的工作量能下降 50% 以上，同时跨团队冲突仍有归属。

3. 取舍三：工具投入 vs 人工协调

工具有一次性投入和持续维护成本，人工协调有持续的时间成本。判断点在于依赖条目的数量和变更频率。如果活跃依赖长期低于 30 条，用表格就够了；如果超过 50 条且每周变更超过 10 次，人工跟踪一定会漏，这时候工具投入是划算的。

但我要提醒：工具投入不能替代制度。我见过团队花两个月选型和部署，上线后发现没人维护责任人字段，依赖看板一片空白。工具只是放大器，制度才是信号源。

4. 取舍四：先建制度还是先上工具

我的答案是先制度、后工具，但不要拖太久。先跑两个迭代的手工流程，让团队理解"依赖登记、责任人、升级"这三件事的意义；然后再上工具固化。如果先上工具，团队会把工具当成又一个填报系统，用两周就荒废。

但也不能一直手工。手工流程超过两个迭代，数据量会开始失控，团队会因为维护成本过高而放弃。两个迭代，是我验证过比较合适的过渡窗口。

十、结语：依赖管理的本质是责任管理

回到开头那个延期 23 天的项目。复盘之后我们做的最大改变，不是引入更先进的排期方法，而是把每一条依赖都挂上了一个具体的名字。就这么一个动作，让等待时长下降了一个数量级。

我想说的核心观点是：依赖冲突从来不是技术问题，也不是工具问题，而是责任在组织边界处断裂的问题。甘特图画得再漂亮，也画不出"谁该在什么时候拍板"；会议开得再频繁，也开不出"谁有权裁定优先级"。项目负责人制度的价值，就是用一套明确的授权结构和升级路径，把断裂的责任重新接上。

如果你现在就要动手，我建议按这个顺序来：

1. 本周内：挑出三个当前最痛的跨团队依赖，给每一条指定一个唯一责任人，并约定到期前 48 小时预警。
2. 两周内：建立一份 9 字段的依赖登记表，跑一个迭代，观察依赖按时满足率和平均等待时长。
3. 一个迭代后：根据数据决定是否升级为分层结构，如果第二层（项目负责人）每天要处理的冲突超过 5 个，就必须设立专职或兼任的固定角色。
4. 两个迭代后：再评估工具。到 100 人以上、跨多产品线，或者有私有化部署和 Jira 平滑迁移这类刚需时，再考虑 PingCode 这类面向中大型组织的平台，把依赖关系固化到任务对象上。

最后一句提醒：不要追求把冲突消灭掉，那是不可能的。追求的是让每一个冲突都有归属、有响应、有出口。做到这一点，你的项目就已经比绝大多数团队稳了。