企业中的速度，第3部分

在上一篇文章中，我们讨论了要想有机会建立企业速度，我必须满足的两个标准。首先，让我们研究一个团队没有完全嵌套在项目下的情况。

当项目团队不是嵌套的时候

可能最常见的坏嵌套的例子是团队除了负责项目工作外还负责产品支持。生产支持本质上是一种不可预测的活动。你永远不知道你的客户什么时候会打电话来，你永远不知道什么地方会出现问题，通常你也不知道解决问题需要多长时间。你可以将这些事项添加到待办事项列表中，并按优先级排列，但通常情况下，这些问题必须立即处理，直到完成。这是以项目工作为代价的。

通常，您允许每次迭代都有一定的时间来处理这种不确定性，并希望随着时间的推移，平均法则会对您有利。在这种情况下，大多数团队都不像他们希望的那样可预测，或者他们的客户需要他们这样做。让我们假设您正在以25点/迭代的速度前进，并且意外地生产支持的数量急剧上升。这是一个迭代事件吗?我们能解决这个问题吗?我们只是不知道。最终的结果是，虽然整个团队的表现可能相当稳定，但新功能的完成将变得非常不稳定。

这种现象的另一个例子是当一个团队在为多个项目工作时。团队的待办事项列表由项目A和项目b的特性组成。产品负责人正在平衡多个涉众的需求，并试图管理业务的期望。亚博vip9通道如果一个团队不是一次专注于一个项目，那么团队的开发速度可能会突飞猛进，而任何一个项目的开发速度可能都很糟糕。无论哪种方式……当你将团队划分为多个项目时，单个团队的速度不再是项目绩效的预测器。

团队速度可以很好，但对任何一个项目的性能都没有任何影响。

特性团队或组件团队

组件团队的挑战可能只是嵌套问题的一种特殊情况，但是由于这种模式是如此制度化，所以我想专门讨论它。如果项目中的每个团队都不致力于端到端的功能，那么你可能拥有一些组件团队结构。组件团队在更复杂的问题领域中很常见，因为许多公司都试图通过重用公共架构子组件来进行扩展。因为解决方案太大了，所以很难在整个产品中获得正确的技能和领域专业知识。所有这些都会导致团队围绕组件进行组织。

我们可能不喜欢……但这种情况已经存在，而且不太可能改变。

从每个团队的角度来看……他们有一个优先级的产品待办事项列表……可以一直完成……并且可以一次又一次地删除待办事项列表。从企业的角度来看，它需要几个团队协同工作来交付企业级价值特性。这些团队的产品负责人正在平衡相互竞争的利益相关者的需求……就像矩阵项目的例子一样……但现在我们有了一个额外的协调层，以确保我们的团队与其他团队一起工作，以同步企业级特性集。我们还有另一个例子，在这个例子中，团队级的速度可能非常好，而项目级的性能却会受到影响。

该项目试图通过几个团队来限制服务创建。当所有服务就绪后，项目将把这些服务集成到完整的端到端特性中。在这种环境中，我们如何规范化项目速度?我们如何预测项目级别的价值流动。基本的事实是，通过向上的速度，你不能。你可以试着在一段时间内取平均值，但这种策略会失败。为什么?任何团队在任何时候都可能使价值创造过程挨饿。你可能有8个团队在打造优秀的服务，而只有一个团队在苦苦挣扎。这样的团队将阻碍企业价值的创造。

现在让我们把事情变得更复杂。通常我们不是只运行一个项目，我们是运行一个项目组合。我们有几个依赖于这些组件团队的服务的项目。现在，每个组件团队的待办事项是多个项目所需要的特性的混合物。在这种情况下，我们有一个团队正在为许多项目构建服务，服务必须一起交付企业特性。在项目的任何时候……团队的速度都可以是惊人的。我们可以在团队级别上稳定和改进，而不能在项目级别上交付任何东西。

伟大的团队…糟糕的生意亚博vip9通道

令人沮丧的是，每个团队都可以很好地实现敏捷。他们可以有一个教练，很好的团队合作，很好的工程实践，开很好的会议，有出色的速度……但企业认为他们正在失败。亚博vip9通道企业并不亚博vip9通道关心所有这些东西……他们看重的是尽快向市场交付端到端功能。所以我们遇到了一个问题，团队和企业之间的阻抗不匹配。这就是我能说的最简单的问题……典型的敏捷扩展假设多对一关系在团队和项目之间。现实情况是，在许多组织中，我们正在处理很多对很多的关系在团队和项目之间。

这种多对多的关系打破了速度。

所以，你有一个选择。要么你构建你的组织，使其能够工作……要么你找到其他东西来衡量企业投资组合的绩效。在接下来的几篇文章中，我们将探讨企业级的速度替代方案。