数字化企业敏捷建模之组织建模( 六 )


延续上面的案例 , 让我们一起来看看利用这样的地图如何进行技术架构的动态治理 。
进展一:经过一段时间的尝试 , “模板工厂”小组形成了重构的套路 , 并且已经有3个公共模块被提炼出来 , 形成了内部的复用 。 最近完成了2个模块的代码主干合入和上线 。 公共模块目前通过SDK的方式提供给各个模板团队使用 , 分析识别出了额外的2个模块待重构 。
三个模板团队反应对于采用新的SDK开发还不是很适应 , 已经提炼出来的第三个模块涉及到较大的代码重构工作量 , 目前还没有时间进行采纳 。
根据这样的情况 , 我们应该及时对“模板工厂”团队的工作定位进行改变 , 由之前的面向模块化复用所采用的复杂子系统定位 , 转向帮助模板团队采纳新组件、推动各模板团队提升自身架构模块化的赋能团队 。
数字化企业敏捷建模之组织建模
文章图片
(基于进展一带来的团队结构调整 , “模板工厂”成为一个赋能团队 , 和三个模板团队的合作也采用“促进”模式 , 从而明确了团队工作职责和合作模式的转变 。 )
进展二:为了活跃用户社区 , 产品经理希望能够让用户自定义模板 , 形成真正的模板市场 , 由此作为抓手来激活用户之间的线上交流 , 甚至未来将模板作为艺术品进行NFT交易 。
这个想法经过初步的价值建模得到了公司高层的支持 。 业务和研发团队联合进行了领域建模分析 , 在模板管理方面的领域模型改动较小 , 业务功能上允许用户进行多媒体和矢量模板的自定义(3D模板暂时不开放) 。
技术团队经过分析 , 认为虽然模板的类型及数据结构未发生变化 , 但从业务连续性的视角 , 仍然希望能够将用户自定义的模板隔离开来 。 由此产生了下图的团队结构变化 。
数字化企业敏捷建模之组织建模
文章图片
(基于用户定义模板组建了一个复杂子系统团队来进行专项开发 , 考虑到针对多媒体和矢量模板数据结构上的一致性 , 需要跟这两个相关团队紧密协作 。 成立复杂子系统团队也是希望明确阶段性的架构隔离 , 成熟后有可能进行团队的合并 。 )
团队拓扑全球社区也给出了结合WardleyMapping类似的应用案例 , 感兴趣的读者可以参考英国运动服饰零售商店Footasylum的应用案例:https://teamtopologies.com/industry-examples/team-topologies-at-footasylum-platforms-flow-and-wardley-mapping
组织建模小结组织建模的核心逻辑是针对软件产品和系统内部架构上的逆康威定律 , 即我们希望通过保持组织内部的灵活性来迎战持续变化的外部需求 , 从而能够持续增量交付高质量的产品或系统 。 在技术架构层面 , 团队结构和技术架构是直接的映射关系 , 相互作用在日常开发工作中立竿见影 。
由此 , 在技术架构层面的建模工作中 , 我们提出了两大视角的转换:
管理标的物的转换 , 从过去系统内部的技术模块到现在研发组织中的团队 , 促使我们真正地思考如何能够从团队定义和协作模式上保证技术架构的落地;
架构演进考量的转换 , 从过去考虑技术模块的改变转换为考虑团队结构的改变 , 促使我们思考合理的认知负荷的分配 , 为团队的高效能运作奠定基础 。
我们意识到这种视角的转换 , 对于已经习惯于划分各个技术模块的架构师及团队来说是一种挑战 。 但我们希望大家能够知行合一 , 真正将架构的演进贯彻到日常的架构治理工作中去 。 而我们这里提出的组织建模 , 无疑是帮助大家明确演进过程的一种方法 。 即使短期视角转换困难 , 也应该在读完此文后 , 开始在技术架构设计阶段引入基于团队结构的组织建模 , 并且在出现架构问题时 , 多一点团队结构合理性的考虑 。