组织架构简单组织架构简单高效

转载

Aceryt 2023-08-21 19:33:01

文章标签 组织架构简单团队开发职场和发展程序人生 API 文章分类 架构后端开发

一、团队即交付

二、流式设计团队拓扑&改进团队交互来促进创新和快速交付

三、应用实践和持续改进，保持上升趋势

一、团队即交付

1、高效能交付团队的特征和问题

增强：包括但不限于以下示例：

1）高度工程能力成熟度（持续集成、持续交付）；

2）强有力且稳定的支持系统；

3）无须创建应用基础设施；

4）SRE可扩展性的应用事实；

5）稳定的团队、高效的协同；

降低：包括但不限于以下示例：

1）经常换团队；

2）目标不一致；

3）技术栈太多；

4）避免单一职能人员的团队坚井（测试、DBA、ETL、系统架构）；

2、康威定律：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗地来讲：产品必然是其（人员）组织沟通结构的缩影。

1）第一定律组织沟通方式决定系统设计。

2）第二定律时间再多一件事情也不可能做得完美，但总有时间做完一件事情。

3）第三定律线型系统和线型组织架构间有潜在的异质同态特性。

4）第四定律大的系统组织总是比小系统更倾向于分解。

3、团队优先的思维方式，如何选择团队边界

即认知负荷、团队API、团队规模架构3个大的维度，如何让其达到合理平衡，有以下方法：

1）领域驱动设计

不可见的单体：单体应用、单体数据库、单体构建、单体发布、单体模型、单体思维（标准化）、单体工作空间（开放式办公室）；

2）破裂面：

业务领域、监控合规、变更节奏、团队位置、风险隔离、性能隔离、技术隔离、用户角色、特定技术和组织的天然破裂面；

二、流式设计团队拓扑&改进团队交互来促进创新和快速交付

1、松耦合、模块化的流式设计的团队拓扑

静态4类拓扑：流动式团队、平台团队、复杂子系统团队、赋能团队；

类型	是什么	行为特征	示例
流动式团队	面向有价值的工作流，团队有能力快速、安全、独立的交付用户价值	流动(不一定是产品)；很少有协作； 2个比萨；	各业务产品、大数据资产
平台团队	面向底层服务，降低认知负荷	服务提供者；少而4高服务；紧密协作&满足客户需求；	基础架构、大数据架构
复杂子系统团队	负责构建和维护系统中严重依赖专业领域知识的子系统团队	领域专家；非组件共享，而是对领域认知负荷驱动；早期协作，稳定后服务；	业务中台、AIOT、算法、ERP接口
赋能团队	具备专业领域的技能，指导并帮助流动式团队成功	较强的沟通能力；提供指导而不是具体执行；专业浪潮之巅；	专业线、流程组、运维组、工具组

每种团队拓扑有其优劣势，找到合适的团队拓扑，促进业务的发展是核心。

比如：团队期望是全部自服务模式，前期是比较合适的，稳定后则可能会带来重复建设等问题。

2、如何改进团队交互来促进创新和快速交付

类型	是什么	行为特征	工作方式	应用场景
协作	与另一个团队紧密合作	高频沟通和互相尊重；有利于创新和快速探索；边界不清，认知负荷增加；	两个具备专业技能和职责的团队共同完成工作；两个团队融为一体；一般1对1，不要1对多；	1、流动式团队与复杂子系统团队；流式式团队与平台团队；复杂子系统与平台团队； 2、项目和产品初期或要进行比较大的调整变革的时候，适合采取协作的方式；
服务	使用或提供某种服务，尽量减少协作	重视用户体验；职责清晰，交付可预期，依赖有效的产品管理；创新减缓，边界不合理效率反而降低；	标准的服务；可以1对多；	1、流动式团队和复杂子系统团队使用平台团队提供的平台即服务；流动式团队和复杂子系统团队使用另一个复杂子系统团队提供的组件或库。 2、项目和产品的稳定期，系统边界（比如API）非常稳定且优雅整洁，能够为其他团队提供稳定的服务
促进	为提供或者寻求其他团队的帮助清除障碍	帮助与被帮助，开放心态，赋能团队的主流交互模式；降低流动式团队的阻碍以提升流动速度；识别组件和平台的缺陷或缺失的功能和特性；	非生产性的工作；赋能与被赋能；	1、赋能团队帮助流动式团队、复杂子系统团队、平台团队；一个流动式团队、复杂子系统团队或平台团队帮助一个流动式团队； 2、项目和产品的交付期的赋能交互模式；纯赋能团队的核心交互模式；