云原生应用架构中的组织变革 一 ：开发的是产品！而不是项目 — 你的事业群开始调整了吗？

Posted 2021-09-05 魏小言

文章目录

• 云原生应用架构中的组织变革：开发的是产品，而不是项目！
• • 为什么要进行组织变革
  • 康威定律
  • 反康威定律
  • 云原生应用适合什么样的组织
  • Q&A
  • 附录

云原生应用架构中的组织变革：开发的是产品，而不是项目！

  公司的组织关系和文化有着息息相关的联系，前篇文章介绍了 “ 云原生应用架构中的文化变革 一：秉承精益制造之魂，启行 DevOps 之路！ ”，下面聊一下与文化对应的组织变革！

  问题来了，究竟什么样的组织关系适合云原生应用呢？

为什么要进行组织变革

  前 文化篇 中介绍过，目前大部分公司对 IT 的组织为 “ 孤岛 ” 类型：专业的人员聚集在一起，形成组织关系、激励机制、管理模式…相互独立的岛。
  按照这个模式，如果我们需要创新扩展一个产品，那么就会首先会成立一个项目组 —> 项目组向项目经理汇报 —> 项目经理与各个孤岛进行协作，寻求对应的资源 —> 项目架构成立。

  从结果论看，这样的常规做法没毛病，结果顺利达成。可你仔细品味，就会发现这样得到的架构或者模式，使新产品功能的开发迭代速度大大降低，架构模块的质量难以被保证，产品最终的市场效果无法最佳实现。
  直接这样说有些抽象，如果不是正在被这种做法耳濡目染的人，可能无法体会。

  举个例子，常规的架构中，往往会对结构进行拆分。如，服务层、业务层、数据访问层、基础设置层「存储层、中间件」…等等，这些层在实际开发中，跨越了多个业务能力领域，也就是会有多个孤岛进行支持保障，这样势必使得在其之上的创新和部署独立于其他业务能力的新功能变的非常困难。

  为什么会这样子呢？组织架构怎么会影响产品呢？

康威定律

  这个问题，在 1967 年的时候就被 Conway — 康威 认识到了，并提出了自己的观点：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

  翻译过来，就是 “ 组织设计的产品/设计等价于这个组织的沟通结构 ”。
  简单的说，就是，“ 组织决定产品形态 “。

  几十年的实践加理论证明，这个观点是正确的。后人把这个问题观点称为 ” 康威第一定律 “。

反康威定律

  既然，Conway 说了，组织结构什么样，产品形态就什么样。那如果反过来呢？
  不错，已经有人这样想过，提出了 “ 反康威定律 ” 或 “ 逆康威定律 ”。

  在孵化产品的早期，不需要建立一个与其组织结构图相匹配的架构，而是先决定了产品最适合的架构，并重组组织以匹配该架构。
  这样一切都将符合期望，切产品迭代发展呈现主动形态，而非受组织牵连呈现被动形态。

云原生应用适合什么样的组织

  云原生应用作为转向DevOps文化的一部分，需要遵循 “ 反康威定律 ”。以产品形态（架构）为主，创建一个包含了各方面专业员工的团队，包含 构建、测试、交付和运营提供业务能力的服务所需的所有角色。

  这样这支跨职能、业务能力的团队，为产品长期付出，开发的是产品而不再是项目。

Q&A

1、遵循 “ 反康威定律 ” 组织的团队规模怎么确定呢？

这个需要根据产品适合的架构能力来决定，一般不会太过庞大，15 人左右。
这种组织又叫做 “ 双比萨队 ”，如果一个团队不能用两个比萨饼喂饱，那就意味着团队规模太大了。

附录

人外有人，天外有天！