需要其他团队合作是很自然的。等待他们或依赖他们为您提供一些东西可能很诱人，发生这种情况是因为他们拥有您需要工作的区域。例如，您可能需要一个团队将一个字段添加到他们的 API 中。或者您可能需要它们为您构建新的 API。有时，如果没有这些更改，您就无法交付所需的内容。
这是一个组织陷阱。它会导致痛苦。
独立执行团队规则
为了避免这个绝望的坑，请不要指望其他团队为您工作。遵循以下规则：
- 您可以制定计划，让其他团队为您工作。
- 与其他团队沟通您想要什么，并确保他们了解它的重要性。
- 但是永远不要指望任何其他团队为您工作。
- 当您依赖其他团队时，请始终制定备用计划。这样，如果他们的优先事项与您的优先事项不一致，您就可以继续并提供价值。
- 尽一切努力向客户提供您的体验。
产品工程应该如何处理依赖关系？
一些组织试图通过跟踪来解决依赖关系。这不起作用，因为问题是依赖关系，而不是跟踪依赖关系。在 Jira 中添加跟踪需求的系统无济于事。一切的基础是每个团队都有相互竞争的优先事项。这些优先事项会发生变化，因此您不能依赖它们。
任何雄心勃勃的项目都会有依赖关系。依赖关系越多，您就越处于危险区域。您拥有的依赖项越多，风险就越大。乘以每个依赖项的变化几率。很快，这是不可避免的。你的计划正在制定中。
转向一种模式，在这种模式下，您坚持始终制定不依赖他人的计划。当你这样做时，你总是有一个能带来价值的计划。将您的需求传达给其他团队，以便他们为整个公司创造最大价值。但要在您的控制范围内提供最大的价值。
据我所知，这是在产品工程中保持理智的唯一方法。
有些人会认为他们可以通过使用经验丰富的项目经理来避免这个陷阱。但问题不在于项目管理不善。即使您管理依赖项和风险，您也将面临无法接受的风险。具有依赖性的计划是有风险的。当你总是有一个后备时，你保证你可以提供一个价值基线。
何时使用此模型
- 这应该是产品工程团队的默认设置。不以这种方式运作会导致项目失败的风险更高。
- 这比产品工程更适用。基本原则适用于所有工程团队。
何时使用本模型
- 评估破解hack和迁移的成本。通常围绕其他团队的优先事项工作意味着您必须保持混乱。当您没有在正确的地方完成工作时，它会使您的解决方案变得不那么优雅。首先，检查您的团队是否可以在正确的地方完成工作。您可以使用 Away Team 模型来执行此操作。见下文。如果您必须使用破解hack不走寻常路，那么您的成本是创建 hack、维护它，并在准备好后迁移到新的解决方案。不要忽视这些东西的成本。您可能会认为成本不值得，而您应该做其他事情。请务必将这些费用传达给您提出请求的团队。但是您可以根据您提供的价值和您承担的成本来决定是否值得。
- 不要忘记你的影响力。尽管您无法控制其他团队可以做什么，但您可以影响他们。一定要传达你的需求，并解释为什么它很重要。为他们提供评估全球优先事项所需的背景信息。
- 密切关注组织结构。如果组织结构不正确，您可能有过多的依赖关系。最常见的例子是前端和后端工程团队。每个前端项目都依赖于后端团队。虽然团队找到了解决依赖关系的方法，但它们并不理想。他们可能会同意 API 合同，但会错过一些东西并且必须迭代。通常最好一起工作。当您看到这些依赖项时，通常您的组织设计是不正确的。（我稍后会写一篇关于前端和后端团队模式的更长的文章——我对此有很多想法）。
- 良好的系统级优先级是必不可少的。如果没有良好的产品管理，您将无法解耦您的团队。您需要一个产品管理（或集成商）倾听全球需求并确定其优先级。如果团队根据本地需求确定优先级，则您需要加强您的集成商。
独立执行者与其他协调模型
独立执行器是一种减少不必要协调的模型。当您需要增加协调时，您应该查看其他协调模型。当您需要其他团队的工作时，请考虑：
项目经理协调大型计划
- 当您需要协调一项大型计划时，项目经理是理想的选择。但首先需要将大型计划作为优先事项。我很快就会写关于集中/集中优先级的文章。在那篇文章中，我将分享如何合理地确定优先级。因此，项目经理并不能帮助其他团队为您工作。
集成商倾听并确定优先级
- 集成商倾听人们的需求，并根据他们听到的内容确定优先级。产品经理通常填补这个职能。当您使用独立执行器模型时，您需要集成器。如果您转向独立执行器模型，则应添加集成器。否则，您最终会遇到很多混乱的产品工程，以及一个无用的平台。
客队模式可以是一种自己动手的方式
- 与其让另一个团队做这项工作，为什么不自己做呢？亚马逊有一种方法叫做离开团队模型。你不能依赖其他团队为你工作，但你可以在他们的职责范围内工作。基本思想是你派一个或多个人到另一个团队。他们在他们的代码库中完成工作。这不是真正的嵌入，因为他们在有限的时间内在那里工作。他们与其他团队的互动方式也很灵活。他们可以完全独立，也可以让团队中的某个人提供帮助。
- 在您的组织中为此制定规范将有助于客队取得成功。制定贡献标准也会有所帮助。我发现让其他团队的某个人与客队成员一起工作并指导他们很有用。但如果你有严格的规范和标准，那可能就没有必要了。
- 重要的是工作与其他团队的目标兼容。所以通常这需要对话。有时，其他团队甚至可能没有足够的带宽来进行这些讨论。在这些情况下，您可能不走运。
- 我稍后会写一篇关于这个模型的更长的文章。
为关键项目组建一个工作组
- 如果工作很关键，则可能需要一个工作组。通过工作组，您可以组建一个临时团队来跨几个团队完成工作。特遣队有缺点，可能具有破坏性。所以你应该只在紧急情况下使用它们。
- 工作组不会帮助您让其他团队完成您的工作。
说服老虎团队为您做这件事
- 如果其他团队太忙，有时您可以说服一个老虎团队来代替。这是一种凌乱的做事方式，但在某些情况下它可以工作。
如果可以，请加入实践社区
- 一些实践社区开发了推动工作的方法。如果您需要的工作与实践社区一致，您就可以利用这一点。