建立一个多学科团队可以让成员身兼数职, 根据需要交换帽子, 他们可以专注于重要的事情, 传递用户价值.
为特定的团队角色(如QA)雇佣或承包专家, 专门从事特定技术的测试人员或开发运维工程师和开发人员, 当你的团队专注于交付产出时，是否会导致问题. 如果你不把他们固定在一个盒子里，他们可能会提供更多的东西，并为你的团队增加价值.
为了探讨这个话题，我们将看看下面的例子团队，团队A和团队B.
A队有:
- 后台开发人员
- 前端开发人员
- 测试人员
- 用户研究
- 产品经理
- 交付经理
B组有:
- 三个开发人员
- 用户研究
- 产品经理
- 交付经理
团队A由3名专家组成:后端开发人员，前端开发人员和测试人员. 然而，在团队B中，我们有3名开发人员，他们能够处理系统的各个方面. 在我们假设的情况下，我们有一堆积压的问题，我们已经做了一些工作，我们知道我们应该建立什么来帮助公民实现他们的目标. 所以，我们开始工作.
在A队和B队中，一切看起来都很好. 团队沟通和合作良好, 团队成员之间的工作分配得很好.
我们已经进行了2个sprint，我们已经开发了一些功能，并且能够与用户一起测试真实的应用程序. 我们得到一些最初的用户反馈，发现我们的一个假设是错误的，我们需要调整. 我们最初以简单的业务逻辑开始我们的服务，它需要扩展以满足用户的目标. 我们发现，为我们的服务提供动力的后端应用程序需要比以前想象的复杂得多.
团队B能够毫无问题地响应这个问题，因为我们的开发人员能够处理我们服务的各个方面. 由于团队B没有测试人员，团队确定他们需要做一些手工质量保证，以确保他们在获得用户反馈之前已经理解了复杂的业务规则. 因为开发人员的团队中没有测试人员, 他们要求产品经理和一位没有参与过该功能的开发人员亲自测试. 一切都很顺利，因为他们能够分割所有的工作，并对用户的其他重要反馈做出反应.
A队举步维艰. 我们只有一个人负责后端应用程序. 前端开发人员没有足够的信心在他们不熟悉的领域工作, 而且对那个领域没有兴趣. 除此之外，他们还面临着团队必须交付的压力. 后端开发人员现在觉得他们需要急于交付并开始走捷径. 他们停止编写全面的测试，并把责任抛给测试人员去承担. 这减慢了后端开发人员的反馈循环. 而不是知道他们写的代码在写的时候是不正确的, 现在要花几天时间才能得到同样的反馈. 前端开发人员现在正在等待后端应用程序完成. 他们在找事情做, 但他们很高兴，团队的速度下降并不是他们的错.
把全部责任交给团队中的个人，而不是作为一个团队承担责任，可能会导致像责备文化这样的有害行为. 团队A的开发人员现在专注于他们可以控制的输出，而不是整个过程. 这方面的一个例子是，一个由专家组成的团队在他们的待办事项中有非常基于系统和技术的票证. 与团队B的票相比，团队B的票关注的是用户故事，关注的是需要对一个或多个系统进行更改的结果.
我创建这个例子是为了强调专注于输出是多么容易对交付过程的不同部分产生负面影响. 比如前端开发人员和测试人员可以利用他们的专长来避免帮助解决问题. 重要的是要注意，当事情开始出错时，像团队B这样的团队并不总是成功的. 你仍然需要确保你的团队与他们需要/想要交付的结果保持一致.
关注我们正在交付的结果，并使团队能够分担交付的所有方面的责任, 我们建立了一个共同的动力来交付. 拥有一个多面手团队, 他们更有可能在工作中自我组织，并寻求彼此的支持. 然而, 如果你有专家的话, 关键是要有一个强大的产品经理/交付经理，专注于交付结果，指明方向. 需要密切关注，以确保专家们专注于取得成果.
有时候，我们确实需要专家来解决我们理解得很好的具体问题，并给出明确的结果. 例如，团队B正在考虑将他们的新系统与特定的遗留应用程序集成. 然而, 团队中没有人熟悉这项技术, 他们有一个交付最小可行产品的截止日期. 在这里, 引进一名专家是有意义的，他可以帮助提高团队的技能，使他们拥有快速进步的知识. 我们不希望在这里发生的是，将系统集成在一起的全部责任完全落在这个专家身上, 隔离服务的关键路径.
你的团队不应该以专业为中心, 在团队中，放大有害行为并鼓励这些行为太容易了. 专家更有可能在他们的专业领域内工作，并开始产生其他问题，如知识差距, 筒仓, 阻滞剂和半成品溶液. 团队B将共同努力解决问题, 允许他们分享知识，并确保每个人都有相同的理解水平. 然而，在团队A中，特定的系统知识只存在于特定的个人中. 这就带来了其他问题, 例如，如果团队成员不可用，这将影响团队交付的能力, 有效地阻碍了整个团队.
有时候，我们的用户无法选择是否使用我们构建的服务. 我们应该尽最大努力确保我们构建的软件通过关注结果而不是输出来交付实际价值.
