现在流行谈组织能力，应该用逆康威定律，先规划要实现的产品形态和技术架构，再倒推需要的团队结构。
一直在思考，全栈式交付业务价值的端到端团队，和边界清晰，维护固定模块的服务团队，哪种是更好的模式。
答案是不同模式适用不同场景，协作的认知负载高，需要所有人了解整体，减少对接成本，适合探索和快速创新。
而相对稳定或者通用基础设施，要有充足的时间调研、学习和尝试，就需要用服务的方式，降低人的认知负载，以舒服的工作节奏为目标，划定工作职责。用接口提供服务，可以减少了外界不确定性对项目的冲击。
但是不管复杂子系统还是平台团队，要做出好的系统，依然要引入产品管理流程，从用户画像、产品路线图开始。
而组织的目标，应该是从探索活动转变为建立可预期的交付模式，建立良好定义，功能强大的平台，从而让很多团队简单的使用服务。
image.png
在设计用于构建和运行软件系统的现代组织时，组织自身架构并不是最重要的，而是当新挑战出现时，用来适应和改变组织的设计规则和方法。战略是持续不断探索、实施、学习和变更的过程。
通过紧密协作来建立可行的服务边界，接下来通过轻量化协作验证边界的有效性。
image.png
正如作者所说，IT效能离不开健康的组织文化，优秀工程实践，良好的财务实践和清晰的业务愿景，而且归根结底，技术的本质是为世界创造价值和业务在商业上的成功。
交付业务价值的核心，归根结底是从端到端交付业务价值的流动式产品或特性团队，一切赋能、复杂子系统和平台团队，都是以降低端到端团队的认知负载为核心，从而加速产品开发。
更适合探索的是协作模式，目标是减少团队工作交接的损耗，协作效率和工作舒适度肯定不如服务模式，它的目标是协作的高成本带来的高价值产出。
现代科学已经很清楚，7-9人的紧密协作团队，是高信任团队的极限。最多可以到15人，前提是组织有高度信任、相互尊重和接受失败的文化。
在现代软件交付中，带有认知负荷，增加摩擦的两个重要因素，一个是代码的膨胀，越来越大而复杂；一个是运维和基础设施，维护的应用越来越多。团队优先方法通过限制软件系统大小，匹配团队预期的工作状态。
我们常说，微服务架构，不是技术问题，而是组织结构，团队规模和软件工程问题，但是这是问题而不是解决方案。这本书的团队优先方法，就是从具体怎么做，什么时候探讨组织如何用逆康威定律，不断调整结构，适应业务快速变化。
组织要根据想得到的软件架构来设计团队结构，都不是期望团队盲从一个被设计好的结构。这个结构要与软件架构和产生的非预期风险匹配。
目标是组织结构能够赋予团队完成从设计到部署的工作能力，而无需团队之间高频沟通。
软件设计并不是要在单体和微服务之间做出选择，而是要适配团队的最大认知负荷。
如果要想快速安全的交付软件，首先应该避免的是只由单一职能人员组成的竖井团队。
产品特性团队这样端到端交付的流动式团队，是交付业务价值的核心，但是总是在交付压力之下，要快速响应变化，缺少调研、探索、学习实践新技能的时间，由赋能团队，来进行调研尝试，然后在工具框架技术栈方面给出高质量建议，赋能的重点是教练，而不是亲自动手。
为了降低使用复杂子系统的认知负载，就需要专门的子系统团队，维护依赖复杂专业知识的领域子系统。
平台则将少量高质量服务提取出来，有点中台的意思，不过看起来应该是要非常少且高质量才行，赋能而不能限制，最后自身能用市场方式证明价值。
Spotify的部落模型很受推崇，但是我现在比较好奇，在没有对照实验的情况下，我们要怎么样证明或者证伪，这种动态演进的模型，会比饱受质疑的拼多多模式更好，是从投入产出比这样的运行效率，工作体验，媒体印象，还是商业上的成功。
经济和市场本身就是通过竞争筛选拥有最合适基因的组织和团队，是不是筛选出来的已经必然是效率最高的
image.png
网友评论