高效能团队模式读后感精选

《高效能团队模式》是一本由Matthew Skelton / Manuel Pais著作，电子工业出版社出版的平装图书，本书定价：89.00元，页数：232，特精心收集的读后感，希望对大家能有帮助。

《高效能团队模式》读后感(一)：四种基本团队拓扑模式

将复杂的情况降低到简单的维度，能以正常人都能看懂的方式描述出来就是一件有价值的事情 四种团队类型，三种合作模式用以覆盖组织中复杂的团队设计 原则上还是以业务领域为主来划分领域，兼顾平台和赋能。 方法论上能消除以人的单个效率为追求的极致而转向团队的效果最大化，减少认知负荷，稳定人员的情况下进行团队力量进一步的提升，这就是进步。

《高效能团队模式》读后感(二)：基本上直给了

这些年业界软件研发组织架构最佳实践理论化的综述。 非常解惑。会对一些典型问题给出斩钉截铁的回答。我以往遇到同类问题因为问题复杂，相干方利益牵扯，没有一个一锤定音的站的住的理论支撑，最终结果往往陷入不了了之。如果早几年能把这本书掏出来，问题就简单多了。 翻译有些问题，导致某些概念和原意有错位，建议对照英文阅读。举个例子，“流动式团队”的原文是“stream-aligned team”。用stream容易表示出“一个又一个的排队出来”的意思。翻译成汉语的“流动”，stream所能表达的持续的有节奏的产出的意味全都没有了，加上受中文语境下“人员流动”的强概念干扰，反而让人误会是临时的不稳定的团队，和原意恰恰背道而驰。这是全书的最关键概念，既然不好翻译，不如直接援引英文。如果非要翻译成中文，叫“持续产出团队”或者“持续迭代团队”也更容易让人理解。

《高效能团队模式》读后感(三)：评

还是有很多思考的，devops的视角，康威定律的具体呈现，从人的角度来思考架构。

1. 考虑架构的时候一定要结合团队来考虑，如果先决定组织形态的话，那软件架构就定了一半；架构师的作用不仅仅是技术层面，合格的架构师需要有理解人的能力；

2. 团队的认知负荷和之前思考的团队压力有映射关系，认知负荷是另一层面的精神压力，影响不亚于实际的物质工作；思考如何度量认知负荷，团队规模扩大随着沟通半径扩大，认知负荷不是同比线性增长，会在不同场景、不同文化下有一定的倍数关系，所以团队能力的增长可能反而降低，和人月那本书是一个意思。

3. 上层很少关注认知负荷，核心关注需求的吞吐情况，认知负荷一定会在其中隐藏起作用；

4. 作为一线管理者，应当限制团队的认知负荷情况，这是对团队负责的做法；

5. 技术红利会随着组织变大摊薄，主要是组织变化没有享受到技术红利；

6. 团队是最有效的软件交付主体，而非个人——非常赞同，一个团队应该以一个稳定的形态出现，个人英雄主义会降低团队的战斗力且不可持续；

7. 如果系统的架构和组织结构不一致，那么组织结构将成为赢家，一味只追求合理的架构阻力会很大；

8. 在中国这本书太理想，最后都为了降本增效或者围绕管理者和领导者的权势建山头，这些在当时，不值一提。

《高效能团队模式》读后感(四)：简谈如何设计好的架构

架构/架构师

谈到架构师，架构设计，大部分人的思考大致有这几个方面（层次）。

大部分的所谓的架构师只会关注到技术，有一定的技术架构好的标准；一部分人会关注到业务，但并不知道业务架构好的标准，更不知道如何将业务模块与技术进行对应；少部分人会关注到组织，但是绝大部分人只会提一句「康威定律」，不知道什么叫好的组织架构，更不知道如何组织架构的实施。 那么应该如何设计「架构」呢？设计和实施的顺序又应该是怎么样的 ？ 必须明确设计包含三个维度「技术」「业务」「组织」。很多时候技术出了问题，其实根本原因并不是技术，很可能是因为业务架构混乱或者组织僵化导致的； 在架构设计过程中的顺序是业务，技术，组织；一切都是为业务服务的，只有业务架构梳理清楚了才能去梳理技术架构。只有业务和技术架构清楚了去梳理组织架构才合理，因为组织架构的目的是为了业务和技术架构的正常运作。架构的实施顺序是组织，业务，技术；因为组织架构会影响业务架构，业务架构又会影响技术架构。 所以如果没有能力去影响业务架构和组织架构是不可能做好架构的。

关于如何设计技术架构的资料有很多，业务架构的资料没有技术架构多，但是也有不少；关于如何设计和实施组织架构的资料国外有一些，国内却极少。《高效能团队模式》是《Team Topologies》的中译本，这本书比较地回答了如何设计好的组织架构的问题。

书中首先讲了一些设计组织的基本理念，并澄清了一部分误区，也就是定义了好的标准。然后将团队归类成了四类基本团队拓扑，并总结出三种交互模式，最后强调了组织架构的可变化性，必须时刻关注可能要腐化的信号。业务架构与技术架构的设计整体方式也是如此，先树立基本观念，指定好的标准；然后给出一些 pattern 可以帮助你达到这个好的标准，最后明确架构并不是静态的，需要时刻监控你的架构，通过发现关键信号防止架构腐化。

下边是本书一些关键要点的摘录和总结，仅供参考。强烈推荐架构师和技术管理者阅读。

虽然豆瓣和知乎的排版都很难用，但是豆瓣更难用一些。大家去知乎阅读吧 https://zhuanlan.zhihu.com/p/404802625