当当正版 敏捷组织设计 面向数字化转型和持续交付的组织重构 [美] 斯里拉姆·纳拉扬 著，熊节 译 著 9787302599685 清华大学出版社

在大多数企业，IT 的表现都不如人意。IT 要为业务赋能尚且费力，更别说扮演差异化要素了。IT 不给力造成的一个结果是，业务和技术（IT）经常剑拔弩张。这对数字化转型来说不是个好兆头。我认为，糟糕的组织设计是造成这种遗憾的主要原因。2014 年 6 月麦肯锡的全球调查①也表明，在大型企业中，组织结构问题被认为是实现数字化目标的主要障碍。
企业管理者通常会从非行业特色的视角看待组织设计，将其视为纯粹是 HR 领域的事。然而在筹划组织重组时，又很少只从 HR 角度入手。与传统的观念不同，本书探索了如何从 IT 领导力的视角进行组织设计，从而给组织设计提供一个可靠的基础。这个基础的建立很重要，因为在实践中，IT 组织的设计很少从基本原则出发通盘考虑。时下常见的组织设计大多是偶然的产物，可能是并购的结果，或是为了留住员工而做的妥协，亦或是组织各层级领导的主意。这就跟软件中逐渐堆积的技术债一样，我们必须时不时退后一步审视组织的设计，否则组织设计也会逐渐腐化。
21 世纪的组织设计不仅涉及组织结构，而且还事关企业文化、团队政治、经营管理甚至物理空间。综合个人的行业经验，现有的关于组织设计、精益和敏捷的文献以及一些广受好评的个人和团队心理学的著作，我提出一套关于敏捷组织设计的理论。本书针对组织结构和经营管理配置提出的建议，很多已经被几家新生代的独立软件开发商所应用。我也解释了其他企业的 IT 部门如何能够从中受益。与此同时，本书中涉及团队政治和企业文化的章节，无论对独立软件开发商还是企业 IT 部门，都同样适用。
有几位审稿人出于好意，建议我在书名中使用“精益”而不是“敏捷”，以便卖得好一些。显然，如今精益更流行，而敏捷已经过时了。但终我还是选择了以“敏捷”为题，因为敏捷非常重视以人为本，而这正是我提出的解决方案的核心。
① https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/the?digital-tipping-point-mckinsey-global-survey-results
时下流行的写书风格是把一篇文章的内容扩充成一本书。而本书恰恰相反，我把大量主题融为一本书，因为我相信这些主题是相互联系的，需要加以综合论述。本书涉及的主题很广，反映出一个现实：IT 领导角色需要关心的范围很广。当然，一本书无法穷尽所有相关问题。诸如创新、知识管理、人员多样性、绩效评估等主题没有在本书中涵盖或者只是捎带提及。
这里涉及的许多主题都属于 IT 治理的范围。但是，传统的 IT 治理过早地陷入了对标准和框架的讨论。本书的讨论基本上和标准和框架无关。此外，本书所讨论的文化方面一般不被认为是 IT 治理的范畴。
本书不是手把手教你操作的菜谱。我描述问题、探索原因并提供解决方案。然而，我并没有详细说明实施解决方案的步骤。只有几个章节提供了从现状迁移的步骤。此外，后一章有一个小节针对几种推荐方案的采用顺序提供了建议。但总的来说，迁移的规划需要在具体背景中制定。我希望读者可以借鉴本书提供的建议，规划他们自己的迁移过程。此外，我也可以提供咨询服务。
本书中提出的许多建议已经在现实世界中取得了一定的成功。只要有公开的成功或失败的证据，我都在书中列举出来。即使没有直接的公开证据，本书中的建议也有来自一线经验的理由和例子提供支持。一旦意识到传统方法没有带来预期的效果，我们就会更容易认真考虑本书建议的替代方案。
我提供了许多小故事来说明现状问题。它们的灵感来自于真实案例，但隐去了公司名称、人名和其他细节。如有雷同，纯属巧合。它们不是完整的故事，也没有终结论。然而，故事之后的章节提供了处理问题的方法。越是能够将这些情景与自己的经历联系起来，就越会发现本章的其他内容具有启发性。书中提及的很多例子都来自电子商务（网上零售）领域，以便不同背景的读者都能理解。
前面四个章节是阅读本书其他章节的前提。第 8、9、10 章分别讲了项目、财务和人员配置，它们是一个整体。其余各章可以独立阅读。尽管我努力将相关的讨论放在一起，但各章之间仍有许多交叉引用。这也表明这些主题是相互关联的。
鉴于本书涉及的范围很广，我不得不提炼了一些次一级的主题。但我又不想花太多精力去解释这些次级主题。作为补充，我在文中提供了章后注，链接到网上可靠来源的免费解释（不采用离线或付费的来源）。读者可以从本书的配套网站agileorgdesign.com 获取这些链接。
本书适合以下读者阅读和参考：
● 参与组织设计或治理的执行官和其他决策者
● 独立软件开发商和互联网企业的高级管理人员
● 负责 IT、产品管理、工程或软件开发的副总裁、董事或主管
● 与 IT 部门和 IT 业务伙伴对接的业务主管
● 财务控制、财务分析员和投资经理
● 数字化业务的投资者
● 关心高层领导意见的技术人员
● ICT 战略制定者
● IT 治理小组成员
● 流程质量 /SEPG 小组成员、流程顾问和教练
本书服务于面临 IT 和业务敏捷挑战的大中型 IT 组织（50 至数千名 IT 员工）。我所说的 IT 组织，可能直接服务于业务（即软件本身就是业务，例如独立软件开发商），也可能间接服务于业务（例如互联网业务和企业 IT）。也就是说，IT 供应商（IT服务公司）也可以利用本书中的内容更有效地与客户协作。
为什么“投资者”也会出现在目标读者对象中？组织设计中的问题不会立即在财务报表中显示出来。然而从长远来看，它们有可能是决定商业成败的关键。由于投资周期往往比高管任期更长，所以数字化业务的投资者好能了解这个话题，并要求高管承担起相应的责任。如果已经实施 IT 敏捷和业务敏捷，本书的内容可能看起来显而易见或者老生常谈。然而，你可能会遇到一些新的角度、观点或技术。也就是说，这绝不是一本入门级的书。它假定读者有一定的软件交付经验，至少要了解 Scrum 或 XP 等敏捷方法以及 DevOps 和持续交付的基本理念。

和thoughtworks资深人士斯里拉姆:纳拉扬(Sriram Narayan)展示了如何将敏捷性注入整个组织中。

依托于超过15年的IT密集型行业企业客户合作经验,他对”业务-IT有效性”提出了-种灵活的方法,

这种方法非常实用,很有价值。作者展示了组织设计的结构、政治、运营和文化方面如何影响组织整

体_上的敏捷性以及如何促进从销售和营销到产品开发、I程到IT运营等不同职能的更好协作。通过

真实的例子,作者可以帮助您评估和改进组织设计,从而增强自主性、掌握性和目的性,这三大要素

是激励员工的关键。

斯里拉姆·纳拉扬(Sriram Narayan)
在Thoughtworks先后担任IT管理顾问（为电信、金融服务、能源、零售和互联网行业的客户提供IT敏捷指导）、领导力教练和创新总监。他是Thoughtworks技术顾问委员会的创始成员，该委员会现在负责编撰Thoughtworks的“技术雷达”。在Thoughtworks产品部门工作的两年时间里，他参与了产品创新和持续交付工具Go的市场宣传。他还有开发人员、开源贡献人员、管理人员、产品负责人、测试员、SOA架构师、培训师和敏捷教练等多个身份。他偶尔也写博客和在大会上发表演讲，可以访问sriramnarayan.com，进一步了解他的著作、演讲和联系信息。
熊  节
中国早的敏捷实践者之一，引领和参与了敏捷在中国的发展历程，亲自指导多家知名企业实现敏捷及数字化转型，译著代表作品有《重构》和《敏捷中国史话》等。熊节发起并成立了“极限编程合作社”，致力于帮助中国企业重回敏捷正道。

第 1 章 背景   1
1.1 焦点     3
1.2 业务、IT 以及影子 IT   4
1.3 业务 -IT 的效能     5
1.4 数字化转型    8
1.5 双模 IT 及双操作系统  11
1.6 涵盖角度     12
1.7 小结    13
第 2 章 敏捷信条    15
2.1 理解“敏捷宣言”   16
2.1.1 个例子     16
2.1.2 第二个例子     17
2.2 持续交付与 DevOps    17
2.3 敏捷文化     19
2.4 常见主题     20
2.4.1 快速失败    20
2.4.2 迭代优于增量    21
2.4.3 价值流优化     23
2.4.4 信息辐射器     24
2.5 敏捷已死     24
2.6 小结    26
第 3 章 核心主题    29
3.1 重新审视软件开发   30
3.1.1 源代码和二进制包不是产品   31
3.1.2 产品是用户或客户使用的东西    31
3.1.3 软件开发是设计过程     32
3.2 治理的目的是追求价值而非可预测性   34
3.3 组织的目的是响应变化而非优化成本效益   35
3.4 设计的目的是激发内在驱动力和即兴协作   39
3.4.1 自主   40
3.4.2 专精   40
3.4.3 目的   40
3.4.4 即兴协作    41
3.4.5 一种有机的方法    41
3.5 小结    41
第 4 章 上层建筑    43
4.1 业务的活动与成果   44
4.1.1 成果导向赋能自主  46
4.1.2 成果的责任人    47
4.1.3 成果的设计     48
4.2 中心化与去中心化   49
4.3 竖井    50
4.3.1 业务 -IT 鸿沟     51
4.3.2 IT 组织内的竖井    51
4.3.3 高阶竖井    52
4.4 观点小结     54
4.5 行动小结     54
第 5 章 团队设计    57
5.1 提出问题     58
5.2 职能团队     59
5.2.1 高延迟交接导致停滞     60
5.2.2 职能团队的传统诱惑     63
5.2.3 什么情况下可以有职能团队   64
5.2.4 独立的测试、验证、确认   65
5.3 共享服务     66
5.3.1 共享团队会失去目标     66
5.3.2 减少共享团队间的摩擦   67
5.4 跨职能团队     68
5.4.1 DevOps = 跨职能开发团队   IT 运维团队   70
5.4.2 响应式组织     70
5.4.3 利用率    72
5.4.4 T 型人才     72
5.4.5 团队规模    72
5.5 其他领域的跨职能   73
5.5.1 医院 Pod 团队    73
5.5.2 跨职能博物馆布局  74
5.5.3 分任务系统     74
5.6 向跨职能团队迁移   75
5.7 实践社区     77
5.8 维护团队     77
5.9 外包    79
5.10 矩阵：解决还是解散  81
5.10.1 共享服务矩阵   83
5.10.2 专有产能和可替换人员矩阵     83
5.10.3 专有产能和专有人员矩阵  83
5.10.4 单体跨职能产品团队    83
5.10.5 由面向活动的子团队组成的跨职能配置   84
5.10.6 由面向成果的子团队组成的跨职能团队   84
5.11 观点小结    85
5.12 行动小结    86
第 6 章 问责制     89
6.1 权力和层级     90
6.2 运用问责制平衡自主性     91
6.3 责任分配     92
6.3.1 谁来对结果负责    93
6.3.2 责任地图    94
6.4 小化权力斗争     96
6.4.1 矩阵瘫痪    97
6.4.2 的层级     97
6.4.3 教授 - 企业家     98
6.5 确定成果负责人    100
6.6 迁移     101
6.7 决策问责    102
6.7.1 决策记录   104
6.7.2 工具     105
6.7.3 范围     106
6.7.4 阻力     107
6.8 计划和执行    108
6.8.1 分离的危害     109
6.8.2 森林和树木     111
6.8.3 职责重叠   112
6.8.4 应对阻力   113
6.9 组织债   114
6.10 观点小结     115
6.11 行动小结     115
第 7 章 一致性    117
7.1 阐明通用一致性的战略     118
7.2 IT 与业务对齐    120
7.2.1 MIT 的运营模式   122
7.2.2 步速分层应用策略     123
7.2.3 一致性图   124
7.3 结构一致    126
7.4 让业务发挥作用    126
7.5 观点小结    127
7.6 行动小结    128
第 8 章 项目      129
8.1 计划驱动的软件项目怎么了   130
8.2 为能力而非项目编制预算   131
8.3 以业务能力为中心的 IT     133
8.4 项目商业论证     136
8.4.1 持续交付和分析支持的收益验证   138
8.4.2 弱化金融商业论证     138
8.5 价值驱动型项目    139
8.6 项目经理    140
8.7 治理     141
8.8 变革计划和倡议    142
8.8.1 数字化转型计划   143
8.8.2 限制在制品数量   143
8.9 观点小结    145
8.10 行动小结     145
第 9 章 财务      149
9.1 相关性   150
9.2 成本中心还是利润中心     150
9.3 内部结算    151
9.4 资本支出和运营支出  152
9.4.1 不依赖考勤表的资本支出和运营支出会计     153
9.4.2 活动分类   155
9.5 传统预算    155
9.5.1 目标     156
9.5.2 预算编制   157
9.6 敏捷预算    157
9.6.1 敏捷式滚动预算   158
9.6.2 协作式预算编制   159
9.6.3 企业 IT 的风险投资     160
9.7 观点小结    161
9.8 行动小结    161
第 10 章 人员配置    163
10.1 应对人才危机     164
10.1.1 限制范围和复杂度     165
10.1.2 组织设计助力人才留存   166
10.2 超越项目团队     166
10.2.1 成本    167
10.2.2 挑战    168
10.2.3 其他反对意见    168
10.3 改进人员配置     169
10.3.1 按技能而非角色配置人员   169
10.3.2 职衔    171
10.3.3 剖析技能     172
10.3.4 避免兼职任务    174
10.3.5 团队个性组合    174
10.4 观点小结     175
10.5 行动小结     176
第 11 章 工具     177
11.1 鼓励即兴协作的访问控制    178
11.2 工具链的微妙影响   179
11.2.1 工具访问的竖井  179
11.2.2 工具使用的竖井  181
11.2.3 工具专业化的竖井     182
11.3 技术并非价值中立   183
11.4 工具评估     187
11.5 观点小结     188
11.6 行动小结     188
第 12 章 指标     191
12.1 指标不能说明全部情况    192
12.1.1 能够度量，不能预测   193
12.1.2 速率    193
12.1.3 应对未知的未知  194
12.2 仪表盘促进无知   195
12.3 目标和奖励的问题   196
12.3.1 目标会诱发局部优化   198
12.3.2 目标是一种控制机制   201
12.3.3 目标和奖励侵蚀内在激励因素    201
12.3.4 目标导致博弈    203
12.3.5 古德哈特定律    205
12.3.6 隐含的目标    206
12.3.7 目标隐含着奖励  206
12.4 改革指标体系     207
12.4.1 取消奖励措施    208
12.4.2 逐步放宽目标    209
12.4.3 允许评估     209
12.5 设计更好的指标   212
12.5.1 成果导向的指标优于职能导向的指标    212
12.5.2 聚合的指标优于特定细粒度的指标    213