乍一看，这个工程问题很常见。但其实，它蕴含着非常深刻的哲学问题。也就是说，到底是代码编写的速度重要，还是代码编写的质量重要。这些涉及到价值观的问题，会让技术分歧进一步演化成派别分歧，导致小团体的产生。

　　5. 团队和办公室结构

　　介绍了这么多，很明显，Grosse和Loftesness都是跨功能团队的支持者。他们倾向于将这种团队称为“送货团队”，来强调他们是在同一个目标下进行合作的。换句话说，只要是与产品和服务有关的人，都应该加入这个团队。

　　有不少初创企业在研发产品时，过度重视工程师，大量雇用开发人员，从而忽视了设计和营销等方面，导致这类人才的缺乏。在这种情况下，产品经理作为整个团队的负责人，是非常无助的，就像无头苍蝇一样。因为一支规模较大的团队要是没有基础设施的支持，是无法实现高效率生产和运作的。更糟糕的是，当不同工程团队发现自己不得不为了资源与对方争夺时，就可能会拉帮结派，形成小团体。

　　在SoundCloud，团队负责人在接到上级命令雇用顶尖工程师来提高生产效率时，会先征求团队成员的意见，问他们在日常工作中是哪个步骤拖慢了整体进度。如果成员们一致认为缺少设计师，而不是工程师，那么公司就应该雇用更多设计师。一味地去雇用更多工程师，只会适得其反，让问题更加麻烦。

　　另外，以产品为导向组建起跨功能团队之后，你还需要提供各个部分需要的资源，让他们自己掌握全部的所有权和决定权。

　　随着公司的发展，“团结一致”这个概念可能会引发逻辑问题，但这并不能成为放弃组建跨功能团队的理由。一般情况下，公司都会在不同城市甚至不同国家开设办事处，所以说领导人一定要仔细斟酌该把谁派去哪个办事处。比如说，一个办事处在旧金山，一个办事处在九个小时路程以外的欧洲。很明显，在旧金山工作的人，是不可能完全了解欧洲员工的需求的。

　　在全球化的今天，这个问题已经越来越常见。不少企业都为了控制运营成本，而降低工程师的质量。但其实，这样做是不对的。因为这样省下来的钱，根本无法弥补低效率带来的损失。所以说，最好的解决办法，就是一个办事处只负责一款产品。只有这样，所有必要的资源才能够集中到特定产品的研发过程中去。

　　结语

　　其实，与大型企业相比，早期初创企业同样很容易出现拉帮结派的问题。虽然它们永远没办法找到一种十全十美的方法来解决小团体问题，但只要从员工招聘、入职培训、职位调配、技术选用和团队结构这五个方面出发，就能够找到妥善处理不同部门和团队之间分歧的方法。