When developing applications there will be requirements that are needed on more than one application. Examples of such common requirements are non-functional, cookie consent and design patterns. How can we work with these types of requirements in a smart way across several applications and teams, without adding bureaucracy and increased lead time?

开发应用程序时，将需要多个应用程序的需求。 此类常见要求的示例包括非功能性，Cookie同意和设计模式。 在不增加官僚主义和增加交货时间的情况下，我们如何在多个应用程序和团队中以明智的方式满足这些类型的需求？

It is a common challenge, that we work in silos, developing “our own” application within one organization. Each application has their stakeholders, product owner, scrum master, user experience, business analyst, architect, developers… In the beginning it’s fine if you only have a few applications running, however what happens when you have 10 applications running? Consider each product team spending 8 hours analyzing a requirement, that means the organization is potentially wasting 72 hours on each requirement. And not only is it a waste during the initial development, consider the amount of waste during the full life-cycle from that one requirement.

一个普遍的挑战是，我们在孤岛上工作，在一个组织内开发“我们自己的”应用程序。 每个应用程序都有其利益相关者，产品所有者，Scrum管理员，用户体验，业务分析师，架构师，开发人员...刚开始时，如果只运行几个应用程序就可以了，但是当您运行10个应用程序时会发生什么呢？ 考虑每个产品团队花费8个小时来分析需求，这意味着组织可能在每个需求上浪费72个小时。 不仅在最初的开发过程中浪费了资源，还考虑了该需求在整个生命周期中的浪费量。

So why do we implement solutions in silos? The answer is that it’s often quicker. We want to deliver with speed to the market, and it’s often easier and faster to do the solution within the team rather than having to rely on other teams, their priorities and time available. Autonomy in all its glory, but sometimes it makes more sense to work across product teams to ensure we work smart and deliver sustainable solutions. And does it really have to take longer just because we work across several product teams?

那么为什么我们要在孤岛中实施解决方案呢？ 答案是它通常更快。 我们希望将产品快速推向市场，通常在团队内完成解决方案变得越来越容易，而不必依赖其他团队，他们的优先级和可用时间。 自治具有其所有的荣耀，但有时跨产品团队工作更有意义，以确保我们明智地工作并提供可持续的解决方案。 是否真的因为我们跨多个产品团队工作而需要花费更长的时间？

我们如何才能聪明地应对跨团队的需求？ (How can we work smart with cross-team requirements?)

How can we in practice work to implement these requirements in a smart way to all relevant applications? There is, of course, the Spotify model, but if it’s too big a change or not the route you want to go down, this could be something to try out.

在实践中，我们如何才能以明智的方式对所有相关应用程序实现这些要求？ 当然，有Spotify模型，但是如果变化太大或您不想沿途走的路线，可以尝试一下。

1. Someone has an idea or are working on a requirement when they realize that this is a requirement that would bring value to other applications within the organization as well.
   当某人意识到这是一个需求，并且会为组织内的其他应用程序带来价值时，他们就有想法或正在研究需求。
2. All product owners meet to discuss the requirement, perform a quick analysis to determine if it brings value, if it’s achievable and if it’s a priority right now within the organization. They collaboratively make a decision on how to best move forward, they set a course of action. The course of action might be that it should be developed by two teams that will work together on further analyzing and developing the solution.
   所有产品负责人开会讨论需求，进行快速分析，以确定它是否带来了价值，是否可以实现以及当前是否已成为组织内的优先事项。 他们共同决定如何最好地前进，并制定了行动方案。 行动过程可能是由两个团队共同开发，这两个团队将共同努力进一步分析和开发解决方案。
3. The two product teams collaborate and do a more thorough analysis to determine the smartest and most sustainable solution for the organization as a whole. Once implemented on one application (possibly as a shared component), the other product teams use the created solution for a “quick” implementation on their applications.
   这两个产品团队合作并进行更彻底的分析，以确定整个组织最明智，最可持续的解决方案。 一旦在一个应用程序(可能作为共享组件)上实现，其他产品团队便使用创建的解决方案在其应用程序上实现“快速”实施。
4. The product owners update all product owners on status and inform about the chosen solution that are being implemented so that they can prepare their teams for what’s coming. Once all applications has implemented the requirement the requirement is set to done. The team does a quick retrospective to learn and adapt.
   产品负责人向所有产品负责人更新状态，并告知他们正在实施的所选解决方案，以便他们为即将发生的事情做好准备。 一旦所有应用程序都实现了需求，就将需求设置为完成。 团队进行快速回顾以学习和适应。

Benefits from working this way

这样工作的好处

• Transparency and cross-team collaboration
  透明度和跨团队合作
• Smart and cost-effective
  精巧且具有成本效益
• Speed in delivering critical changes on all applications
  加快在所有应用程序上交付关键变更的速度
• Align tech solutions and user experience
  调整技术解决方案和用户体验

顺利过渡到这种工作方式的先决条件是什么？ (What are the prerequisites for a smooth transition to this way of working?)

Stakeholder alignmentWhen delivering software, we deliver something the customer needs, that is technically feasible and sustainable and that works for the business. So why is there still so much politics involved? Most commonly due to team or product bonuses which leads to misalignment, endless discussions and incorrect priorities. Bonuses should only be based on total company success. This makes the decisions easier and everyone working towards one common, unified goal.

与利益相关者保持一致在交付软件时，我们交付客户需要的，技术上可行且可持续且对企业有效的东西。 那么为什么还涉及这么多的政治？ 最常见的是由于团队或产品的奖金而导致的偏差，无休止的讨论和不正确的优先级。 奖金仅应基于公司的整体成功。 这使决策更加容易，每个人都朝着一个共同的统一目标努力。

We are in this togetherCompany culture must be about the best for the company in totality. You get rewarded when you work for the best sustainable solution for the whole organization. There are, of course, times where speed is more important than quality, for example when performing proof-of-concept, to allow for early feedback, but then once you know you are building the right thing we need to take a step back and look at the best solution for the company.

我们在一起，公司文化必须对公司整体而言是最好的。 当您为整个组织寻求最佳的可持续解决方案时，您将获得奖励。 当然，在某些时候，速度比质量更重要，例如在进行概念验证时，可以及早反馈，但是一旦您知道要构建正确的东西，我们就需要退后一步，为公司寻找最佳解决方案。

Team missionTeams want to know they are working on creating value, they want to be proud of what they are developing, they want to work smart and rest assured that they are contributing to the overall organization in the best way possible. Contribution to the bigger picture has to be part of the culture and be part of each teams mission statement, cross-team collaboration should be noticed and rewarded.

团队使命团队希望知道他们正在努力创造价值，他们为自己的发展感到自豪，他们想要聪明地工作，并放心他们以最佳方式为整个组织做出了贡献。 对大局的贡献必须是文化的一部分，也是每个团队使命宣言的一部分，跨团队的合作应引起注意和奖励。

Let data and learning lead the decisionsThe challenge with working across teams is that more people are involved which leads to more opinions and ultimately to longer lead times. But with an agile mindset, basing the decisions on data and learning, it shouldn’t have to end up with endless discussions. The requirement that brings highest value is the one we work on first and the team that will tackle the initial solution is the team that is most fit to do so at that moment in time.

让数据和学习来领导决策跨团队工作所面临的挑战是，需要更多的人参与，这将导致更多的意见并最终导致更长的交付时间。 但是，基于敏捷的思维方式，将决策基于数据和学习，就不必结束无休止的讨论了。 带来最高价值的要求是我们首先致力于的，而解决初始解决方案的团队是当时最适合这样做的团队。

It’s important to clarify, that not everything is a common requirement. Your organization needs to decide what is and what is not; it should only be treated as a common requirement if it brings value by analyzing and delivering them in a cross-team collaborative way.

需要澄清的是，并不是所有的东西都是一个共同的要求。 您的组织需要决定什么是什么，什么不是。 只有通过以跨团队协作的方式分析和交付价值来带来价值时，才应将其视为一项共同需求。

我很想听听你的故事 (I would love to hear your story)

If you have faced or are facing a similar challenge, I would love to hear your story.

如果您面临或正面临类似的挑战，我很想听听您的故事。