简介：IT工作的一个特点是工作制品本身不是直观可见的，这对IT管理者提出很大挑战。管理可视化使得隐藏的问题浮现到表面，从而采用有效对策。

关联微课：《DevOps&Lean IT里的关键可视化工具系列微课》第五讲看板、第六讲可视化工作集

注意：本文阐述的是工作项依赖的管理，不是软件系统/组件之间的调用依赖关系。

IT工作中依赖关系的管理是一个难点。当然如果能够对依赖关系解耦，使得变更可以在本地化进行则最为理想。即特性团队可以独立实现开发、测试、部署。在Gene Kim的新书《独角兽项目》中提出的“五个理念”的第一理念：局部性和简单性即是对此的总结。

但这也可能意味着需要跨功能团队协调工作项。无论如何，工作项之间的依赖很难完全避免。对此我们首先要能够可视化“隐蔽的依赖”，然后是针对性地进行管理。

三种类型的工作项依赖

Dominica DeGrandisit在《Making Work Visible》一书中定义了三种依赖关系来源：

• 架构（包括软件和硬件）依赖— 一部分的变更造成另一个部分功能被破坏（例如，导致它停止工作）

• 人员/专家依赖 —某项工作需要专门知识的人才能进行。

• 活动依赖 —在某项活动完成之前无法进行下一个活动。最直观的即为甘特图里的几种任务依赖关系。

依赖需要小心管理，否则可能造成大量的等待和时间浪费。工作项依赖可以通过以下可视化手段来进行管理：

依赖矩阵

适用于职能型组织。为完成某个需求/任务，各个职能部门/角色之间存在很强的工作依赖，但因为不属于同一团队，团队外沟通协调非常耗时。为了理解具体哪些角色之间经常存在依赖关系，以便有效管理，可以采用下图的依赖矩阵。

来源：Dominica DeGrandisit，Making Work Visible

该矩阵的行和列都是组织内的职能角色（或职能团队）。如表上头的团队/角色（impactor）为了开始、继续或完成工作，而需要表纵列的团队/角色（impactee）完成对应的工作，那么就在相应的单元格里增加一个’•’。比如，VS Arch这一角色为了完成任务，必须要和InfoSec，Enterprise Arc和Chg Control协同工作。

当然，上图只是使隐藏的依赖关系浮现出来。可以考虑的解决方案有通过看板协调任务、组织架构调整（比如组建跨功能团队）、流程自动化、架构解耦等。

下面几种是通过看板来可视化及管理依赖的几种方法，可以根据需要选择合适的策略。

为看板卡贴“依赖”标签

适用于团队外依赖比较少的情况。

可以用一个“依赖标签”贴在对应的看板卡上，每日站会时重点跟踪该工作项的进展。当然如果有其他类型的阻碍，可以统一用“阻碍”标签来代表受阻状态。

用标签标识依赖工作项

在“活动和”完成“之间增加“跟踪”列

适用于依赖经常出现在某步骤中。在看板中增加一个跟踪列，专门用来跟踪有外部依赖的工作项。比如实施过程中经常因为需要等待外部的审核、依赖、批准或来自团队外部的其他意见，工作项在中途被阻塞。

为了解决这个问题，可以在“实施”步骤的中间添加一个“跟踪”(Track)列。

来源：Eric Rechner, 《用看板管理敏捷项目》

当工作项因为等待外部输入而被阻塞时,它们将被移动到“跟踪” 里。每天, 被分配在阻碍工作项上的团队成员会报告这些工作项的进展情况。当阻碍问题解决以后,这些工作项将重新进入实施阶段。

单独的依赖工作 “泳道”

适用于工作项在整个工作流中都存在对外部团队的依赖。如果某种类型的工作在整个工作流程中都需要管理和外部的依赖（而不是只在某一个步骤），那么可以考虑单独为该类型的工作划分一个泳道。

来源：Dominica DeGrandisit，Making Work Visible

组合看板

适用多个团队的工作项经常有依赖关系，需要在组织级别经常进行统一协调沟通。具体看板的设置可能是在组织的某个区域，多个团队的看板组合排列在一起，然后在一个跨团队的站会上统一回顾/协调各团队看板任务的关系。

来源：Dominica DeGrandisit，Making Work Visible

其他管理策略：

当采用看板方法，而团队所依赖的场景或组件延迟交付时，除了通过可视化的方式管理和协调任务外，还可以通过为所依赖的工作项创建一个简单的伪实施 (Fake Implementation) ,或在依赖项的前一个稳定版本和延迟的预期未来版本之间编写一个垫片（shim），以及协助上游合作团队, 甚至可能直接接管你的依赖项工作。（详见《用看板管理敏捷项目》第7章）

附 —— Gene Kim的五个理念（《独角兽项目》）：

第一个理念: 局部性和简单性

第二个理念: 专注、流动和快乐

第三个理念: 改进日常工作

第四个理念: 心理安全

第五个理念: 以客户为中心