# 团队设计
康威定律指出，一个系统的设计很可能反映出了团队的沟通结构，单体团队倾向于单体架构，根据全后端业务逻辑分离的团队倾向于分层架构，拥有不同产品模块的团队倾向于模块化架构。团队内部的协作通常是根据需要即兴、持续的发生，多数团队设计都着眼于面向业务活动对人员进行组织分配，敏捷组织设计中倡导跨职能业务导向，从团队成果角度来进行设计。
让团队为业务成果负责，而不是为了业务活动负责就要先看看什么是业务成果。例如，出售产品并得到收益，这就是业务成果，成果就是如市场调研、客户引导、产品设计、功能开发、集成测试等一系列活动构成的结果。为了获得成果，常常会把一个长链条的过程划分成若干子成果，子成果本身不那么有价值，只有作为整体业务的一部分他们才会显得重要。
成果与活动的区别类似于用户故事和任务的区别，将成果划分成子成果，就如同把一个特性划分成多个用户故事，而活动只是为了实现这些用户故事价值所经历的任务，任务不比是独立的，也不必有价值。所以，在企业中要围绕着结果来组建团队，而不是围绕活动来组建团队。把自主权赋予一个成果导向的团队，因为成功具有独立的价值，所以围绕着成果局部优化的危害要小得多。对成功负责，也会让团队更有使命感，团队能看到自己的付出获得了对应的商业价值，这就是一种内驱力。
好的业务成果不仅具有独立价值，而且能够独立达成。无论是企业，还是国家机构，组织的根本挑战是一样的，中心化配置容易剥夺下属单位的自主权，而在去中心化的配置中，下级单位往往会小心翼翼的保卫他们局部层次的自主权，如果这种自卫意识使得各单位间的协调行动成为问题，久而久之这些单位就会形成一个个隐形的“仓囱”。IT组织本身就是只能垂直的组织架构，是潜在的“仓囱”。它常常不是面向市场的，而是经常被视为成本中心，IT用来支撑业务。
在数字化转型的过程中，业务和IT可能出现巨大是鸿沟，软件迭代的过程是一个需要业务和IT紧密合作的过程，由利润中心向成本中心下命令的想法，往往会事与愿违。在这个过程里，组织会出现多个团队共同负责同一个结果的情况出现，一旦形成这种现象，就会降低成果兑现的效能和减少取得成果的几率。因为，同一个团队成员不需要安排会议就可以相互合作，而跨部门协作流程和间接步骤过多，会成为协同共进的直接阻力。
跨职能团队是指团队成员拥有不同的专长，为了一个共同成果而一起工作。这是按业务成果而非活动来组织团队的必然结果，成果的实现涉及到不同的活动，这就需要让拥有广泛不同技能的人员共同组成一个团队。跨职能团队将整个软件交付价值流纳入一个团队，这样可以减少交接成本，进而可以降低批次规模，最终减少周期时间，提高响应速度。
为了更高效的跨职能协作，我们不仅要有良好的专业深度，同时也需要扩展一些广度，专业广度能提供更宽广的视角和共情能力，T型人才可以更容易的与他们领域之外的思想建立连接，并在此基础上有所建树。从矩阵式的IT部门转变为自足是跨职能团队是一个相当有颠覆性的转型过程，下面是一个渐进转移的方法：
- 识别出创造业务差异化的产品/功能。有多少个差异化的产品就可以有多少个跨职能团队。
- 选出一个产品进行试点转型。最好试点的产品和其他产品没有太多依赖关系，确保该产品有一个全职的成果负责人。
- 让产品负责人提供初步的产品路线图和待办事项。
- 从现有的职能团队中挑选出试点团队成员，向他们解释这次试点。
- 确保试点图案多拥有所必要的技能，能自给自足。
- 让新团队开始处理待办列表。
- 将这个团队的能力共享给新的团队。
跨职能团队鼓励成员从专才变为通才，在没有职能组织的情况下，实践社区是培养技能的替代方案，实践社区可以保持团队IT专业技能的专精，它有一个线上线下交流和知识共享的机制。实践社区可以组织分享会、对员工进行培训、进行内部研讨会、保荐团队成员参加外部研讨活动。