关于devops:DevOps|研发效能团队组织架构和能力建设-审核中

3次阅读

共计 2363 个字符,预计需要花费 6 分钟才能阅读完成。

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

业务闭环组织架构

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

业务闭环组织架构特点

  • 最大化响应速度
  • 最大限度缩小内部、外部依赖
  • 最大限度升高沟通老本
  • 最大限度升高决策老本
  • 责、权、利对等

业务闭环组织架构益处

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

业务闭环组织架构劣势

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

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

职能独立型组织架构

职能独立型组织架构特点

  • 每个人都依据业余线,依照职能向上汇报,决策集中在最高领导
  • 当须要做我的项目时,从产品、技术,运维、QA 等团队中抽调人员组成我的项目团队。
  • 一线的我的项目人员须要依照职能线向上汇报,也须要横向做我的项目上的沟通,有更多的沟通、协调工作。
  • 对一线的我的项目人员要求高。岂但要解决好我的项目上的事件,还须要解决好职能线的事件。
  • 尽管某些公司号称 context not control,然而理论一线的我的项目人员在某些方面还是无奈作出决策的,要一直的向上反馈,有时要回升到整个组织 / 团队的高层,同时也须要一直的横向沟通
  • 为了推动我的项目顺利开展,因为波及泛滥角色,须要更多工作流程、平台的反对,以便缩小在含糊地带、两头地带的沟通、期待、决策老本。
  • 我的项目规模大、共享资源多
  • 比拟适宜成熟的业务,或者团队比拟大的公司

职能独立组织架构劣势

  • 专家领导专家。你的汇报线都是相干职能的专家。下级对上级有相对的业余判断。很少会呈现在行领导外行。
  • 同一职能团队外部能够互相交换、互相声援
  • 因为决策团队中蕴含了各个职能的相干人员,个体决策。个体决策在大团队大组织里永远是最不坏的抉择,但未必是最优抉择。
  • 面向规定办事,所有走流程

职能独立组织架构劣势

  • 决策链路长、决策过程慢,决策工夫长
  • 职能线之间达成统一后,再横向沟通,横向都称心后我的项目能力向下推动。如果有不同意见,那么只能职能线沟通 -> 横向沟通再来一遍。
  • 职能线外部也要同时承当多个横向我的项目,优先级重要度呈现变动时,其余职能团队也须要变动,但未必能及时反馈。
  • 责、权、利不对等。「摘桃子」「背黑锅」常产生。
  • 职能线外部被「摘桃子」「背黑锅」时常产生。不同职能线基于脸面都是有桃子一起吃,更多的是「被甩锅」。
  • 各个职能部门的利益与横向团队的利益、客户的需要未必统一,短少用户利益的代言人
  • 谁代表用户谁有决定权。职能独立型的组织之间,各个职能是互相配合的关系,谁都能够说代表用户可是谁又无奈齐全代表。
  • 宰割的各个职能部门之间的沟通交流合作耗时、耗力、费神
  • 依照流程做事,个体决策,各个职能部门个体对最终业务成绩负责,经常导致无人对业务后果负责
  • 谁都在做事,也都很辛苦,可是最初后果不好,能怪谁?产研运各个职能向上最近交叉点的那个人么?
  • 更多的对流程、对撑持平台的反馈、埋怨。然而平台无奈解决解决不了人心。

本文总结

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


浏览我的更多文章

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

正文完
 0