首页 > 其他分享 >DevOps|研发效能团队组织架构和能力建设

DevOps|研发效能团队组织架构和能力建设

时间:2023-09-25 16:49:24浏览次数:39  
标签:团队 架构 效能 组织 闭环 DevOps 业务 职能

研发效能团队相对于各个公司主营业务规模来说并不是很大,但是在经历的几家公司里主要是有两种组织架构,职能独立型组织架构和业务闭环型组织架构。本文主要讲解这两种组织架构的特点、优劣、劣势。

业务闭环组织架构

这里引入了一个概念-特性团队,以及特性团队的负责人(FTO),更多的内容在我之前的文章《研发效能组织能力建设之特性团队FeatureTeam(上)》有过介绍,这里只把一些关键点列出来。特性团队是一个长期稳定、跨职能跨组件、持续端到端交付用户价值的团队。特性团队就是一个业务闭环的组织架构。图中的负责具体业务的运维人员、QA、设计师甚至都可以闭环到业务中去,这样整体效率会更高。

业务闭环组织架构特点

  • 最大化响应速度
  • 最大限度减少外部、内部依赖
  • 最大限度降低沟通成本
  • 最大限度降低决策成本
  • 责、权、利对等

 

业务闭环组织架构好处

  • 交付快,单位产出多
  • 小步快跑,唯快不破,精英小团队
  • 团队内可以做到端到端交付,极少等待时间,交付速度快
    • 一手的信息来源,从头跟到尾的负责制模式
  • 减少团队之间依赖,计划更容易、更有保障
    • 如果团队间有依赖,那肯定是弱依赖,如果是非常强的依赖,团队内部要么有人主动出来承担这部分工作,要么闭环到团队内部。
  • 团队内部快速沟通、交流、决策,快速响应用户的诉求
    • 大家都围绕着几个桌子坐,每日例会,平时有问题快速沟通。
  • 以业务为中心、以用户为中心驱动团队运转
    • 闭环团队的工作人少活多,强调自我驱动、主动承担。
  • 责、权、利对等,成员责任心、自驱力高
    • 大家每天坐在一起工作,每天做什么,做得怎么样,团队贡献度,每个人心里都有一杆秤

 

业务闭环组织架构劣势

 

  • 团队整体压力大
  • 对业务闭环组织的负责人(FTO)要求高,定方向、搭班子、带团队的综合能力都要很出色。FTO不但要强于业务,还要在多项职能上都要有很好的判断,尤其是带领产品、研发、QA、运维、设计师、运营等多种背景的小伙伴上。虽然很多决定是FTO和团队沟通后作出的,但是我们依然认为FTO是所有问题的第一责任人,团队内部所有问题,业务问题等都要FTO担责,FTO压力比职能型管理者大很多。千金易得,一将难求
  • 对成员要求高,不断学习、自我驱动、主动承担。每日例会,每个人都做了哪些事情质量如何,团队内部每个人心知肚明,大家都知道。任务催的紧,工作压力很大,「葛优躺」「摸鱼族」难生存,未必所有人都能适应
  • 长期高强度的端到端用户价值的交付,团队注意力全部集中在事上,工作压力大、对团队内部成员的关怀度低
  • 长时间工作在一个业务领域,部分队员可能会对做的事情失去兴趣,公司、部门需要有便利的内部活水、转岗制度和机制。很多公司在这一点做得不好,我觉得要放开这方面的限制。
  • 各个业务闭环团队都会针对自己的团队、自己的业务非常实际地做出决定,在技术栈选择、规范性遵从上一般不是很注重,需要技术委员会、专家团队横向引导

 

业务闭环组织架构的一个很重要的点在于找到一个懂业务的 FTO来负责整个业务。

 

职能独立型组织架构

职能独立型组织架构特点

  • 每个人都根据专业线,按照职能向上汇报,决策集中在最高领导
  • 当需要做项目时,从产品、技术,运维、QA等团队中抽调人员组成项目团队。
  • 一线的项目人员需要按照职能线向上汇报,也需要横向做项目上的沟通,有更多的沟通、协调工作。
  • 对一线的项目人员要求高。不但要处理好项目上的事情,还需要处理好职能线的事情。
  • 虽然某些公司号称context not control,但是实际一线的项目人员在某些方面还是无法作出决策的,要不断的向上反馈,有时要上升到整个组织/团队的高层,同时也需要不断的横向沟通
  • 为了推动项目顺利开展,因为涉及众多角色,需要更多工作流程、平台的支持,以便减少在模糊地带、中间地带的沟通、等待、决策成本。
  • 项目规模大、共享资源多
  • 比较适合成熟的业务,或者团队比较大的公司

 

职能独立组织架构优势

  • 专家领导专家。你的汇报线都是相关职能的专家。上级对下级有绝对的专业判断。很少会出现外行领导内行。
  • 同一职能团队内部可以相互交流、相互支援
  • 因为决策团队中包含了各个职能的相关人员,集体决策。集体决策在大团队大组织里永远是最不坏的选择,但未必是最优选择。
  • 面向规则办事,一切走流程

职能独立组织架构劣势

  • 决策链路长、决策过程慢,决策时间长
    • 职能线之间达成一致后,再横向沟通,横向都满意后项目才能向下推进。如果有不同意见,那么只能职能线沟通->横向沟通再来一遍。
    • 职能线内部也要同时承担多个横向项目,优先级重要度出现变化时,其他职能团队也需要变化,但未必能及时反应。
  • 责、权、利不对等。「摘桃子」「背黑锅」常发生。
    • 职能线内部被「摘桃子」「背黑锅」时常发生。不同职能线基于脸面都是有桃子一起吃,更多的是「被甩锅」。
  • 各个职能部门的利益与横向团队的利益、客户的需求未必一致,缺少用户利益的代言人
    • 谁代表用户谁有决定权。职能独立型的组织之间,各个职能是互相配合的关系,谁都可以说代表用户可是谁又无法完全代表。
  • 分割的各个职能部门之间的沟通交流协作耗时、耗力、费心
  • 按照流程做事,集体决策,各个职能部门集体对最终业务成果负责,常常导致无人对业务结果负责
    • 谁都在做事,也都很辛苦,可是最后结果不好,能怪谁?产研运各个职能向上最近交叉点的那个人么?
    • 更多的对流程、对支撑平台的反馈、抱怨。但是平台无法解决解决不了人心。

 

本文总结

本文主要对比了职能独立型组织架构和业务闭环型两种组织架构的特点、优势、劣势。通常来说对于小组织、小业务、业务目标相对明确采用业务闭环型组织更好。

 

 


阅读我的更多文章

研发效能组织能力建设之特性团队FeatureTeam(上)
高效能敏捷交付团队反思:特性团队(FeatureTeam)+Scrum
互联网公司研发效能/工程效率团队建设和规划
找到能做好研发效能的人
中小互联网公司研发效能团队规模、职能划分和优劣势分析

 

 

标签:团队,架构,效能,组织,闭环,DevOps,业务,职能
From: https://www.cnblogs.com/laofo/p/17728237.html

相关文章

  • 交易日均千万订单的存储架构设计与实践 | 京东物流技术团队
    一、订单系统概述1.1业务范围服务业务线:快递、快运、中小件、大件、冷链、国际、B2B合同物流、CLPS、京喜、三入三出(采购入、退货入、调拨入、销售出、退供出、调拨出)等1.2订单中心价值1、解耦(提升系统稳定性)**原系统:**交易与生产耦合在一起,业务新增需求,涉及个上下游多个系统。EC......
  • 《架构即未来》中最常用的15个架构原则
    《架构即未来》这本书的第12章简单阐述了架构设计的一些常用的原则(后面章节会详细阐述)。这些原则中很多都是在架构一开始的设计中就要考虑进去的,这样在出现任何问题时,我们都能够及时的处理,和把问题影响的范围有效的缩小。否则就像我现在的项目,一开始设计时,考虑的很少,出问题时,没有做......
  • 交易日均千万订单的存储架构设计与实践
    一、订单系统概述1.1业务范围服务业务线:快递、快运、中小件、大件、冷链、国际、B2B合同物流、CLPS、京喜、三入三出(采购入、退货入、调拨入、销售出、退供出、调拨出)等1.2订单中心价值1、解耦(提升系统稳定性)原系统:交易与生产耦合在一起,业务新增需求,涉及个上下游多个系统。......
  • 新零售SaaS架构:面向中小连锁的SaaS系统整体规划
    零售企业的发展路径零售企业的发展路径一般可分为以下几个阶段:单店经营阶段:企业在一个地区或城市开设单个门店。这时,企业需要把精力放在了解当地市场和顾客需求上,这是积累经验和品牌知名度的重要环节。为了在市场中建立竞争力,企业需要不断提升产品和服务的质量,比如探索新的零......
  • Transformer架构解析及其pytorch实现
    备注本文对Transformer架构的分析来源于论文AttentionisAllYouNeed以及部分其引用的论文,可以理解为对该论文的翻译以及相关内容的整理。本文对Transformer的实现基于Pytorch,但是不直接调用Pytorch封装的Transformer,而是手动实现Encoder和Decoder等;与Transformer......
  • Redis搭建集群架构
    使用docker搭建6.x版本以后的镜像docker支持部署集群模式,由于Redis要求集群至少要有三个主节点,因此本次测试搭建了三主三从的Redis集群。不基于Host网络模式配置docker-compose.yml文件version:"3"networks:redis-cluster:driver:bridgeipam:......
  • PPT| 企业信息安全架构全貌 P17
        本人在四大咨询机构从事咨询工作多年,二十年一线数字化规划咨询经验,提供制造业数智化转型规划服务,顶层规划/企业架构/数据治理/数据安全解决方案资料干货.   【智能制造数字化咨询】该PPT共86页,由于篇幅有限,以下为部分资料,如需完整原版 方案,点击关注下方。  ......
  • 高级系统架构师学习(八)嵌入式系统
    一、嵌入式系统概述基本概念1、将可配置与可裁剪的软硬件集成于一体的专用计算机系统,需要满足应用对功能、可靠性、成本、体积和功耗等方面的严格要求。2、指嵌入各种设备及应用产品内部的计算机系统。它主要完成信号控制的功能。体积小、结构紧凑,可作为一个部件埋藏于......
  • Redis搭建哨兵模式架构
    使用Docker安装因为配置太复杂,所以这里我们使用dockercompose来一键部署不使用内部网络搭建编写redis主从docker-compose.ymlversion:'3'services:master:image:rediscontainer_name:redis-masterrestart:alwayscommand:redis-server--requi......
  • 组播网络基本架构
    组播关键技术1)源端网路:将组播源产生的组播数据发送至组播网络2)组播转发网络:形成无环的组播转发路径,该转发路径也称为组播分发树(MulticastDistributionTree)3)成员端网络:让组播网络感知组播成员位置与加入的组播组组播协议1)组播协议:PIMDM、PIMSM2)成员端管理协议:IGMPv1、v2、v3......