依赖管理：项目和产品的完整指南

Informatec Digital »资源»依赖管理：项目和产品的完整指南

依赖关系管理是每个人每天都会遇到的问题之一，但很少有组织能够系统地解决它。如果依赖关系管理失控，就会出现延误、莫名其妙的障碍，需要召开紧急会议来“救火”，最终导致项目延期甚至根本无法完成。

反之，当依赖关系被识别、可视化并得到有效管理时，团队就能更自主地工作，截止日期不再是碰运气，部门间的协作也会更加顺畅。本文将详细探讨项目和数字产品中的依赖关系是什么，它们有哪些不同的类型，以及如何使用敏捷方法、看板等框架以及 Jira 或项目管理软件等工具来实际管理它们。

在项目和产品管理中，依赖关系指的是什么？

在项目和产品开发领域，依赖关系是指两个工作要素之间的必然联系：它可以是任务、团队、技术组件，甚至是外部供应商。任何事物的开始、进展或结束，都必须以其他事物的发生为前提。

从实际角度来看，依赖项可以是功能性需求（例如，网站上的购物车），也可以是纯粹的技术性需求（例如，可用的 API、环境访问权限或版本部署）。即使最终使用者并非人，而是其他服务，我们仍然称之为依赖项。

在项目管理中，如果一项任务的执行取决于另一项任务的完成、启动或进展，则该任务通常被描​​述为依赖任务。例如，“任务 B”需要“任务 A”达到特定阶段才能继续进行，那么它们之间就存在依赖关系。

依赖关系并非只是令人烦恼，它们构成实实在在的风险。依赖关系会增加项目延误、成本超支甚至在正式上线前就被取消的可能性。默认情况下，每个依赖关系都具有一定的概率和影响，因此应该加以管理，而不是忽视。

依赖项类型：完整概述

为了有效管理依赖关系，首先必须对其进行分类和命名。项目管理文献和产品实践通常区分以下几个维度：根据其性质（逻辑依赖、资源依赖、外部依赖、优先依赖）、根据任务之间的关系以及根据组织范围。

各部门按其性质划分

逻辑依赖或因果依赖是指遵循必然步骤顺序的依赖关系。你不可能在墙还没建好之前就粉刷它；你不可能在功能还没开发好之前就测试它。它们是最直观的。

当多个任务或项目争夺同一有限资源时，就会出现资源依赖性：例如关键人员、单个设计师、单个后端团队、测试机器等。工作进度与其说是取决于逻辑顺序，不如说是取决于这些资源的实际可用性。

优先依赖项是指源于内部流程或最佳实践，但并非完成交付物所绝对必要的依赖项。例如，团队决定保留的额外编辑审核或质量保证步骤，因为它可以减少错误，即使没有这些步骤，项目也可以正式“结束”。

当团队受到自身无法控制的因素影响时，就会出现外部依赖性：例如，供应商必须交付材料，法务部门必须批准合同，天气会影响项目，或者第三方支付网关必须对其服务进行认证。

任务依赖关系：经典的时间关系

在计划层面，任务依赖关系通常用四种基本关系来建模，您会在进度表或甘特图中看到这些关系：

在完成-开始（FS）关系中，后续任务必须在前置任务完成后才能开始。这是最常见的关系，也是大多数工具默认使用的关系。

在完成到完成（FF）关系中，下一个任务必须在前一个任务完成后才能完成。这种情况通常发生在某个任务实际上是由几个相互依赖的子任务组成时。

对于“起始-起始”（SS）模式，两个任务必须并行启动。后置任务不能在其前置任务之前启动，即使它们随后以各自的速度进行。

起始到结束（SF）关系虽然不太常见，但仍然存在，它意味着任务A只有在任务B开始后才能被视为完成。一个典型的例子是客服人员的换班：一个人必须等到下一个人到来才能离开。

内部、外部和团队间依赖关系

除了性质之外，区分项目内部依赖关系（团队自身控制的任务或资源之间的依赖关系）和外部依赖关系（依赖于第三方的依赖关系）也很重要。

在中大型组织中，团队间的依赖关系变得越来越重要：当多个团队、部门或供应商需要协调合作以交付共同成果时，就需要关注这一点。这包括产品团队之间的依赖关系、团队和跨职能团队（人力资源、采购、法务）之间的依赖关系，以及后端、前端、移动端和运维等技术团队之间的依赖关系。

主动式与被动式依赖管理

一个组织处理依赖关系的方式，决定了它是疲于应对各种问题，还是营造更健康的组织环境。我们可以探讨两种基本策略：主动策略和被动策略。

被动式管理是指仅在依赖关系出现严重问题时才做出响应：例如缺少权限、访问权限、组件或 API，导致团队陷入困境。这种情况通常会导致持续停机、临时重新计划和承诺无法兑现。

另一方面，主动管理则需要从一开始就投入精力来识别和规划各种依赖关系。它能够预见需求，预留资源，明确团队间的承诺，并在风险演变成问题之前将其识别出来。

尽管总会有被动应对的成分（你不可能预见所有事情），但一个健康的依赖关系管理策略必须有强大的主动性成分：分析、确定优先级、准备替代方案，并建立定期事件来审查这些依赖关系的状态。

可视化依赖关系：从看板到 Jira 中的矩阵

管理依赖关系的第一步是让所有人都能看到它们。看不见的东西就无法管理，只会造成损失。这就是看板实践、项目看板和各种可视化工具发挥作用的地方。

在看板系统中，一项基本实践是将工作可视化。这包括清晰地展示哪些任务依赖于其他任务，以及哪些任务阻碍了其他团队的工作。明确标记哪些任务“正在等待依赖关系”有助于避免意外情况的发生。

在 Jira 等工具中，一种非常实用的方法是利用问题链接字段来连接相互阻塞的任务。您可以使用“阻塞”或“依赖于”关系，区分强依赖（阻止依赖任务启动）和弱依赖（允许在解决一个任务的同时并行推进另一个任务）。

如果解决依赖关系的任务尚不存在，您可以选择使用特定标记来标记该问题，以表明这一未解决的需求。这样，您就可以将这些未解决的依赖关系分组并显示在面板、路线图、待办事项列表或看板中。

有了这些信息，就可以构建一个依赖关系矩阵，其中一个维度代表组织中的团队或小组，另一个维度代表时间线。这可以清晰地展示谁依赖于谁以及何时依赖，从而有助于资源分配和优先级协商。

在远程办公普及之前，这些矩阵通常绘制在实体白板上。如今，Jira 的插件和模块，例如 Advanced Roadmaps、BigPicture 和 Structure，使得在混合办公或完全远程办公环境中，这些依赖关系网络能够以可视化的方式呈现。

看板中的预约课程和预约板

一旦您对产品或组织层面的依赖关系有了全局的了解，您就可以更进一步，应用看板方法中的预留类概念，为依赖关系解决分配不同的服务级别。

预留类别用于根据优先级、紧急程度或所需交付时间对工作进行分类。为了将此方法应用于依赖关系，需要使用日历来分配专门用于解决这些依赖关系的容量槽位，分配周期可以是天、周或迭代周期（例如，Scrum 团队中的 Sprint）。

储备通常分为三种主要类型。首先是保障性资源，即专门预留的容量，以确保在需要时能够在特定日期可用。这些资源通常用于应对不可预见但至关重要的任务。

其次是预留依赖项：这些任务已经设定了完​​成期限。它们通常用于解决强依赖关系，一旦解决，其他团队就可以开始工作。

最后，备用依赖项属于只有在资源充足的情况下才会处理的类别。这些依赖项通常可以暂时避免，推迟处理，以便推进其他工作。

这种模式与航空公司管理机票的方式非常相似：有价格昂贵的保证座位、标准预订座位，以及取决于是否超售的候补机票。候补座位的状态甚至会随着时间推移而改变，随着目标日期临近和风险增加，座位状态会从“候补”变为“预订”或“保证”。

活动旨在审查依赖关系并协调团队

仅仅拥有预约看板或依赖关系矩阵是不够的，它必须融入到常规的审核流程中。至关重要的是，在当前的工作流程中，至少要安排一次活动来审核这些依赖关系并进行调整。

不一定要召开新会议；可以将其作为现有会议议程中的一个固定环节：例如，在迭代计划会议、SAFe 式 PI 计划会议或团队间协调会议中。

真正重要的是，所有参与创建和解决依赖关系的各方都必须参加此次审查。如果没有这种面对面（或屏幕对屏幕）的沟通，很容易出现不切实际的期望、单方面的承诺以及无法兑现的承诺。

好的依赖和坏的依赖：同步依赖和异步依赖

这听起来可能有点违反直觉，但并非所有依赖关系都是坏事。有些依赖关系能够促进健康的协作，而另一些则会造成信息孤岛和持续不断的摩擦。区分它们一个有效的方法是讨论同步依赖和异步依赖。

异步依赖是指团队工作时间或节奏不一致的情况。例如，Scrum 团队计划将另一个团队将在下一个 Sprint 中完成的开发工作集成到当前 Sprint 中，或者紧急请求访问依赖于第三个已不堪重负的团队的资源，这些都是存在问题的异步依赖的例子。

另一方面，同步依赖关系是指在同一时间段内开展的工作。例如，多个团队共享开发和测试环境，或者一个公司内任何开发人员都可以贡献代码的公共软件库。

这类依赖关系鼓励人们积极协作并分享信息。如果没有这些依赖关系，每个团队都更容易孤立于各自的信息孤岛中。而信息孤岛除了限制整体视野外，还会削弱部门间的同理心，并使组织层面的决策变得复杂。

长期战略应旨在最大限度地减少异步依赖关系，增强同步依赖关系，从而有利于拥有更大端到端自主权和更开放的协作实践的团队。

设计组织和团队以减少依赖性

组织结构直接影响依赖关系的数量和类型。随着产品发展和团队规模扩大，摩擦、重叠和瓶颈也会随之增多。通常情况下，即使只有两个团队，问题也会开始显现，并且随着每个新团队的创建而加剧。

在垂直整合、产品导向型组织中，目标通常是创建尽可能自主的多学科团队，这与《团队拓扑》中描述的“流式团队”拓扑结构非常契合。这些团队负责从头到尾完成某个业务领域或子领域。

即使拥有自主团队，仍然需要协调机制来确保产品一致性并防止团队协作破裂：全球路线图仲裁实例、受 PI 规划启发的联合规划活动、可视化依赖关系的程序看板、共享设计系统和实践社区等机制。

实际上，许多公司最终会采用混合模式，并非所有技能都能在每个团队中找到。于是，跨职能团队应运而生，涵盖产品设计、数据、质量保证、移动端开发、后端开发或运维等各个方面，为多个产品团队提供服务，从而引入了需要有效管理的额外依赖关系。

设有跨职能团队的部门：人力资源部、采购部、法务部……

除了技术领域，许多团队还依赖于人力资源、采购或法务等跨职能的企业团队。这些依赖关系通常体现在关键人才招聘、通过外部供应商进行能力建设、预算管理或法律审查等方面。

当一支球队需要签约或补强阵容，却无法掌控签约流程时，其市场反应速度就会受到影响，球队的可预测性也会下降。有多种方法可以缓解这种情况。

一种方法是将传统上由人力资源部或采购部管理的某些活动委托给小组（例如，部分甄选流程或与供应商的运营关系），这样既能实现明确的治理，又能减少官僚主义。

另一种方法是协商服务预算，以便每个团队在约定的限额内，自主决定雇用哪些人员或服务以及何时雇用。

也可以偶尔将人力资源、采购或法律专家纳入团队，以加快关键决策的制定，尤其是在快速增长或进行相关战略变革的时期。

典型的技术依赖项：后端、运维和移动端

从更技术的角度来看，依赖关系主要有三个常见来源：独立的后端团队、独立的运维团队和独立的移动团队。

当一个集中式的后端团队服务于多个前端团队时，就会形成难以管理的客户-供应商关系。后端团队必须为所有人构建 API，平衡自身无法控制的外部优先级，并承受巨大的压力。与此同时，产品团队由于无法确定所需功能何时可用，而面临开发延误和挫败感。

作为缓解措施，可以将后端开发人员暂时整合到团队中，可以定义后端和前端之间的清晰接口契约，或者可以发展微服务架构，其中每个团队负责自己的服务，接受会出现新的依赖项，但这些依赖项更容易管理。

对于运维团队而言，依赖关系通常集中在环境和部署管理上。开发团队完成开发后，需要运维团队将产品部署到各个环境中。如果运维团队工作量过大，版本发布就会积压，优先级划分不透明，导致交付延迟或仓促的风险增加。

为了改进这一领域，可以实施看板式的交付流程可视化管理，将针对运维需求的特定用户故事集成到团队的待办事项列表中，并提供自动化大部分流程的“软件即服务工厂” 。

即便如此，真正意义上的飞跃还是要建立成熟的 DevOps 文化，在这种文化中，开发和运维紧密合作，测试和部署实现自动化，团队能够安全地将变更投入生产。

类似的情况也发生在独立的移动团队身上：他们各自拥有高度专业化的技能（iOS、Android、移动设计、平台规范），这导致许多组织将他们合并成一个团队，最终这个团队要服务于多个小组。当所有团队同时提出移动端变更请求时，就会出现排队、优先级排序复杂以及瓶颈等问题。

一种可能的策略是，保留这些移动团队，并采用探索团队逻辑来跟踪团队，标记模式、可重用组件和良好实践，并在移动功能范围与 Web 版本相同时解散该团队。

软件依赖管理：库、框架和安全性

除了组织结构之外，在软件开发中，“依赖项”一词通常指的是应用程序运行所需的外部库、框架和组件。这里我们指的是依赖管理工具，例如 Maven、Gradle、npm 或Composer。

对这些依赖项管理不善会导致版本冲突、集成问题、长期维护困难或安全漏洞。因此，使用能够自动执行下载、版本解析和受控更新的工具至关重要。

建议保持依赖项适度更新，在安全性和稳定性之间取得平衡。频繁更新可能会引入意外错误，而更新不频繁则会使项目容易受到已知漏洞或npm 上恶意版本的攻击。

尽量减少依赖项的数量也是一种良好的实践：在添加新库之前，值得问问自己它是否真的能带来价值，或者是否可以用更简单的方式实现。每增加一个依赖项，就意味着更多的维护工作、潜在的冲突，而且在很多情况下，还会影响性能。

所有这些都应附有清晰的文档，说明使用了哪些依赖项、它们的版本以及用途，并进行严格的自动化测试，以验证更新不会破坏现有功能。安全分析工具也有助于检测新增依赖项中已知的漏洞。

项目依赖关系管理的实用技巧

在项目的日常管理中，有很多方法可以极大地帮助控制依赖关系。一些工具（例如 Asana、Wrike 和 Jira 等）也推荐采用某些特定方法。

首先，至关重要的是使用功能强大的项目管理工具来组织任务，该工具能够帮助你建立任务依赖关系、可视化时间线，并快速查看哪些任务受阻以及原因。这可以降低忽略重要环节的风险。

使用甘特图、路线图或看板等工具清晰地可视化依赖关系也十分有帮助。了解执行顺序和阻塞点有助于团队更好地理解某些任务的先后顺序以及它们如何影响其他同事。

另一个关键方面是监控与依赖关系相关的潜在风险。在项目计划的初始阶段，建议集思广益，探讨具体的依赖关系风险：例如关键人员工作量过大、外部供应商问题、待审批的许可证或尚未做出的业务决策。

最后，利益相关者之间的公开沟通至关重要。在处理依赖关系时，沟通绝非多余：如果有人知道自己会因他人依赖的任务而延误，最好尽快通知他们，以便其他人能够调整计划，避免遭受重大影响。

依赖关系对项目成功的影响

掌握依赖关系管理对项目的成功有着直接的影响。一方面，它能够实现更全面的控制和更明智的战略规划，因为项目经理可以了解所有环节如何相互关联，并制定切实可行的工作顺序。

另一方面，它显著提高了时间管理和延误预防能力。通过了解关键任务的顺序和依赖关系，可以更精确地调整截止日期，优先处理真正关键的任务，并立即发现任务变更的后果。

此外，良好的依赖关系管理有助于减少错误并优化资源。它避免重复工作，最大限度地减少不必要的返工，并创建一种能够限制代价高昂的错误发生的执行顺序。

所有这些都带来了更大的灵活性和适应性：当变化不可避免时，清晰的依赖关系图可以让你以更少的痛苦重新组织计划，预测影响并更有判断力地重新配置优先级。

总而言之，有效管理任务、团队和技术组件之间的依赖关系，是无论是短期项目还是复杂数字产品的持续开发，都至关重要的成功因素。重视自主团队、清晰可视化、协调机制和强大技术文化的组织，能够减少瓶颈，缩短产品上市时间，并使团队能够更高效地协作，更专注于为最终用户创造真正的价值。