作 者
斯凯尔顿 / 派斯
商业 · 知名作者 / 学者
商业 · 知名作者 / 学者
About the Book
书籍信息
In a Nutshell
一句话总览
软件团队常见的困境是：所有事情都在互相等，等评审、等发布、等另一个团队配合。两位长期实践者把这套复杂度变成了一套可操作的结构语言——用『四种基本团队类型』和『三种交互模式』来重新设计组织的协作拓扑。核心洞见是：团队的形状本身就是一种架构决策，它决定了沟通成本、信息流动速度和认知负荷的分配。书里给出的是一套诊断与设计工具，而不是一份组织架构图模板。
Core Frameworks
核心框架 / 概念
核心理念
CORE · 概念
- 四种基本团队类型：业务流对齐团队（端到端交付价值）、赋能团队（补齐能力缺口）、复杂子系统团队（封装高难度专业模块）、平台团队（提供自服务的内部能力）。
- 认知负荷三型：内在负荷（任务本身的复杂度）、外在负荷（工具与流程造成的多余摩擦）、相关负荷（用于建立理解与技能的时间）。
实操应用
ACTION · 落地
- 三种交互模式：协作（长时间紧密）、协作×（临时紧密）、X 协作（低耦合）。选错模式，代价由个人承担。
Key Principles
关键原则
为团队减负而不是给人加任务
Principle
技能升级是个人投资，减负是组织责任，两者要分开谈。
先定交互模式，再定组织图
Principle
团队间怎么协作决定了组织该长什么样，反过来会失败。
平台团队要卖能力不是卖人力
Principle
把内部服务做成有明确接口的产品，而不是随叫随到的支援。
Notable Quotes
金句摘抄
如果团队总是等别人，那问题多半不在人，在拓扑。
认知负荷是有限资源，超载时人会退回本能，而不是更好工作。
组织结构是团队拓扑的自然结果——先设计协作，再画架构图。
减小团队规模之前，先确认耦合关系是否真的需要那么紧密。
Takeaways
对工作和行动的行动启发
画出你所在组织的依赖地图
标出谁在等谁，统计跨团队等待占用了多少工时。
检查每个团队的认知负荷
问成员：真正困难的事，和让你疲惫的事，分别是什么？
把一次跨团队协作显性化
明确是协作、协作×还是 X 协作，别让默契替代约定。
为平台团队定义接口
内部服务也该有 SLA、有版本、有用户手册。
Who Should Read
适合谁读
技术管理者研发效能负责人组织设计咨询顾问正在扩张的创业团队