Building a multidisciplinary team allows the members to wear multiple hats, and swap hats based on need, they can focus on what matters, delivering user value.
Hiring or contracting specialists for specific team roles such as QA, Testers or DevOps Engineers and Developers who specialise on specific technologies, can lead to problems as your team focus becomes delivering outputs. 如果你不把他们固定在一个盒子里，他们可能会提供更多的东西，并为你的团队增加价值.
To explore this topic we’ll look at the following example teams, Team A and Team B.
Team A has:
- Backend Developer
- Frontend Developer
- Tester
- User Researcher
- Product Manager
- Delivery Manager
Team B has:
- Three Developers
- User Researcher
- Product Manager
- Delivery Manager
团队A由3名专家组成:后端开发人员，前端开发人员和测试人员. 然而，在团队B中，我们有3名开发人员，他们能够处理系统的各个方面. 在我们假设的情况下，我们有一堆积压的问题，我们已经做了一些工作，我们知道我们应该建立什么来帮助公民实现他们的目标. So, we start to get to work.
In both team A and B everything is looking good. The teams are communicating and collaborating well, there’s a good split of work between the team members.
我们已经进行了2个sprint，我们已经开发了一些功能，并且能够与用户一起测试真实的应用程序. 我们得到一些最初的用户反馈，发现我们的一个假设是错误的，我们需要调整. 我们最初以简单的业务逻辑开始我们的服务，它需要扩展以满足用户的目标. 我们发现，为我们的服务提供动力的后端应用程序需要比以前想象的复杂得多.
团队B能够毫无问题地响应这个问题，因为我们的开发人员能够处理我们服务的各个方面. 由于团队B没有测试人员，团队确定他们需要做一些手工质量保证，以确保他们在获得用户反馈之前已经理解了复杂的业务规则. As the developers don’t have a tester in their team, 他们要求产品经理和一位没有参与过该功能的开发人员亲自测试. 一切都很顺利，因为他们能够分割所有的工作，并对用户的其他重要反馈做出反应.
Team A is struggling. We’ve only got one person who’s working on the backend application. 前端开发人员没有足够的信心在他们不熟悉的领域工作, and has no interest in that area. On top of this, they’re also facing pressure that the team has to deliver. 后端开发人员现在觉得他们需要急于交付并开始走捷径. 他们停止编写全面的测试，并把责任抛给测试人员去承担. This slows the backend developer’s feedback loop. Instead of knowing some code that they wrote isn’t correct at the time of writing, it’s now taking days to get that same feedback. The frontend developer is now waiting for the backend application to be complete. They’re looking for things to do, but they’re happy that it’s not their fault that the team’s velocity has decreased.
把全部责任交给团队中的个人，而不是作为一个团队承担责任，可能会导致像责备文化这样的有害行为. 团队A的开发人员现在专注于他们可以控制的输出，而不是整个过程. 这方面的一个例子是，一个由专家组成的团队在他们的待办事项中有非常基于系统和技术的票证. 与团队B的票相比，团队B的票关注的是用户故事，关注的是需要对一个或多个系统进行更改的结果.
我创建这个例子是为了强调专注于输出是多么容易对交付过程的不同部分产生负面影响. 比如前端开发人员和测试人员可以利用他们的专长来避免帮助解决问题. 重要的是要注意，当事情开始出错时，像团队B这样的团队并不总是成功的. 你仍然需要确保你的团队与他们需要/想要交付的结果保持一致.
关注我们正在交付的结果，并使团队能够分担交付的所有方面的责任, we build a shared drive to deliver. Having a team of generalists, 他们更有可能在工作中自我组织，并寻求彼此的支持. However, if you do have specialists, 关键是要有一个强大的产品经理/交付经理，专注于交付结果，指明方向. 需要密切关注，以确保专家们专注于取得成果.
有时候，我们确实需要专家来解决我们理解得很好的具体问题，并给出明确的结果. 例如，团队B正在考虑将他们的新系统与特定的遗留应用程序集成. However, none of the team are familiar with this technology, and they have a deadline to deliver a Minimal Viable Product. Here, 引进一名专家是有意义的，他可以帮助提高团队的技能，使他们拥有快速进步的知识. 我们不希望在这里发生的是，将系统集成在一起的全部责任完全落在这个专家身上, siloing a critical path of the service.
Your team should not generally be built around specialisms, 在团队中，放大有害行为并鼓励这些行为太容易了. 专家更有可能在他们的专业领域内工作，并开始产生其他问题，如知识差距, silos, blockers and half finished solutions. Team B would work together to solve problems, 允许他们分享知识，并确保每个人都有相同的理解水平. 然而，在团队A中，特定的系统知识只存在于特定的个人中. This opens up other problems, 例如，如果团队成员不可用，这将影响团队交付的能力, effectively blocking the whole team.
有时候，我们的用户无法选择是否使用我们构建的服务. 我们应该尽最大努力确保我们构建的软件通过关注结果而不是输出来交付实际价值.
