前言
最近读完了段念推荐的《管理 3.0：培养和提升敏捷领导力》，本书是一本结构规整的书，全书将管理理论用六个维度来阐述，然后每个维度下，先讲理论，再讲实践中的故事。
在作者 Jurgen Appelo 的理解下，管理的六个维度是：
- 激励员工：保持员工的活力、创造力和积极性。
- 授权团队：如何进行自组织。
- 调合约束：如何保护人力资源以及如何共享资源。
- 培养能力：如何提高员工技能和提高竞争力。
- 壮大组织：如何实现组织的成长。
- 全面改进：如何进行改进。
本书对我来说，收获最大的是「壮大组织」（第 12，13 章）部分所介绍的实践。很多想法我自己本身有一些体会，看到书中的介绍就更加清楚了，以下是这部分的一些想法。
专业主义
书中提到了专业人才，并且认为专业人才应该是优先被考虑的人才结构。这点我很认同，但是它和部分业界的观点不同。
比如，业界一直在追捧「全栈」工程师，但是其实大部分所谓的「全栈」工程师，是指同时写 Web 前端和后台逻辑。这里的后台逻辑通常也偏业务逻辑一些，不涉及太多的高并发问题。所以，「全栈」工程师更多时候是一种特定业务场景下的需求，在这些特定业务场景下，「全栈」的工程师可以省去沟通前后端接口约定的沟通工作，在出现问题后，也更加便于排查。在 Nodejs 流行后，由于前后端可以统一编程语言，进而可以统一渲染模版，前端工程师更加有动力参与到部分后端的工作中。
但是，「全栈」工程师也仅限于此，涉及到更专业的领域时，组织还是更倾向于使用专业人才。不信的话，你可以问问，很少有人同时做 iOS 和 Android 端的开发，也很少有人同时做客户端和服务器端的「全栈」开发。
但是，在一方面专精，同时对于其它方面又有广泛了解的人员会带来更多的沟通和协作上的效率提升，所以我们都强调培养 T 型人才。T 型人才指在某一方面专长，但是又有着不错的知识面的人。比如 iOS 开发者，如果同时能懂一些产品、交互、服务器端的知识，那么在合作上就会舒服得多。
扁平层级与非正式领导力
过多的管理层级带来效率低下的沟通和决策过程，所以现在的互联网公司都提倡扁平化的层级。但是在扁平化的层级下同样需要合作和决策，这个时候非正式的领导力就变得更加重要了。
非正式领导力在我们公司并没有被明确提出来，但是它确实反复存在。非正式的领导力在跨部门合作的时候变得异常重要，而这里面也涉及大量的沟通技巧。
职能型团队 vs 跨职能型团队
这是我又一次见到相关的讨论了，在格鲁夫的《给经理人的第一课》里面也提到了相同的问题。当时，格鲁夫的观点是采用「混合型组织」和「双重汇报」的方式来解决。而本书的作者提出了另外一个思考的角度：沟通的频繁程度。
本书的作者认为，按照复杂系统理论，达成一件事情需要的沟通总量是不变的，所以我们应该让组织的形式更加易于沟通。所以一个人的工作应该归属于职能型团队还是跨职能型团队，就看他和哪边的沟通工作更多。
在这种思考的角度下，作者认为以产品为单位的跨职能型团队是更加符合沟通需求的。因为在开发一款产品时，PM 与开发需要密切地沟通合作，客户端与服务器的开发也需要密切的沟通合作。所以我们应该把他们放在一个团队中，而不应该分开到不同的职能型团队中。
有意思的是，「跨职能型团队」与「决策由组织间自行沟通解决」就构成了敏捷开发中的 Scrum of Scrum 模式。
作者在本书中认为（并且他指明具有争议），项目管理、架构级模块、用户界面设计、硬件设计、测试是专业性很强的工作，并且沟通量并没有那么大，可以用职能型专家团队来完成。但是需要服务好项目团队，由项目团队判断职能团队的价值并且建立合适的沟通渠道。
适应
作者强调企业的组织方式并不是一层不变的，我们可以不变调整适应，如果觉得不合适，就可以继续调整。比如我们发现需要构建出一些架构级的模块时，我们可以临时组建专家团队，当这方面的工作变少时，我们也可以选择将专家团队解散。
总结
本书还有一些小的翻译问题，例如 P13 把授权团队翻译成赋能团队，P109 把凯文·凯利翻译成科里。
本书的理论部分太过散乱，并且没有重点。实践部分的各章节也不成系统。如果为了节省时间，可以直接看每一章最后的小结，从小结中就可以看出结论非常散。
就像本书最后说的那样，不同的管理理论有不同的模型，本书的六大模型并不一定是正确的，它更多是一种看问题的可选角度。所有模型都有错，但有一部分是有用处的就行了，为方法、框架、原则和实践争得死去活来真的没有必要。
本书对于我的价值，就是再一次思考了组织在壮大过程中的各种问题的解决方案，我们公司的团队正在经历人员增长，跨部门的合作也遇到了很多问题，本书有助于我理解这其中的原因。
最后是我整理出来的知识脉络思维导图，这份图带有我个人的主观色彩，一些我不认同的观点没有整理在里面。
